Sign in to follow this  
quang

UDP-packets

Recommended Posts

i have a question : when using UDP protocol each packet is sured to have no error(bit error) when it reach the destination? I know with TCP protocol each packet is sured that they have no error and in order when they reach the destination

Share this post


Link to post
Share on other sites
no. udp packets can and do get dropped, thrown out of order or simply put on hold for random reasons for random amounts of time.

Its the price you pay for speed, and the lack of the lag that tcp gets after a single packet drop.

Share this post


Link to post
Share on other sites
The data is almost always checksumed at the data link layer which will probably keep you safe in most cases. Generally you shouldn't rely on that it is though, which is why TCP as well as UDP includes a 16-bit CRC field.

Share this post


Link to post
Share on other sites
Quote:
Original post by BleedingBlue
Yes you could send a packet containing 9, and it could be 40, 1200, or not even get there. UDP is not guaranteed in anyway.


Incorrect. UDP does not make any garuntee about packets getting lost, duplicated, or reordered, but it does garuntee that when a packet arrives, the packet is fully intact.

Share this post


Link to post
Share on other sites
Quote:
Original post by Driv3MeFar
Incorrect. UDP does not make any garuntee about packets getting lost, duplicated, or reordered, but it does garuntee that when a packet arrives, the packet is fully intact.

Indeed, although this checksum fails a little more than might be expected. The link-level checksum should catch all but 1 in 4 billion errors, but the non-randomness of the packet structure makes the actual number of packets slipping through larger (1 in 16 million). (See: When The CRC and TCP Checksum Disagree - Stone J, Partridge C for an interesting read about this)

All in all: in general you can trust UDP-packets to be intact. Only when you need to be really, really, really sure that a packet is intact could you consider an extra checksum. (Remember you can check the integrity of a packet in other ways then checksumming).

Share this post


Link to post
Share on other sites
Quote:
Only when you need to be really, really, really sure that a packet is intact could you consider an extra checksum. (Remember you can check the integrity of a packet in other ways then checksumming).


Note that "intact" only means "contains what the sender put in there." Remember that the sender may not be your program, but may instead be a program altered by a malicious user.

For all intents and purposes, the combination of UDP checksum plus link-layer CRC will catch most corruption. In the off chance that you do get a corrupt packet (which is uncommon) and the checksum/CRC don't catch it (very, very uncommon, in turn), then this will be no different from a malicious packet crafted by a hacking user. Thus, your application must always be resilient to mal-formed data.

This is true for TCP, too, btw -- hackers can get in there just as easily as in UDP.

Share this post


Link to post
Share on other sites
Quote:
Original post by ZeRaW
Quote:

SO when the packet is dropped, Is it automatically sent again to the receiver (like in TCP)?


No. If u need to resend every dropped packet, just use tcp.


Or, as is the better option in many cases (such as when you don't need to resend every dropped packet, just really important ones), write your own reliability layer on top of UDP.

Share this post


Link to post
Share on other sites
I've got some udp tests I made working pretty well, so how do you usually handle resending packets or detecting lost, out of order etc. My plan was to hold a few packets in memory at all times and to have each have a number, a 10 bit number, to track order, but I have little experience in the area. I wasn't planning on using threads at all is this reasonable?

Share this post


Link to post
Share on other sites
Quote:
Original post by questors_endgame
I've got some udp tests I made working pretty well, so how do you usually handle resending packets or detecting lost, out of order etc. My plan was to hold a few packets in memory at all times and to have each have a number, a 10 bit number, to track order, but I have little experience in the area. I wasn't planning on using threads at all is this reasonable?


There are standard approaches to handling packet loss, packet reordering, packet duplication, flow control, sliding windows, and all the other things you should know about to write a really thorough network stack.

You've more or less got the idea already, holding onto packets looking at the order of incoming ones to see which ones you missed. You've got lots of options for exactly how to handle them once you have missed them. You could have the receiver request the missing one (NAK packets), or you could have the server notice it didn't receive a positive response for a packet (ACK packet) and resend. There's a LOT of reading on this particular subject. If you're a student, I'd recommend a networking class. If not, there're lots of tutorials and books on the subject.

It's perfectly reasonable not to use threads at all. It's much easier, especially if you're new to the problem, and in many situations it's just as fast or faster.

Hope that helps!

Share this post


Link to post
Share on other sites
Thanks, I wonder if there really are a lot of tutorials though, All I have looked at say nothing about UDP except very brief how to get started things. I got the impression a lot more is available on tcp even for games. So if there is a place with some free tutorials or information I'm sure there are some of us who would benefit from hearing about it.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this