[zeromq-dev] equivalent of accept

[Martin Sustrik]

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.

> 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