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

Yi Ding yi.s.ding at gmail.com
Sat Aug 18 03:15:03 CEST 2012


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



More information about the zeromq-dev mailing list