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

[Justin Erenkrantz <[e-mail]>]

On Fri, Jan 29, 2010 at 10:43 PM, Maciej Stachowiak <[e-mail]> wrote:
> 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?)

It depends upon what level of "reliability" you are looking for.  If
you are aiming for the "common" case, the answer to both is "yes".

However, edge cases make the answer "no" - it is quite possible to
have "lost" responses that a server actually sends, but the client
will never see.  Some versions of httpd would aggressively close the
server-side socket "too soon" so that the FIN/ACK cycle happens too
soon and unread data is lost - so httpd has a bunch of logic to hold
off on the close() call until a set time has elapsed so as to minimize
this risk.  (See
https://issues.apache.org/bugzilla/show_bug.cgi?id=35292 for one
description.)

The explicit channel close semantics and ACK process of BWTP is, IMO,
a particularly elegant solution here.

HTH.  -- justin