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

[Maciej Stachowiak <[e-mail]>]

On Feb 2, 2010, at 8:44 PM, Greg Wilkins wrote:

> 
> ... and I'd just like to repeat that I believe it is important to
> have a mechanism where an intermediary can initiate a clean shutdown.

In the case of an SSL proxy, there's no obvious way to do that, since an intermediary can't inject anything into the SSL stream. Or at least, we'd have to break through the SSL layer for this, which I expect would be hard to implement. For other intermediaries, I think we would have to design how they can participate at all, before worrying about how they can initiate a close.

Regards,
Maciej

> 
> cheers
> 
> 
> 
> Maciej Stachowiak wrote:
>> 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
> 
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi