[Spread-users] Corrupt packets
Alec H. Peterson
alec.peterson at messagesystems.com
Mon Dec 4 16:28:03 EST 2006
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
More information about the Spread-users
mailing list