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

[Greg Wilkins <[e-mail]>]

Salvatore Loreto wrote:
> 
> just to make order in this particular thread discussion
> 
> as I understood, two different problems have been arised
> 
> 1) "safely" shutdown a websocket connection.
>      The possibility to lose data while closing a TCP connection is a
> well-known problem,
>      as has also been discussed and described in the thread.
> 
>      Some people think there is a value to add to the spec gracefully
> shutdown the websocket connection.
> 
>      However I haven't seen a clear consensus on it.
> 
>      So please if you have an opinion on this, speak up!!!


I've spoken enough in support of orderly close... so I 'll let others
speak up here.



> 2) what happen if/when the connection is lost; this can happen for
> several different reasons:
>    e.g. a NAT restarting, the mobile terminal go out of network coverage
> etc.
> 
>     here we have different sub problems in my opinion:
>     2.1) how detect as fast as possible that the connection has been lost
>     2.2.) what to do after have reconnected.
>     Are those something people think is important to spend cycles on??

Yes.

I think that it is very important for an endpoint and/or application to be
able to distinguish between:

   a) orderly close in response to an application request, in which case
      the app probably should not attempt to re-establish.

   b) close in response to an error (message too large or similar),
      in which case the app/endpoint should refrain from any
      retries it might otherwise have attempted.

   c) close in response to an idle timeout.
      in which case the endpoint should not recreate the connection.
      But an application might, if presence is required.

   d) unexpected close due to some failure (or undisclosed intermediary
      timeout).     In this case an application may wish to retransmit
      messages (either all recent idempotent messages or un-acked
      non-idempotent messages).

   e) inability to open a connection due to no connectivity.  In this
      case an app might do a retry at regular intervals

   f) inability to open a connection due to permission denial from the
      server.  In this case, the app probably wants to alert the user
      of the error.


I think that the endpoint code will be able to do very little
of the handling of reconnections and retries, simply because
it does not know enough about the messages.   So the application
will have to decide about reconnects and retransmits, but it
currently does not have the information needed to make those
decisions.


I think fail fast is also desirable, but I'm not sure it is so
desirable that I'd advocate a regular keep-alive message just
failure detection.  But if keep-alive messages are required to
keep open connections through transparent proxies, then it could
be 2 birds with 1 stone.

cheers