[zeromq-dev] zmq_poll

[Serge Aleynikov]

Martin,

I sited SCTP merely as an example of separation of an association from 
the transport layer socket, which makes it possible to poll for SCTP 
events on a single fd and dispatch the messages to application-level 
queues handling association-specific content.  It would be fine to have 
different OS threads working on those queues interchangeably.

Conceptually the 0MQ socket can be perceived as an SCTP association; 0MQ 
socket subscription is like an SCTP stream; and 0MQ app_thread's 
signaling fd is like SCTP one-to-many socket.

Though after my initial introduction to 0MQ I believed it would be a 
good idea to have a BSD file descriptor associated with each 0MQ socket, 
after giving it more thought, it seems unnecessary as it would associate 
a 0MQ socket with a wrong OSI layer.  The multiplexing problem needed to 
be solved by the library is how to route messages between N logical 
subscriptions and M transport connections within a single process (as I 
understand the actual 0MQ implementation is slightly different as M 
transport connections are never shared between 0MQ sockets).  A 0MQ 
socket is a "user-level queue" associated with one or more 
subscriptions.  A dispatching engine running in some OS thread would be 
triggered when there's an I/O activity and it would read and replicate 
incoming messages to application-level 0MQ queues based on details of 
the subscription matrix.  In cases when application-level code needs 
more than 1 0MQ socket, instead of associating them with a file 
descriptor for providing an application with ability to poll on multiple 
sockets, it could be avoided by registering a notification callback 
triggered when there's a message to read.  This way no enforcement of 
any threading model on the application layer is needed.  0MQ sockets 
would be merely light-weight queues for reading/writing messages from 
any OS thread context and the user could control how application-level 
notification is handled through implementing that functionality in the 
callback.

Hope this makes sense. :-)

Serge

On 5/23/2010 5:40 AM, Martin Sustrik wrote:
> Serge,
>
>> BTW, if you are going to spend some time thinking about this, perhaps it
>> would be helpful to take a look at specification of socket API of SCTP
>> protocol in a way how the concept of a connection is separate from an
>> association between endpoints (talking about one-to-many sockets).
>
> How that that apply to 0mq threading issues?
>
> Martin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev