Is it worth additional overhead to add an extra checksum to UDP packets?

I'm working on an application which transfers encrypted files over UDP (yes; I know UDP isn't usually used for file transfer, but this is an edge case), and开发者_C百科 was wondering if its worth the additional overhead to add an extra checksum to the packet. I know it's not 'likely' that UDP packets will come in corrupted, but would it be worth it to add an additional checksum?

---

encrypted files over UDP

If you encrypt, then your encryption must include a HMAC. Also, if you encrypt, you must have a session key exchange protocol (over UDP? Lets ignore that for a moment) and you must generate a random IV for each UDP packet and include this IV in the packet. If you don't take this precautions (separate IV per packet, add HMAC) then your encryption is basically useless. And if you have an HMAC, you don't need a checksum.

---

UDP already has a checksum 16 bits, very unlikely that there is a collision, possible in theory.

You definitely want partial checksums. If you have a 1TB file that takes a day to transfer and then you get a hash fail, that would make you very sad.

Lazy solution: Hash every megabyte or so? Maybe more or less, eyeball it.

Right solution: Write an application that sends random data and hashes with your UDP transfer spec. See what percentage fails, (bonus: find tonnes of bugs in your app and fix them in advance) estimate what data sizes you should hash.

Probably not a big deal to go lazy on this one. Just think, how much time are you okay wit losing? How much data will 99% of your use cases transfer in that time? That is how much data you should be hashing intermediately.

---

UDP packets already have a checksum to detect corruption. I don't think adding another checksum improves anything. However, you might be interested in Hash Trees.

Hash trees can be used to protect any kind of data stored, handled and transferred in and between computers. Currently the main use of hash trees is to make sure that data blocks received from other peers in a peer-to-peer network are received undamaged and unaltered, and even to check that the other peers do not lie and send fake blocks.

---

It's up to you. If you need very high reliability, you could add a CRC32 computation.

The checksum for a UDP packet is computed thusly: "all 16-bit words are summed using one's complement arithmetic. The sum is then one's complemented to yield the value of the UDP checksum field."

...Which seems like you're going to have fairly high, but not foolproof, reliability with the existing checksum.

---

Probably not, given they already have a checksum. Adding a second one isn't going to help all that much unless you're really worried about edge cases which the UDP checksum doesn't pick up.

---

I would say yes. If I recall, IPV4 level checksums are optional for UDP streams. IPV6 makes it mandatory.

---

Given that UDP already does a check sum (one's complement) and the encryption algorythm also has some type of integrity checking (You did not say what type of encryption you are using, but most of the established encryption schemes have integrity checking), I think it would be unnecessary to add an additional checksum. Having said that, I will point out that you need to be aware of how the UDP and Encryption integrity failures will be reported. I believe that a chacksum failure is reported as a SocketException with the error code set to WSANO_RECOVERY 11003. Obviously how it is reported for your encryption sche,e depends on the scheme. You will then have to decide what you are going to do about it. Catching it on the packet level allows for a request to send just that packet again, assuming that the sender keeps track of what is in each packet. This can become complex in a hurry, which is ahy so many people just end up using TCP.

Hope that helps.