Re: [PATCH 3/10]: Dedicated auxiliary states to support passive-close

[Gerrit Renker <gerrit@erg.abdn.ac.uk>]

Quoting Arnaldo Carvalho de Melo:
|  > [DCCP]: Dedicated auxiliary states to support passive-close
|  > 
|  > This adds two auxiliary states to deal with passive closes:
|  >   * PASSIVE_1 (reached from OPEN via reception of Close) and
|  >   * PASSIVE_2 (reached from OPEN via reception of CloseReq)
|  
|  
|  Perhaps we should rename PASSIVE_1 (magic number) to PASSIVE_CLOSEREQ
|  and PASSIVE_2 to PASSIVE_CLOSE, and also CLOSEREQ to ACTIVE_CLOSEREQ?
No problems with the first two. With the third I was initially thinking
`this name is from the RFC', but the RFC didn't help much here and your
scheme makes the state much clearer - so, yes, I agree fully with that.
 
|  I'll defer these patches till we get some more discussion. There are
|  many more unrelated patches to work on after all :)
What kind of discussion were you thinking of: in a previous thread Ian and I
reached some agreement already that there is a problem here.

The problem really is in taking the RFC 4340 state machine at face value: if this
is done literally, short-lived connections will wipe the receive queue before the
userland application had a chance to read data; as documented on
	http://www.erg.abdn.ac.uk/users/gerrit/dccp/notes/closing_states/
If you don't believe this, it can readily be tested by writing a small test app which 
sends something like `hello world' to the server.
All data is seen on the wire, but never by the application.

A test app can be found in the directory misc/hello_world of
http://www.erg.abdn.ac.uk/users/gerrit/dccp/apps/dccp_applications_lib.tar.gz