On Sat, 21 Aug 1999 02:07:47 +0900 
 itojun@iijlab.net wrote:

 > 	Under the current behavior, I agree.
 > 	Even if we keep dangling syn cache entries after closing listening
 > 	socket, it buys us nothing at all.  This is because in{,6}_pcblookup
 > 	will fail in early stage of tcp_input(), so dangling syn cache
 > 	entries will never be looked up.
 > 
 > 	However, current behavior is different from the behavior we had
 > 	prior to syn cache.  Prior to syn cache, sonewconn() is called right
 > 	after SYN is received (TCP/IP illustrated p931), so, once SYN is
 > 	received listening socket is free to go away while accepted socket
 > 	will persist.  If we want to go back to old behavior for some reason
 > 	(of course with protection against syn flood attack), we should not
 > 	remove syn cache entries.  Instead, we need some trick in tcp_close(),
 > 	to preserve listening socket somehow, until all syn cache entries
 > 	go away (no new syn cache entry should be generated, though).
 > 	I'm not really sure which behavior is desirable.

I don't think the old behavior is really correct.  It almost seems to me
as if the old behavior could leave waiting-to-be-accepted sockets laying
around will will never be.

In your original example in this thread, what happens if the server
application exits because of a signal before accept()'ing the new
connection, assuming the old sonewconn() behaviour in 4.4BSD?

It seems to me that if you cause the listen socket to persist until all
of the SYN cache entries go away, then you have now created a situation
where you cannot necessarily restart a server daemon until all of the
entries time out (and thus release all references to the listen socket,
causing it to be released).

 > 	I agree, but I'm not completely sure.  Per-listen socket queue
 > 	needs to be hash table, not simple linked list (linear search on
 > 	per-listen socket queue can be more expensive than current syn hash
 > 	lookup).  Having small hash tables for each of the listenig sockets
 > 	may eat more memory in kernel space.
 > 	It really depends on distribution of syn packets, and its src/dst
 > 	address pair...

Perhaps something like a per-listen-socket queue of associated SYN
cache entries ... so you just have immediate access to them when
you nuke the listen socket...

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>