UDP-packets

Started by
12 comments, last by questors_endgame 17 years, 6 months ago
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
^^
Advertisement
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.
Click here to patch the mozilla IDN exploit, or click Here then type in Network.enableidn and set its value to false. Restart the browser for the patches to work.
no, my question , when i use UDP, i send a number such as: 9 , and whether the client receive other number such as 40 or something like that?
^^
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.
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.
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.
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).
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.
enum Bool { True, False, FileNotFound };
SO when the packet is dropped, Is it automatically sent again to the receiver (like in TCP)?
^^
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.

This topic is closed to new replies.

Advertisement