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

[Greg Wilkins <[e-mail]>]

Francis,

I'm all for protocol layering and if features can be
implemented in a subprotocol, then they probably should be.

However, we don't want to force subprotocols into having to
re-implement TCP with timeouts, keep-alives, acks etc.
if a few simple features in the base protocol can expose
more of TCP/IP's capabilities to the layered protocol.



In the case of orderly close, a layered protocol
could implement its own orderly close.  But it would
still have a problem with error closes, as the
servers response to all sorts of issues is simply
to close the socket.

If my layered protocol does:

  websocket.send(moderatelyLargeMessage)

and then receives a onclose callback before any
acks or orderly close are received, then the layered
protocol knows there has been a failure, but does not
know the cause.  So it will probably open another
connection and send the moderatelyLargeMessage again....
and again... and again....

If it new that the message was being rejected by
the other endpoint rather than a network failure,
then it would know not to retry.

The same problem goes if the user opens too many
tabs and exceeds some connection limit on the
server. The sub protocol will be unable to tell
the difference between that and network failure.



TCP is a reliable transport, but if a layered protocol
is unable to see the difference between an orderly close,
and error close and a network failure, then it cannot use
TCP reliably.

If I do a websocket.send(message) and then a short
time later I get a websocket.onclose() call back, then
I have no idea if that message was delivered.

So websockets is obscuring the reliable capabilities
of TCP.     As I've said before, it's more like
webserialport than websocket and subprotocols will
need to be more complex as a result.


regards





Francis Brosnan Blazquez wrote:
> Hi Greg,
> 
>> TCP does have  difference between an orderly shutdown (FIN),
>> error shutdown (RST) and timeouts.
>>
>> So if you want to be like TCP, then you'll have those
>> concepts.
> 
> Why not?
> 
> I think people is interested on Websocket because they will layer its
> favourite protocol on top of it. I not stating I'm against this but I
> still don't see this point and how it would improve the protocol...
> 
> In other words, people that cares about orderly close will use a
> protocol on top of Websocket that provides graceful close (like BEEP)
> and people that do not cares about this will have an additional feature
> not requested....so it looks to me both kind of users won't use this.