On 01/27/2014 08:07 PM, Giancarlo Razzolini wrote:
> Em 27-01-2014 19:05, Why 42? The lists account. escreveu:
>> FWIW, you don't have to out in the sticks (the backwoods?) to have
>> a network problem:
>>
>>
>> http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-sometimes-couldnt.html
>>
>> However, as I understand it, in this case the TCP checksumming worked
>> and protected the application from the corrupted data.
>>
>> Cheers,
>> Robb.
>>
> I wasn't exactly in the woods, but I had a 600Kbps unreliable ADSL
> connection that would send the packets. But the latency and corruption
> was so severe that TLS handshakes would take too long. And even if
> complete, the connection wouldn't sustain itself. Anyway, the UDP vpn
> improved things quite a bit. This due, well, to UDP of course, and to
> the dynamic compression, reducing the amount of data sent to the wire.
>
> This case you pointed, the TCP checksumming was doing it's job.
> Successfully protecting the application. This kind of things, where bits
> "randomly" flip, proves that computer science can be anything but an
> EXACT science. That's one of the reasons why the machines will
> (hopefully) always need humans.
>
> Cheers,
>
To add to the preceeding...
One client of mine used a CVS repository via coast-to-coast NFS.
Somewhere in the deeps, the UDP checksum was set to 0 (no checksum).
Somewhere else, one bit in each packet was corrupted.
If the UDP checksum had been present we would have seen the bad
data a lot sooner. We had to go back at least a month, sometimes more,
to find good data, and then recreate all the edits.
This scenario shows a danger of silently passing corrupt packets.
It would be good if when data protected by a checksum is modified,
the current checksum is validated and some appropriate? action is done
(drop? produce invalid new checksum?) when proceeding.
Geoff Steckel
