On 11/16/05, Andreas Bartelt <[EMAIL PROTECTED]> wrote: > I was wondering why such a simple checksum algorithm is implemented in > TCP. I suppose, it's because of the slow CPU performance many years ago.
and that's the way the great tcp gods of old said it must be. > In RFC 1122 I've read that the TCP checksum MUST (the usual caps lock > problem...) be implemented: i'm not sure if you're serious or not, but MUST has a particular meaning. > So I'm wondering why it MUST be calulated: > is it necessary to implement a checksum in TCP because reliability at > layer 2 is insufficient in practice? I see only two possible answers to > this question: > 1) yes - than it's a very old reliability bug and should be fixed, > because sooner or later the TCP checksum won't catch a random error > pattern in a segment. (should it be fixed by always using an alternate > TCP checksum option, i.e. a MD5 hash? Or by improving layer 2 > reliability in hardware?) [btw, netstat -sp tcp shows me that there > sometimes are TCP checksum errors - 23 errors in 9 days on a slow DSL link] good luck communicating with other tcp devices after you change your checksum to md5. the point is to be fast and catch some errors. also, type end-to-end into google. > 2) no - so why not skip TCP checksum calculation at all? (at least for > incoming seqments this wouldn't break a thing besides the RFC itself). because then you don't detect errors.
