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

[Mridul Muralidharan <[e-mail]>]

Detection of lost messages is slightly harder problem than orderly close.
In xmpp space, where we had to deal with it, the base protocol mentions about orderly close - there are extensions which deal with detecting (on reconnect) if server/client received all messages sent & retransmit those : but this also depends on whether the server/client supports it, etc.
Actually detection for need for retransmission for httpbind is different from message level retransmission ... but I am not getting into that here.


Regards,
Mridul



----- Original Message ----
> From: Maciej Stachowiak <[e-mail]>
> To: Jamie Lokier <[e-mail]>
> Cc: Hybi <[e-mail]>; "Thomson, Martin" <[e-mail]>
> Sent: Wed, 3 February, 2010 7:15:18 AM
> Subject: Re: [hybi] Reliable message delivery (was Re: Technical feedback.)
> 
> 
> On Feb 2, 2010, at 4:54 PM, Jamie Lokier wrote:
> 
> > 
> > In a nutshell, there are *two* distinct uses for signalling clean shutdown:
> > 
> >    1. To avoid the TCP reset hazard.
> > 
> >    2. To signal that it was a clean shutdown, so there is no protocol
> >       uncertainty about what has been processed / what can be retried
> >       on another connection.(**)(***)
> > 
> > shutdown() and lingering close does deal with 1, but it isn't reliable
> > for 2 because of all the other things which can look like shutdown().
> 
> I think everyone agrees that we need to address #1. I also personally agree with 
> #2.
> 
> Also, there's a potential third use:
> 
> 3. Knowing the other endpoint has definitely received all of your messages sent 
> prior to the close.
> 
> I'm not sure, but I think to achieve #3 may require at either a 3-way close 
> handshake, or a close reply message distinct from close initiation. Consider the 
> case both endpoints initiate close at the same time and their messages cross. 
> Then one endpoint may think it is the close initiator, and when it sees the 
> close from the other side, it may think the other side got all of its messages 
> successfully. Another possibility is to make the close response message look 
> different from the close initiation message. Then you can distinguish a close 
> reply from simultaneous close. I haven't yet analyzed whether this is fully 
> sufficient. We may need to explicitly identify the last message received by each 
> side somehow.
> 
> Clearly there are subtle issues here, and we'll have to carefully analyze what 
> can go wrong in any close protocol.
> 
> Regards,
> Maciej
> 
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi



      Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://downloads.yahoo.com/in/internetexplorer/