[zeromq-dev] Getting started with ruby bindings

Brian Candler B.Candler at pobox.com
Wed Apr 21 16:25:40 CEST 2010


On Wed, Apr 21, 2010 at 01:28:06PM +0200, Martin Sustrik wrote:
> The main problem here (and that's a reoccurring issue) is the 0MQ
> sockets cannot be polled on because they aren't real file
> descriptors.
> 
> I can imagine a small wrapper library on top of 0MQ that would
> intercept the system BSD socket API and forward the calls either to
> OS (in case of OS file descriptors) or to 0MQ (in case of 0MQ
> sockets).

It's all very well intercepting the socket library calls, but intercepting
select() and epoll() etc, and making them work with these 'fake' sockets, is
going to be hard I think.

You could use socketpair(2) instead to give selectable FDs, but that
involves data copying (or else passing pointers).  It's also unlikely to
port cleanly to Windows.

So let's assume that the 0MQ handler is a separate daemon.

ISTM that each "0MQ socket" abstraction maps essentially to a pool of
underlying BSD sockets, which have automatic connect/disconnect capability
and round-robin message sending.  So a simple approach would be to create
0MQ socket instances in the daemon and *name* them.  When the client
connects to the daemon it says the name of the 0MQ socket it wants to use on
that connection, and then start sending messages.  Perhaps this is a good
use of the initial handshake.

The daemon would need a config file. e.g.

   foo:
     type: ZMQ_REQ
     connect:
       - tcp://1.2.3.4:5555
       - tcp://1.2.3.6:5555

Then the application would just open a connection to the daemon (using
localhost or a unix domain socket), request peer "foo", and start sending
messages.  The daemon would recv() from the client connection and send() to
the "foo" 0MQ socket, and vice versa.

The framing of messages between client and daemon could still be 0MQ
framing, since it's so simple. But the client doesn't need to implement
anything else.

I feel that the ability to select a named peer at the start of the session
is something which should be available in 0MQ itself anyway; it means you
can have multiple services on the same port. The obvious way is to extend
the URLs, e.g. tcp://1.2.3.4:5555/stock-quotes

Regards,

Brian.



More information about the zeromq-dev mailing list