This isn't directly related to ZeroMQ, but it is somewhat relevant now
given A) the addition of the (yet unimplemented) heartbeating feature in
ZMTP/3.0 and B) the Windows TCP keepalive parameters fix I committed
recently.
The question is: has someone here used TCP keepalives as a substitute
fo
It makes sense, and I'd try this; the timeout should be in msec, to be
consistent with other duration arguments. You can take any of the
existing socket options like ZMQ_SNDBUF as a template, and make a pull
request.
On Mon, Dec 30, 2013 at 11:29 PM, Alex Grönholm
wrote:
> This isn't directly rel
02.01.2014 15:59, Pieter Hintjens kirjoitti:
> It makes sense, and I'd try this; the timeout should be in msec, to be
> consistent with other duration arguments. You can take any of the
> existing socket options like ZMQ_SNDBUF as a template, and make a pull
> request.
Wouldn't it be enough to docu
Seconds is fine for this case but surprising overall since all other
durations in the API are in msec.
I'm not sure what you mean about backwards compatibility.
On Thu, Jan 2, 2014 at 7:55 PM, Alex Grönholm wrote:
> 02.01.2014 15:59, Pieter Hintjens kirjoitti:
>> It makes sense, and I'd try this
On 3 Jan 2014, at 7:48 am, Pieter Hintjens wrote:
> Seconds is fine for this case but surprising overall since all other
> durations in the API are in msec.
>
> I'm not sure what you mean about backwards compatibility.
>
> On Thu, Jan 2, 2014 at 7:55 PM, Alex Grönholm
> wrote:
>> 02.01.2014
02.01.2014 23:48, Pieter Hintjens kirjoitti:
> Seconds is fine for this case but surprising overall since all other
> durations in the API are in msec.
>
> I'm not sure what you mean about backwards compatibility.
As it stands, the TCP keepalive intervals are given in seconds on the
vast majority
The existing apps do not use yet 0MQ heartbeating anyhow, so there is no
"backward compatibility" issue.
I support Matt point of view to keep libzmq homogeneous. I add that I
don't like specifications or performances degradations when it can be
avoided. There are standard usages that sustend y
What should be the behavior if the user specifies 1500ms but the underlying
OS only supports seconds granularity?
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
On Fri, Jan 3, 2014 at 11:54 AM, KIU Shueng Chuan wrote:
> What should be the behavior if the user specifies 1500ms but the underlying
> OS only supports seconds granularity?
Presumably to round up. What if the user specifies 1ms? Rounding down
would not work.
A heartbeating option should probab
On 01/03/2014 02:03 AM, Alex Grönholm wrote:
> As it stands, the TCP keepalive intervals are given in seconds on the
> vast majority of operating systems.
Furthermore, if the peer is unresponsive then additional probes will be
sent at regular intervals before the TCP keepalive mechanism reports a
There are two approaches that can be used if an API specifies time more
finely than the system supports.
First, you can specify in the API that this is only a hint. This is
accurate but it makes it more difficult to reason about and debug the
actual behavior.
Second, you can have the method retur
Yes, we can do lots of things. Most of them are instant technical
debt. I'm going to repeat like a broken robot: fix only problems that
are provable, and fix those in a minimal plausible fashion. I won't
believe the difference between 1.5 and 2.0 seconds heartbeating is
significant unless I see a r
i’m sorry, maybe i skippe dteh very start of this thread, but why are we even
considering
heartbeating using transport layer stuff? it seems contrary to the spirit of zmq
and its orthogonality to transport choice.
is the driving use case documented/described somewhere?
On Jan 3, 2014, at 9:31 AM
03.01.2014 14:45, Bjorn Reese kirjoitti:
> On 01/03/2014 02:03 AM, Alex Grönholm wrote:
>
>> As it stands, the TCP keepalive intervals are given in seconds on the
>> vast majority of operating systems.
> Furthermore, if the peer is unresponsive then additional probes will be
> sent at regular inter
03.01.2014 11:24, Laurent Alebarde kirjoitti:
The existing apps do not use yet 0MQ heartbeating anyhow, so there is
no "backward compatibility" issue.
What 0MQ heartbeating? There is no 0MQ heartbeating implemented
anywhere. I'm talking about TCP keepalives which is a whole different beast.
TCP
15 matches
Mail list logo
