[3514] in linux-net channel archive
Re: The crash 2.0 tcp program
daemon@ATHENA.MIT.EDU (Eric Schenk)
Wed Jun 26 21:59:58 1996
To: alan@lxorguk.ukuu.org.uk (Alan Cox)
cc: linux-net@vger.rutgers.edu, schenk@cs.toronto.edu, torvalds@cs.helsinki.fi
In-reply-to: Your message of "Wed, 26 Jun 1996 17:42:00 EDT."
<m0uZ2Li-0005FaC@lightning.swansea.linux.org.uk>
Date: Wed, 26 Jun 1996 20:16:16 -0400
From: "Eric Schenk" <schenk@cs.toronto.edu>
Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
>Ok this appears to run us out of buffers with one end of a connection in
>the state where bytes_rcv > max_unacked. This causes the following
>unfortunate sequence:
[nasty little sequence deleted...]
This might explain a couple of tcpdump's I've received that I
just couldn't understand. The obvious fix is to seperate the
setting of real delayed acks from the setting of a delayed
ack because we have no memory. Say introduce tcp_resend_ack()
which would take care of scheduling an ack if we can't get
enough memory. The alternative is to just drop the ack if
we haven't got enough memory, but I don't much like that alternative.
Anyone see a problem with this approach?
-- eric
