[zeromq-dev] PUB-SUB sync: Node Coordination

Claudio Carbone erupter at libero.it
Sat Aug 18 08:46:37 CEST 2012


Thanks for the heads up:I was copying the setup in the guide and hadn't realized that.
Although for my needs I think that a reply (receive confirmation at least) is necessary.

Regards
Claudio
-- Sent from my LG Optimus 2x with K-9 Mail.

Yi Ding <yi.s.ding at gmail.com> wrote:

Hi Claudio,

We had some discussions about giving the application the ability to
the IP address of the sender of a packet (the way it's possible with
raw packets). Unfortunately that feature has not been implemented, as
far as I know.

So given that, the best option would be to send some kind of
identifying information inside the message itself. You also mention
using REQ-REP channel for other things in addition to synchronization.
If that's the case, I would highly recommend looking into either
PUSH-PULL or ROUTER-DEALER sockets. REQ-REP is a pain to deal with if
you ever want to do any kind of asynchronous processing because you
have to reply to a message before receiving another one (on the server
side)

Cheers,
Yi

On Fri, Aug 17, 2012 at 5:43 AM, erupter at libero.it <erupter at libero.it> wrote:
> Ok after sorting out the poller errors I'm trying what I really need to do:
> some sort of PUB-SUB sync.
> The part of the guide I'm referring to is this:
> http://zguide.zeromq.org/page:all#Node-Coordination
>
> First of all I notice that if I add a second socket to bind to the server, I
> then have to hit ctrl+c two times to get a clean exit.
> Remove the second bind and it's ok.
> Here is the code with the relevant part commented, this is still on the
> framework of the basic REQ-REP system.
> I'm just adding a PUB socket and getting the double ctrl-c thing.
>
> zmq_pollitem_t local_zmq_sockets[5];
>
>
> int main (void)
> {
> zmq_msg_t request;
> void *context = zmq_init (1);
> const char * chptr = 0;
> int zerr = 0;
> // Socket to talk to clients
> void *responder = zmq_socket (context, ZMQ_REP);
> zerr = zmq_bind (responder, "tcp://*:5555");
> if (zerr != 0)
> {
> zerr = zmq_errno();
> chptr = zmq_strerror(zerr);
> printf ("\n%s\n", chptr);
> }
>
> // void *publisher = zmq_socket (context, ZMQ_PUB);
> // zerr = zmq_bind ( publisher, "tcp://*:5556");
> // if (zerr != 0)
> // {
> // zerr = zmq_errno();
> // chptr = zmq_strerror(zerr);
> // printf ("\n%s\n", chptr);
> // }
>
> s_catch_signals ();
> local_zmq_sockets[0].socket = responder;
> local_zmq_sockets[0].events = ZMQ_POLLIN;
>
> while (1) {
> // Wait for next request from client
>
>
> zerr = zmq_poll(local_zmq_sockets,1,5);
> if (zerr == -1)
> {
> zerr = zmq_errno();
> chptr = zmq_strerror(zerr);
> printf ("\n%s\n", chptr);
> break;
> }
> if (local_zmq_sockets[0].revents & ZMQ_POLLIN) {
> zmq_msg_init (&request);
> zmq_recv (responder, &request, 0);
> zmq_msg_close(&request);
>
> // Send reply back to client
> zmq_msg_t reply;
> zmq_msg_init_size (&reply, 5);
> memcpy (zmq_msg_data (&reply), "Prova", 5);
> zmq_send (responder, &reply, 0);
> zmq_msg_close (&reply);
> }
>
> if (s_interrupted) {
> printf ("\nSIGTERM interrupt received, killing server…\n");
> break;
> }
> // Do some 'work'
> sleep (1);
>
>
> }
> // We never get here but if we did, this would be how we end
> zmq_close (responder);
> zmq_term (context);
> return 0;
> }
>
>
>
> The example in the guide naively assumes that each empty sync request is a new
> subscriber, thus incrementing the subscribers count.
> Now in a realistic scenario am I wrong in assuming something more complex must
> be in place?
> I think I need to discern the real number of subscribers from the actual
> number of requests: in a real scenario the REQ-REP channel may well be used for
> a number of things, including heartbeats and uplink messages, so moderate
> traffic is to be expected.
> I can't just thrust the number of REQs to represent the number of subscribers.
> Is there a way to determine a priori the identity of the sender?
> Or else should I really parse every message inside the socket manager?
>
> Regards
> Claudio
> Something like the MAC Source field of an ethernet packet.
>_____________________________________________

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120818/462c7232/attachment.htm>


More information about the zeromq-dev mailing list