On Wed, Mar 10, 2010 at 7:08 PM, gonzalo diethelm wrote:
>> One solution to this is a last-value cache whereby subscribers get the
>> last version of messages matching their subscriptions, when they
>> connect.
>
> This is something that would have to be added internally to 0MQ, right?
IMO this
> One solution to this is a last-value cache whereby subscribers get the
> last version of messages matching their subscriptions, when they
> connect.
This is something that would have to be added internally to 0MQ, right?
--
Gonzalo Diethelm
-
Declara
One solution to this is a last-value cache whereby subscribers get the
last version of messages matching their subscriptions, when they
connect.
On Wed, Mar 10, 2010 at 2:55 PM, Martin Sustrik wrote:
> gonzalo diethelm wrote:
>
>> Ok, that makes perfect sense now. And the reason this is not appar
gonzalo diethelm wrote:
> Ok, that makes perfect sense now. And the reason this is not apparent
> for Upstream / Downstream sockets is because they queue any unsent
> messages, so all messages are eventually sent after a successful
> reconnection, right?
Exactly.
> So I guess it is not a bad ide
> > 2. If the sender sleeps, say, 50 ms, the receiver misses a few of
the
> > initial messages sent by sender.
>
> That's because delay between two subsequent attempts to reconnect is
set
> to 100ms. See src/config.hpp:
>
> // Maximal wait time for a timer (milliseconds).
> max
gonzalo diethelm wrote:
> But now sender sleeps after binding to the PUB socket and before it
> starts sending messages. There are two cases happening here:
>
> 1. If the sender sleeps any amount of ms above 100, the receiver gets
> all messages.
>
> 2. If the sender sleeps, say, 50 ms, the rece
> > But I run the receiver first, THEN run the sender (sorry if that was
not
> > clear). In that case, shouldn't the receiver get ALL messages sent
by
> > the sender?
>
> It takes some time to connect. Thus when you start the sender, it'll
> bind to an interface a starts sending messages. In say 5
gonzalo diethelm wrote:
> But I run the receiver first, THEN run the sender (sorry if that was not
> clear). In that case, shouldn't the receiver get ALL messages sent by
> the sender?
It takes some time to connect. Thus when you start the sender, it'll
bind to an interface a starts sending mes
ar 10 04:45:24 2010
Subject: Re: [zeromq-dev] Is Pub/Sub unreliable
Emit Sorrels wrote:
>> This works erratically. Sometimes receiver receives less than 20
>> messages; sometimes it receives NONE.
>>
>> Is it the case that PUB/SUB sockets are unreliable? This is sort of a
Emit Sorrels wrote:
>> This works erratically. Sometimes receiver receives less than 20
>> messages; sometimes it receives NONE.
>>
>> Is it the case that PUB/SUB sockets are unreliable? This is sort of a
>> surprise to me... If they are not, what could explain this behavior?
>> Thanks in advance.
On Tue, Mar 09, 2010 at 07:26:34PM -0300, gonzalo diethelm wrote:
> I wrote two small apps: one binds a PUB socket to an endpoint and sends
> N messages to it; the other connects a SUB socket to that same endpoint
> and receives N messages. The sender optionally can wait a certain amount
> of ms be
I wrote two small apps: one binds a PUB socket to an endpoint and sends
N messages to it; the other connects a SUB socket to that same endpoint
and receives N messages. The sender optionally can wait a certain amount
of ms between each send, and it always waits for 60 seconds at the end.
I am attac
12 matches
Mail list logo
