[zeromq-dev] equivalent of accept
sustrik at 250bpm.com
Wed Apr 21 15:25:26 CEST 2010
> 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.
> 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.
More information about the zeromq-dev