Hi,
Damien Miller wrote:
...
[EMAIL PROTECTED] djm]$ netstat -sp ip | grep -E '(bad.*checksum|total packets)'
61092730 total packets received
0 bad header checksums
wouldn't netstat -sp tcp | grep -E '(bad.*checksum|total packets)' give
the output of interest?
(uptime 10
Hi,
Tobias Weingartner wrote:
On Thursday, November 17, Andreas Bartelt wrote:
As much better algorithms for error detection are known and PC
performance (and also Internet traffic) has increased a lot since the
introduction of TCP - do you think that the original checksum algorithm
is
On Thu, 17 Nov 2005, Andreas Bartelt wrote:
Hi,
Tobias Weingartner wrote:
On Thursday, November 17, Andreas Bartelt wrote:
As much better algorithms for error detection are known and PC performance
(and also Internet traffic) has increased a lot since the introduction of
TCP -
[EMAIL PROTECTED] wrote:
Hi,
Damien Miller wrote:
...
[EMAIL PROTECTED] djm]$ netstat -sp ip | grep -E
'(bad.*checksum|total packets)'
61092730 total packets received
0 bad header checksums
wouldn't netstat -sp tcp | grep -E
'(bad.*checksum|total packets)' give
the output
Hi all,
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.
This algorithm looks so unreliable to me that it even can't protect
against some pretty simple errors, which (I suppose) also could occur
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
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.
This algorithm looks so unreliable to me that it even can't protect
against some pretty simple errors,
Hi,
Ted Unangst wrote:
...
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.
thanks for the interesting paper. I now understand why it makes sense to
use a checksum at
On 11/17/05 00:39, Andreas Bartelt wrote:
As much better algorithms for error detection are known
What's better? Can those algorithms run with only a few hardware gates at 10Gbit
speeds too?
and PC performance (and also Internet traffic) has increased a lot since the
introduction of TCP
On Thu, 17 Nov 2005, Andreas Bartelt wrote:
As much better algorithms for error detection are known and PC performance
(and also Internet traffic) has increased a lot since the introduction of TCP
- do you think that the original checksum algorithm is still the best choice
in terms of a
10 matches
Mail list logo