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
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
