[zeromq-dev] equivalent of accept

Varol Okan varokan at movingsatellites.com
Wed Apr 21 17:16:54 CEST 2010


On Wednesday 21 April 2010 09:25:26 am Martin Sustrik wrote:
> Varol,
> 
> > That is correct, only I would not have a predefined number of threads 
> > but the # of threads depend on the connected clients.
> > 
> > This approach is used to store ( amongst other states ) login 
> > information about the connected clients and do the processing according 
> > to user restrictions. So if one user is 'root' and another is 'guest' 
> > they'll be allowed to do different things.
> > 
> > I spent yesterday mostly reading up on the mailing list and it seems a 
> > general pattern emerged with XREQ/XREP main socket and inproc sockets 
> > for the worker threads.
> > 
> > So I have two questions:
> > 1) Is there a simple, working example for this ( BTW. I love the 
> > examples on the web page, small and concise )
> > 2) Is there a example where each thread is using its own socket to 
> > connect to the client
> 
> I think there's a conceptual gap here. 0MQ is not connection based, it's 
> message based. Forget about connections. There are none -- at least from 
> user's point of view. Instead, there are messages.
> 
> In your case it means there's no way to authenticate a connection. You 
> have to authenticate a message.

Hahaha, I feel like I was sitting in a dark room until some one turned on the light :)
Sorry for that, as I said I am starting out with 0MQ.

Anyhow, one last question remains wrt to the client. Since 0MQ is message based, how can I determine if the host is alive or simply busy doing things.

Example:
for a socket of type  zmq::socket_t socket ( ctx, ZMQ_REQ );

If I do 
   socket.send ( query );
followed by 
   socket.recv ( &result );

How do I handle a fault like server crashed, or some one pulled the plug. Is there a timeout I can set or would the client freeze ? What can I do to gracefully handle these types of fault ?

Varol :)

> > If these examples are missing I could work something up and it could be 
> > added to the examples, as that issue seems to be coming up frequently. 
> > Though with your comment of XREP/XREQ not being functional maybe I'll 
> > use a standard REP/REQ socket instead ( BTW, whats the difference ? )
> 
> REQ/REP work in step-lock fashion. For example, you cannot send new 
> request to REQ socket until you have received the reply.
> 
> XREQ/XREP are fully asynchronous.
> 
> Martin
> _______________________________________________
> 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