On Tuesday 11 September 2012 01:48:08 Constantin Makshin wrote: > TCP's 16-bit checksum isn't [very] reliable by today's standards, so doing > additional integrity checks at application level is not necessarily a bad > idea (in situations where correctness of the transmitted data is REALLY > important/critical). > > On Sep 10, 2012 11:43 PM, "Konrad Rosenbaum" <kon...@silmor.de> wrote: > > * You do not need to checksum them against physical defects.
A 16bit CRC is more than adequate for simple physical defects in todays
networks. The probability that 2 bits flip in a way that keeps the checksum
valid is extremely slim (smaller than a 16bit checksum would suggest at first
glance).
I would be worried if Jumbograms of 1MB or larger were common. But we have an
Internet with the average package being somewhat below 1500 bytes long and an
ISP side MTU of 4kB.
If you need security against malicious attackers: use a cryptographic hash (at
least SHA-1) and proper encryption (e.g. by using SSL).
If you transfer data in which every single bit is life-threateningly important
and you use it only long after transfer: use SHA-1 checksums and store them
with the file. Thre probability of corruption while in storage is at least as
high as the probability of corruption during a TCP transfer. I would also
recommend highly redundant hardware with at least two independent
implementations of the software in this case. ;-)
Konrad
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
