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

[Jamie Lokier <[e-mail]>]

Francis Brosnan Blazquez wrote:
> Hi Greg,
> 
> > TCP does have  difference between an orderly shutdown (FIN),
> > error shutdown (RST) and timeouts.

Btw, TCP is missing one: Distinguish between application crash and
application orderly shutdown.  Both result in FIN.

And TCP is actively unhelpful with it's TCP RST data-discard hazard.

> > 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...

Think about what happens when:

   - Assume an app which is all request-response, originated by the client.
   - Assume some requests are state changing ("INSERT INTO...").

   - client opens a WebSocket
   - sends a few requests to the server, server responds
   - after 30 seconds, the server decides to close the connection
     because it's not being used(*)
   - at around the same time, the client sends another request
   - client receives TCP RST from the server, as "connection reset" error

(*) Note that servers which don't send or expect keepalive probes
    *must* timeout connections like that, because it's impossible to
    tell the difference between an idle connection and one which
    has gone away due to the network.

Two problems happen:

   1. What does the client do with that last request?  It's not safe to open
      a new connection and repeat it, because it might be acted on twice.
   2. What happens to the response to the second to last request?
      It gets truncated, because it was unlucky enough that the last
      packets were delayed by >30 seconds.

Now, I know how to use WebSocket to solve both of those, and so do you.

Anyone serious about their WebSocket app will handle it.  We don't
need to worry about them.

But seriously, do you think the millions of authors who write little
web applications in a few pages of Javascript and a few pages of Python
will think of that, or even care?  It almost never happens, and it is
much rarer on the LAN where they are testing.  It'll be one of those
rare glitches that are left broken, like random double-posting to a blog.

Mostly it only causes problems for the unlucky schmuck on some obscure
network in a remote location on a 56k modem - or an over-subscribed
mobile network; inevitably the application author doesn't experience
the problem, and it settles on the bugzilla (if there is one) as
"CANNOT REPRODUCE".

And, getting it right does demand a little more mystical TCP knowledge
than most web app authors will ever care about.  Heck, half the people
I know who write TCP apps don't realise write boundaries aren't
preserved (because their app works fine on Windows over a LAN except
for those pesky rare unexplainable lockups...) - and those are people
writing socket apps in C who should know better, not web app authors.

I wouldn't mention _those_ apps and authors, except that it's been
explicitly spelled out elsewhere that they are a target audience for
using WebSocket directly.

> 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. 

Orderly close is a bit subtle, and the failure modes when it's done
wrong don't occur for everyone because they are quite dependent on
network configuration.

It's not _complicated_, it just involves non-obvious issues - the TCP
reset hazard being totally non-obvious.

I agree that orderly close can be overlaid on top of WebSocket
(with a small overhead).

But do we really want to encourage fragile applications, because many
of them will be written by people who don't think about this sort of
thing every day like us protocol designers do?

I think that's what Greg's getting at with deciding the base requirements.

-- Jamie