On 21 January 2015 at 01:36, Martin Thomson <martin.thomson@gmail.com> wrote: > > = Section 5.1 = > > "WINDOW_UPDATE or RST_STREAM frames can be received in this state > > for a short period after a DATA or HEADERS frame containing an > > END_STREAM flag is sent. ... > > endpoints MAY choose to treat frames that arrive a significant > > time after sending END_STREAM as a connection error > > (Section 5.4.1) of type PROTOCOL_ERROR." > > > > Can some ballpark guidance be given about how long "a short period" and > > "a significant time" are expected to be? Or how an implementation might > > calibrate these values? > > This is tricky; a good implementation will maintain shallow send > buffers and so be able to respond to changes in state fairly quickly. > In that case, one RTT is enough. However, keeping a buffer protects > against local hiccups and as soon as you buffer anything, you are > potentially subject to long stalls if packet loss or other problems > occur. > > Maybe "significant" is 1RTT plus a complete CWND worth of received > data. Even then I think that some implementations could buffer more > than that to allow them to encipher larger blocks. As I've said before, I think we really need to do more to simplify the CLOSE state, as 7 paragraphs to describe the handling of the terminal state is too complex. Currently it is as if the TCP RFC left TIME_WAIT and CLOSE_WAIT as an implementation specific exercise. It is a very common problem for OS's to have issues with large numbers of sockets left in TIME_WAIT, so I can similar issues with servers keeping stream in memory in CLOSE_before_the_undefined_short_period. We could introduce a RESET state, which means that CLOSE will always be entered gracefully and there will be no late packets. RESET could then have defined timeout before entering CLOSE. Alternately, we could just define all the frame handling in CLOSE and let that take place for all time so that CLOSE is not a stateful state. It is mostly ignore, other that PP which is reset. -- Greg Wilkins <gregw@intalio.com> @ Webtide - *an Intalio subsidiary* http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales http://www.webtide.com advice and support for jetty and cometd.
Received on Friday, 23 January 2015 11:14:06 UTC