[zeromq-dev] equivalent of accept
varokan at movingsatellites.com
Wed Apr 21 17:16:54 CEST 2010
On Wednesday 21 April 2010 09:25:26 am Martin Sustrik wrote:
> > 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.
for a socket of type zmq::socket_t socket ( ctx, ZMQ_REQ );
If I do
socket.send ( query );
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 ?
> > 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.
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
More information about the zeromq-dev