No. When in stream mode the sockets deal with the data as a stream. Thus enabling you to read small bits of data at a time. Unreliable datagram protocols however (of which UDP is one) require you to read all of the data pending from a particular sender. Doing otherwise causes the remaining data to be dropped.

With stream based sockets you end up with a socket per client, and tend to call send/recv. With datagram based sockets you typically end up with one socket, and call sendto/recvfrom, passing the address of the destination/source you wish to send the data to.

Quote:Original post by xor
and is not garanteed to get there uncorrupted, as oposed to TCP.

Eh, UDP is checksummed. Unless the packet is corrupted in a very specific way, it will fail the checksum process and thus be dropped. The chances of getting corrupted data unintentionally is...slim, although that still doesn't mean you shouldn't handle that case, as someone might try to exploit your networking code to gain access to your machine. Although checksumming is optional (just set the field in the UDP header to 0).

Quote:Original post by Washu

Quote:Original post by xor
and is not garanteed to get there uncorrupted, as oposed to TCP.

Eh, UDP is checksummed. Unless the packet is corrupted in a very specific way, it will fail the checksum process and thus be dropped. The chances of getting corrupted data unintentionally is...slim, although that still doesn't mean you shouldn't handle that case, as someone might try to exploit your networking code to gain access to your machine. Although checksumming is optional (just set the field in the UDP header to 0).

UDP packets can get corrupted by bugs in routers that, for example, fragment packets, and upon reassembly, compute a new checksum. If there is an error in any step, the packet checksum will be valid, but the data it is computed from will not be valid.

For voice data, etc., it may not be catastrophic to get a bad UDP packet, but for game data, it could cause the game to crash. An arithmethic (additive) checksum is not a very strong method to detect errors in a block of data: a CRC (polynomial division) is much stronger. In the same way a checksum can be recomputed on invalid data, so can a CRC be recomputed by an attacker after modifying a packet. Thus, to try to prevent hacking, a cryptographic hash must be used (the data itself should also be encrypted).

Quote:Original post by John Schultz

Quote:Original post by Washu

Quote:Original post by xor
and is not garanteed to get there uncorrupted, as oposed to TCP.

Eh, UDP is checksummed. Unless the packet is corrupted in a very specific way, it will fail the checksum process and thus be dropped. The chances of getting corrupted data unintentionally is...slim, although that still doesn't mean you shouldn't handle that case, as someone might try to exploit your networking code to gain access to your machine. Although checksumming is optional (just set the field in the UDP header to 0).

UDP packets can get corrupted by bugs in routers that, for example, fragment packets, and upon reassembly, compute a new checksum. If there is an error in any step, the packet checksum will be valid, but the data it is computed from will not be valid.

For voice data, etc., it may not be catastrophic to get a bad UDP packet, but for game data, it could cause the game to crash. An arithmethic (additive) checksum is not a very strong method to detect errors in a block of data: a CRC (polynomial division) is much stronger. In the same way a checksum can be recomputed on invalid data, so can a CRC be recomputed by an attacker after modifying a packet. Thus, to try to prevent hacking, a cryptographic hash must be used (the data itself should also be encrypted).

Yes, however such bugs are rare. Things like that tend to get caught and fixed, because they are serious problems. I didn't say you shouldn't expect corrupted data, i did say that the chances were slim.

TCP only does a checksum as well, so the possibility of getting corrupted data from both is roughly the same.

Quote:Original post by Washu

Quote:Original post by John Schultz

Quote:Original post by Washu

Quote:Original post by xor
and is not garanteed to get there uncorrupted, as oposed to TCP.

Eh, UDP is checksummed. Unless the packet is corrupted in a very specific way, it will fail the checksum process and thus be dropped. The chances of getting corrupted data unintentionally is...slim, although that still doesn't mean you shouldn't handle that case, as someone might try to exploit your networking code to gain access to your machine. Although checksumming is optional (just set the field in the UDP header to 0).

UDP packets can get corrupted by bugs in routers that, for example, fragment packets, and upon reassembly, compute a new checksum. If there is an error in any step, the packet checksum will be valid, but the data it is computed from will not be valid.

For voice data, etc., it may not be catastrophic to get a bad UDP packet, but for game data, it could cause the game to crash. An arithmethic (additive) checksum is not a very strong method to detect errors in a block of data: a CRC (polynomial division) is much stronger. In the same way a checksum can be recomputed on invalid data, so can a CRC be recomputed by an attacker after modifying a packet. Thus, to try to prevent hacking, a cryptographic hash must be used (the data itself should also be encrypted).

Yes, however such bugs are rare. Things like that tend to get caught and fixed, because they are serious problems. I didn't say you shouldn't expect corrupted data, i did say that the chances were slim.

The following statement implies that a checksum is sufficient for corruption detection, and that additional corruption checking is only necessary in the case of hack-prevention:

Quote:Original post by Washu
The chances of getting corrupted data unintentionally is...slim, although that still doesn't mean you shouldn't handle that case, as someone might try to exploit your networking code to gain access to your machine.

I would agree with the following statement:

Quote:
While the chances of getting corrupted data unintentionally is slim, one should still handle that case, as such errors do occasionally occur via bad routers and buggy software/drivers. In cases where someone might try to exploit your networking code to gain access to your machine, one should use a cryptographic-strength hash.

Again, an arithmetic additive checksum is a relatively weak method to detect errors in blocks of data. A CRC or stronger method should be used in any application where fault tolerance is important. The few extra bytes required are more valuable than the (miniscule) loss in bandwidth. Link layers can provide CRC protection, but it's up to the application to ensure the integrity of its data.

For example, in the case of a MMOG, customer support costs outweigh the additional bandwidth required to validate data. In the case of faulty routers and/or malicious hackers, the application will drop the bad packets instead of crashing. While the bad routers/active-hackers can be fixed in time, crashing applications can be prevented.

Another example: at the Launch of XBox Live, faulty routers were found in Japan. The short term solution was to reduce UDP packet size so that the packets were never fragmented. Since XBL packets are encrypted and authenticated, the apps would not crash, though the corrupted packets would get dropped.