Jump to content
  • Advertisement
Sign in to follow this  
Tree Penguin

Quick UDP/TCP question

This topic is 4819 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement
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.

Share this post


Link to post
Share on other sites
Absolutely not.

UDP is a connectionless protocol, as oposed to TCP.
UDP is an unrealiable protocol, because not every packet is garanteed to get to the destiny and is not garanteed to get there in order, as oposed to TCP.

There a lot more you need to change.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!