Re: Corrupt packets

Hi Jonathan,

On Dec 4, 2006, at 13:11, Jonathan Stanton wrote:

> Very interesting.
>
> I saw in the patch that you are checksumming both the daemon-to-daemon
> traffic (UDP) and the client-server (message contents only) which goes
> over TCP/UnixDomain. This is really strange, as both UDP and TCP have
> checksums and should not deliver corrupted data to the application
> (Spread)

Agreed.  Hence my confusion.

> Were the UDP/TCP checksums valid on the 'corrupt' data -- I'd guess  
> they
> had to be for the packets not to be dropped -- were you able to  
> capture
> an example packet that had a valid checksum but was corrupt?

I did not check this, as I'm not as familiar with the Solaris IP  
tools as I am the BSD ones.  I would think that they would have to  
be, however.

> This kind of checksum is something I'd like to avoid if possible as it
> complicates the code and is more overhead per packet -- but if we can
> have corrupt data delivery and it isn't just a particular OS bug, then
> it's worth considering.
>
> If the data is corrupted in kernel/memory before being sent but after
> "spread" finished with it, then that would explain the situation --  
> but
> should indicate an OS bug.

I performed some checksums within Spread as well, thinking that was  
where the problem had to be since the transport layer is supposed to  
take care of this sort of issue.  However, everything came back clean  
inside of Spread.

However, I think the utility of the checksums can be seen beyond just  
these sorts of 'odd' situations.  For example, Spread doesn't have  
any protection against foreign packets (at least without the  
checksums).  Granted the checksums are not perfect, but I think this  
should make Spread a lot more resilient against 'unauthorized'  
packets that may get injected into the ring (either intentionally or  
by accident).

Alec