[zeromq-dev] (3.x) non-zmq tcp clients support for router socket

Hardeep Singh hshardeesi at gmail.com
Wed Oct 31 07:58:20 CET 2012


Thanks! Here are few notes:
- Hardeep


Requirement:
---------------------
Ability to accept non-zmq tcp (client) socket connections and exchange data
as byte stream.

Use-case:
---------------
Certain legacy applications may not be modified to open zmq sockets. With
zmq supporting raw tcp connections, non-zmq client applications can connect
and exchange data with server application that uses zmq. e.g. telnet
connection to a zmq router socket listening on a port.


Design:
------------

Code changes are not whole lot and should be fairly easy to follow and
understand, here are few pointers:

=> Introduced a new socket option (ZMQ_ROUTER_RAW_SOCK) for ROUTER socket
that will basically put it in raw mode. This option can only be set for
ROUTER, setting it for any other transport will throw an error.
=> When a non-zmq tcp client application makes a connection with router
socket, zmq core will instantiate the session and pipe just like any other
zmq connection. But only in this  case, identity is never expected and
exchanged with the remote peer. so in router.cpp a pipe is assigned an
identity as soon as it's attached (router_t::xattach)
=> Added two new raw_encoder.cpp and raw_decoder.cpp classes to be used
instead of standard zmq framing protocol encoder and decoder. These classes
are the ones that send and receive bytes in raw form i.e w/o zmq framing
protocol encaps.
=> Handshaking is disabled in stream_engine.cpp when it gets plugged to an
io_thread and raw_encoder and raw_decoder are instantiated.
=> One more new feature is added - application can close a remote
connection by sending an id message followed by zero length data message.
router_t::xsend will check for this condition and trigger the pipe
termination that will eventually terminate the remote connection and clean
up the resources. Right now it is only supported for ROUTER in raw mode,
but it may be useful for regular non-raw mode too, since application is
keeping track of ids of remote connections and may chose to terminate a
connection selectively.
=> ZMQ_MSGMORE flag is ignored while sending data messages.


Why ROUTER socket:
--------------------------------
In short, routers ability to provide connection identifier helps the server
application to manage non-zmq client connections. Exchanging data as byte
stream transcends zmq framing protocol and messaging model. This leaves
application to make decisions on data received and sent in asynchronous
manner. I believe this is kind of orthogonal to zmq's messaging model,
which is to make applications oblivious to connection endpoints and message
framing, so I guess other transports may not need to support this. I
haven't tried all of them, so I don't know...


Test-case:
-------------------
A sample usage is provided in tests/test_raw_sock.c


Few other things that I thought would be Nice to have:
-----------------------------------------------------------------------------
- Message priorities: Each connection has one receiver and one sender pipe.
Instead there can be >1 receiver and sender pipes with assigned priorities
and weights. Application while sending a message can assign a priority to
the message and fq_t and lb_t can dequeue and enqueue messages into
corresponding priority pipes.

- Ability to register new encoding and decoding framing formats that
replaces or extends zmq framing protocol: Application, if so desire, may
register their own framing encoder and decoder objects that zmq will
invoke as soon as a message is received over the wire. Applications, on
decoding custom frame headers can run it though it's filtering rules and
can provide action - drop/enqueue/assign priority to the message.





On Mon, Oct 29, 2012 at 9:05 PM, Pieter Hintjens <ph at imatix.com> wrote:

> On Wed, Oct 24, 2012 at 8:23 AM, Hardeep Singh <hardeeps80 at gmail.com>
> wrote:
>
> > I am using zmq to manage my telnet client connections. I have made some
> > modifications to 3.x version to support this.
>
> I've merged the patch, which looks clean and builds, and have some
> questions.
>
> Mostly, it would be good to have some explanation of the design and
> API, how to use this, and why you implemented this in the ROUTER
> socket rather than, for example, as a different transport.
>
> Also, an example of using it would be great.
>
> Thanks
> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20121030/950174eb/attachment.htm>


More information about the zeromq-dev mailing list