[zeromq-dev] several binds on the same ipc

[MinRK]

On Thu, May 24, 2012 at 7:17 AM, Tarek Ziadé <tarek at ziade.org> wrote:

>  On 5/24/12 2:17 PM, Tarek Ziadé wrote:
>
> Hey
>
> I am trying to solve an issue I have with a broker that opens a zmq
> router socket and just relay calls to workers via a socket dealer.
>
> The problem is that I don't know how to prevent a second broker to bind
> itself to the same ipc.
>
> Consider the following scripts where I isolate the issue:
>
> The server: http://tarek.pastebin.mozilla.org/1649175
> The client: http://tarek.pastebin.mozilla.org/1649176
>
> If I run them they happily interact. Now I can run a second server. It
> will bind the socket but won't do anything or even error out.
>
> If I stop the first server, the client will simply lock, as it seems to
> have a sticky connection to the first server - and won't communicate
> with the second server until I restart it.
>
> As far as I understand, we can only bind() **once**, which make sense.
>
> So my question is - shouldn't the second attempt to bind() the socket
> raise an error ? maybe this is related to the python binding ?
>
> If not, how can I know if there's already a socket bound to the ipc ?
>
> Cheers
> Tarek
>
>  After a bit of discussion on IRC, this seems to be a pyzmq issue, where
> the second
>
> bind() call does not raise an error, as expected.
>
> So I opened a bug there: https://github.com/zeromq/pyzmq/issues/209
>

As discussed there, it has been confirmed that pyzmq behaves no differently
from C in this regard, so it is not related to pyzmq.

You can bind multiple sockets to a single ipc channel, but only one will be
active at a time.

-MinRK


>
>
> Cheers
> Tarek
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120524/9c8c03db/attachment.htm>