Subject: Re: erroneous ack packet, ideas please?
To: Andrew Brown <email@example.com>
From: Jason Thorpe <firstname.lastname@example.org>
Date: 07/10/1997 14:25:31
On Thu, 10 Jul 1997 15:44:10 -0400 (EDT)
email@example.com (Andrew Brown) wrote:
> i've got my box at home to the point where accept() returns after the
> first syn (via a setsockopt() on the "master" socket), subsequent syns
> are simply "absorbed", and i can then *choose* to keep the connection
> and finish the tcp handshake (via an ioctl() on the "slave" socket).
> after this, it behaves like a completely normal socket except for the
> extra ack packet that i don't understand.
Hm... this is very interesting...
As some may have noticed a couple of weeks ago, I have been doing some
work on the Borman/BSDI SYN "cache" code (it's horribly misnamed; it's
really just compressed state for TCP). On the development branch, the
current working code doesn't create a socket until the 3-way handshake
is _complete_. This is diffferent from how the code works in BSD/OS,
and the patches Borman posted relative to 4.4BSD-Lite, where it would
create a socket, and if that failed, presumably because the queue limit
had been reached, place the SYN in the "cache".
In some ways, it has simplified the code somewhat (tcp_input() no longer
handles the TCPS_LISTEN state at all; it is now only used to indicate
that a socket is listening, for the benefit of netstat.
Eventually, I want to keep TIME_WAIT in compressed state, as well;
currently, TCBs in TIME_WAIT eat up slots that count against the
socket queue limit. If you delete the socket when it enters TIME_WAIT,
you can accept more connections, which is winful for busy mail and www
I think implementing "eager listeners" would be fairly easy to implement
in this new way of handling embryonic connections, as well... just check
for the option set on the listening socket, and Do The Right Thing (which
is how you do it, now, I guess :-)
Anyhow, I plan on doing some more testing of the SYN_cache_branch this
week (I have been running it on all of my systems here, without problems,
but I want to test it in a slightly more "real" environment first), and
pulling it into the trunk very soon.
Jason R. Thorpe firstname.lastname@example.org
NASA Ames Research Center Home: 408.866.1912
NAS: M/S 258-6 Work: 415.604.0935
Moffett Field, CA 94035 Pager: 415.428.6939