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 - To unsubscribe from this list: send the line "unsubscribe dccp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
