Subject: Re: [review please] tcp syn cache cleanup code for sc->sc_so
To: Jason Thorpe <thorpej@nas.nasa.gov>
From: None <itojun@iijlab.net>
List: tech-net
Date: 08/21/1999 03:16:11
>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?

	old behavior, without syn cache:
	- SYN packet comes: socket structure will be copied by sonewconn(),
		send SYN ACK
	- listening socket closed: copied socket structure will persist
	- ACK arrives: copied socket strucuture will handle it normally
	new behavior, with syn cache:
	- SYN packet comes: syn cache entry will be created, send SYN ACK
		syn cache entry has a pointer to listening socket
		(=> ipsec code needs policy info)
	- listening socket closed: syn cache entry persists, pointer from
		syn cache entry to listening socket becomes dangling pointer
		(** need cleanup here)
	- ACK arrives: as listening socket is not there, goto dropwithreset

	The original problem I needed to solve was to cleanup any dangling
	pointers from syn cache entries to socket structure (**).  If we have
	old sonewconn() behavior, we do not need syn cache and we have no
	pointer cleanup problem.  I will use the socket structure copied by
	sonewconn() for looking up policy, not the listening socket.

>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 should have written "dummy listen socket" or "zombie listen socket".
	behavior should be like this:
	- SYN packet comes: syn cache entry will be created, send SYN ACK
		syn cache entry has a pointer to listening socket
		(=> ipsec code needs policy info)
	- listening socket closed: as syn cache entries need the listening
		socket, it will persist as zombie listening socket.
	- ACK arrives: zombie listening socket is looked up, connection
		will be accepted by checking syn cache entries

	So, even if we use syn cache, we can preserve old behavior.
	This would add too many complexities so I think we do not need to
	keep zombie listening socket.  We just need to nuke syn cache entries
	when listening socket goes away.

itojun