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

[Maciej Stachowiak <[e-mail]>]

On Jan 29, 2010, at 2:55 PM, Greg Wilkins wrote:

> 
> Because there is no orderly close mechanism, we have to keep
> our own close handshake and implement our own acks for our
> reliable messaging extension (which currently batches acks
> into the equivalent of a long poll.... I guess we could
> re-invent TCP inside websocket and do message by message
> acks... but what a waste!).
> 
> So if you look on the wire of cometd running over websocket,
> it just looks like long polling.  We use the same /meta/connect
> long poll message as a keep alive and as our ack carrier.
> 

I think it's a flaw in the WebSocket protocol that you can't be sure what messages were delivered successfully without inventing your own client-level ACK protocol. This seems like a shame because TCP already has per-message ACKs and reliable delivery, but we're actually losing this capability at the higher level.

I'm curious about a couple of things:

1) Do OS TCP stacks expose enough information to socket-level clients to determine what has definitely been sent when a TCP connection is closed?

2) Is a TCP-level ack sufficient for this purpose? (Or would clients for reliable message delivery want a full end-to-end ack from the receiving application?)


If the answer to both of these questions is "yes", then we only need a change to the client API, not the protocol, to have built-in reliable message delivery. We could just look at what has been ack'd at the TCP level to determine what has been delivered.

If the answer to either is "no", then we should consider whether acks could be added to the protocol. We should probably think about piggybacking them on messages and having some sort of close handshake rather than sending wholly separate ack messages. Also, I'm pretty sure the client needs acks from the server, but is the opposite required? Do servers need to know if the client got a message?

Once we have a strawman proposal for how acks could work, the next question is whether this needs to be in the 1.0 version of the protocol, or whether there is a clean and compatible way to add it in a later revision.

Regards,
Maciej