Greg Wilkins wrote:
> Anne van Kesteren wrote:
> > On Mon, 01 Feb 2010 20:33:49 +0100, Salvatore Loreto
> > <salvatore.loreto at ericsson.com> wrote:
> >> 1) "safely" shutdown a websocket connection.
> >> The possibility to lose data while closing a TCP connection is a
> >> well-known problem,
> >> as has also been discussed and described in the thread.
> >>
> >> Some people think there is a value to add to the spec gracefully
> >> shutdown the websocket connection.
> >>
> >> However I haven't seen a clear consensus on it.
> >>
> >> So please if you have an opinion on this, speak up!!!
> >
> > We discussed this on IRC earlier today. The idea is to introduce a frame
> > for closing. If A wants to close the connection it transmits 0xFF 0x00.
> > Once the B receives that and has no more messages to transmit it
> > transmits 0xFF 0x00 as well. When A receives that it knows it can close
> > the connection.
>
> So I think talking implementation before we have requirements is
> premature. While I'm sure that a solution might look something like
> that, there are other use-cases to be considered that might need
> a bit more content in the frame.
>
> Intermediaries should be able to initiate and orderly close,
> so they would need to send another message to either/both
> endpoints, which would then initiate the normal orderly close.
>
> I think there is also a need for an error close. Currently all errors
> are handled by just closing the connection, but if that looks like
> a network failure, then a client might retry. If the error is due
> to a message being too large, or too many connection or some other
> server resource limitation, then the last thing we need is the
> client doing a retry.
Yesterday I decided to analyse Ian's question "does it work", and
found that in some cases, the above method doesn't quite. It depends
on what, exactly, the orderly close is meant to ensure.
Interestingly, the cases I found are different from Greg's list above.
So I agree with Greg there. Let's agree the requirement for orderly
close (it seems like maybe we have, just not formally), and we'll look
at those implementation cases.
I won't object if Ian wants to add something preliminary to the draft,
so long as it's possible to add corrections after.
I hope to post my analysis in a day or two.
> > This would not be required of servers however as there are scenarios
> > (e.g. news tickers) where it does not really matter whether everything
> > has been received by the client.
>
> I think it would still be good for the newsfeed client to know if
> the connection was severed normally (ie there is no more news today)
> or if it just failed for some other reason (and thus it might
> retry to connect).
It's _very_ useful to know when it's safe to retry things. Apart from
avoiding the TCP reset hazard causing truncated delivery, this is the
other useful reason for orderly close.
(E.g. see HTTP persistent connections, especially the reason POST needs
a new connection every time to be safe. E.g.
see http://www2.tw.squid-cache.org/mail-archive/squid-dev/199812/0036.html
If HTTP had orderly close, POST could be used on persistent and even
pipelined connections.)
When it's not known, and a request is unsafe to repeat, generally you
have to report an error to the user, or go wrong.
Ideally, a protocol ensures that uncertainty can only occur on real
and unexpected transport errors (and then uncertainty is theoretically
unavoidable anyway).
The following is a good basis for apps to layer higher level protocols
on (like automatic safe retries):
In the absence of errors (network, application and OS), ensure the
receiving side knows that a close was intentional from the sending
app (e.g. not crashes, not TCP proxy shutdowns), and ensure data
sent before the close is transmitted reliably.
Let's make sure this part of WebSocket Just Works(tm). It's got a bit
too much subtlety, and requires a bit too much low-level knowledge, to
push the responsibility onto each application designer.
-- Jamie
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.