[zeromq-dev] Bind, publish, unbind, repeat

Marcus Ottosson konstruktion at gmail.com
Fri Jun 20 13:05:05 CEST 2014


Hi Peter, thanks for your reply.

This makes sense, but I'm attempting to run an arbitrary number of peers
and they can't all be bound to the same port, can they?. I'm definitely no
expert, so do go basic on me, that is ok.

In a nutshell, I'm attempting to mimic real-life in which people
continuously broadcast information about themselves; their location,
appearance and so on and then having an arbitrary amount of spectators take
part in this information flow - i.e. the equivalent of looking out onto a
crowd of people.

I would understand if it isn't straightforward, but do you think there's a
way? I'd assume the traditional method would be to introduce a broker, but
I'd rather not as it violates the real-life equivalent. I'd like each
available peer (on a single workstation, this isn't to be run on a network)
to continuously broadcast information about themselves, without a central
broker.

Best,
Marcus


On 20 June 2014 11:57, Pieter Hintjens <ph at imatix.com> wrote:

> You are rather abusing the tcp:// transport, as well as the pub/sub
> metaphor. This simply will not work without artificial waits.
>
> Proper design would be: keep the socket bound, and send a message once
> a second. Subscribe, get one message, disconnect.
>
> On Fri, Jun 20, 2014 at 12:13 PM, Marcus Ottosson
> <konstruktion at gmail.com> wrote:
> > Hi all, first time on this mailing-list, let me know if anything is
> amiss.
> >
> > I originally posted on Stackoverflow but had previously seen mentions of
> > otherwise posting on an active mailing-list so here goes.
> >
> > Why isn’t this working?
> >
> > peer.py
> >
> > import zmq
> > import time
> >
> > if __name__ == '__main__':
> >     context = zmq.Context()
> >
> >     socket = context.socket(zmq.PUB)
> >
> >     while True:
> >         print "I: Publishing"
> >
> >         socket.bind("tcp://*:5555")
> >         socket.send_multipart(['general', 'Unique peer information'])
> >         socket.unbind("tcp://*:5555")
> >
> >         time.sleep(1)
> >
> > scanner.py
> >
> > import zmq
> >
> > if __name__ == '__main__':
> >     context = zmq.Context()
> >
> >     socket = context.socket(zmq.SUB)
> >     socket.setsockopt(zmq.SUBSCRIBE, 'general')
> >     socket.connect("tcp://localhost:5555")
> >
> >     print "I: Scanning 5555"
> >
> >     while True:
> >         message = socket.recv_multipart()
> >         print "I: Receiving: {}".format(message)
> >
> > I’m attempting to broadcast multiple peers over the same port, on the
> same
> > computer and have a single “scanner” listen in and “see” who is
> available.
> > Each peer would broadcast its contact information, a client would then
> use
> > the scanner to find out who is available and then use the broadcasted
> > information to connect via a REQ/REP channel.
> >
> > To make this work, I’ve attempted to quickly bind a PUB socket, broadcast
> > information about a peer, and then unbind so as to let other peers bind
> to
> > the same socket, at a different time, and broadcast a different set of
> > identifiers for the next peer.
> >
> > I’m suspecting that messages get discarded before getting sent due to the
> > unbinding (the same occurs with a call to close()) but I can’t figure out
> > how to get it to empty the queue prior to closing the connection so as to
> > not discard any messages.
> >
> > Any ideas?
> >
> > Windows 8.1 x64
> > Python 2.7.7 x64
> > PyZMQ 4.0.4
> >
> > Thanks
> >
> > --
> > Marcus Ottosson
> > konstruktion at gmail.com
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



-- 
*Marcus Ottosson*
konstruktion at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140620/df0e10a5/attachment.htm>


More information about the zeromq-dev mailing list