[zeromq-dev] strange behavior with pub/sub sockets (when pub connects)

[Robert W]

Interesting, so if you want a reliable 1-to-1 pub/sub you could have your
publisher do the connecting. It looks like you don't even miss the first
couple messages either (no synchronization needed).

The rebind thing is a bit bizarre. It actually blocks ad infinitum until I
kill the publisher (which connects). After that, the socket goes into a
TIME_WAIT state and then eventually clears up..

I can't make a completely reproducible case though. If I restart the
subscribing server (which binds) soon after it had stopped, then it's
usually able to reconnect without any issues. What do you think might be the
problem? (These two things might be related?)

On Thu, Apr 7, 2011 at 1:13 PM, Ian Barber <ian.barber at gmail.com> wrote:

> On Thu, Apr 7, 2011 at 5:58 PM, Robert W <robertwalters83 at gmail.com>wrote:
>
>> In this example, there is one publisher and one subscriber.
>> The publisher connects and the subscriber is the one that binds.
>>
>> It looks like the publisher acts like a durable publisher and does not
>> drop messages (even if there is no subscriber).
>> This is quite different from what the documentation says.
>>
>
> I suspect this is an effect of the slightly different way of treating
> connect/bind with regards to buffers - the publisher is trying to connect,
> retrying etc., hence has not dropped, while a bound one knows it has no
> connections, and can drop. If that's the reason, I can see the confusion,
> interesting side effect!
>
> The rebind thing, does that clear up if you wait a little bit, or does it
> block the port ad infinitum? It does take some time for the port to become
> free again, so an immediate reconnect might trigger a bind failure, a few
> people have hit that.
>
> Ian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110407/c8c7015b/attachment.htm>