OK, here's my proposal: https://github.com/zeromq/libzmq/pull/1258

On Wed, Nov 12, 2014 at 9:24 AM, Frank Hartmann <sound...@gmx.net> wrote:
> Pieter Hintjens <p...@imatix.com> writes:
>
>> That bug hasn't been fixed IMO.
>>
>> So what you're saying is that simply doing a "sleep (n)" inside
>> zmq_ctx_term would actually work better than LINGER n seconds (where n
>> is less than infinity)... LOL.
>
> Hi,
>
> not really I meant:
>
> ----------------------------------------------------------------------
> set_linger(n);
> zmq_ctx_term();
> ----------------------------------------------------------------------
>
> is the same as:
>
> ----------------------------------------------------------------------
> internally_stop_sending_msg_and_drop_queued_msg();
> set_linger(0);
> sleep(n);
> zmq_ctx_term()
> ----------------------------------------------------------------------
>
> At least that is my suspicion. Probably for DEALER/ROUTER, but I do not
> know if at both ends or not. So there is much behaviour to explore and
> document...
>
> Based on above I meant further setting LINGER to any other value as '0'
> or 'inf' is pointless.
>
> So while 2 seconds or 30seconds from
> https://github.com/zeromq/libzmq/pull/1253 might make sense from
> documentation point of view, in practise it does not help as the
> implementation seems to be broken.
>
> And even if libzmq would work as documented the apprach sounds
> racy. Basically I think there will be no guarantee that a message of any
> size will be delivered in any amount of time.
>
> We used ZMQ for short-living sessions(exchange data between processes
> over TCP on localhost for a few seconds, then one or both processes
> would stop), so in order to achieve delivery of all messages if one
> endpoint wants to disconnect, I implemented a special 'exit'-handshake,
> so that both processes could deal with the situation.
>
> So I think too that "Any reliable protocol has to do handshaking, as we
> already know."  from
> https://github.com/zeromq/libzmq/pull/1253#issuecomment-62477269
> is the way to go.
>
> kind regards
>   Frank
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to