Re: [hybi] Reliable message delivery (was Re: Technical feedback.)

["Thomson, Martin" <[e-mail]>]

> That is fine for TCP; the 0xff 0x00 is redundant.

What I get from this is that TCP connections haemorrhaging data can be solved without support in the higher layer - all that it requires is that the implementation of the next layer be aware of the limitations of TCP and that it uses shutdown(...) or whatever is necessary.

That's a pretty strong argument against putting specific close semantics in WS.  I don't buy the "let's make our protocol transport-layer-agnostic argument"; that only leads to the protocol picking up unnecessary baggage. 

If an explicit close notification is required for an alternative transport, then let those who are porting the protocol to that environment add a shim for that purpose.

Having text that explains the assumptions of the current solution and maybe even suggests an implementation option (preferably by reference) seems most appropriate to me.

--Martin

 
> Please note: The close-frame is *not* for acknowledgement of prior
> messages.  It is a mechanism to prevent closes from turning into
> "connection reset" TCP errors and the data-discarding behaviour.  It
> would be *most unwise* of an endpoint to refuse to send the
> close-frame (or shutdown) because it was keeping it to acknowledge an
> expected message - because that would force the other end to keep a
> connection open for a long timeout, when receiving close and lack of
> an expected message is precisely a situation when connections should
> be closed quickly because an unrecoverable error has occured.

This too is useful information - but this could be applied to the FIN, rather than the close frame.  That is, if you receive a FIN, that doesn't mean that the other peer received everything that you've already sent.  When you put it like that, it doesn't seem like much of a stretch ;)