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

Pieter Hintjens ph at imatix.com
Tue Nov 6 13:13:26 CET 2012

Hi Hardeep,

Another question while I'm writing the man page. When receiving a message,
how do you specify how many bytes to read? Does the socket just return as
many bytes as the underlying TCP socket provides?


On Tue, Nov 6, 2012 at 1:06 PM, Pieter Hintjens <ph at imatix.com> wrote:

> Hardeep,
> Do you mind if I change the option name to ZMQ_ROUTER_RAW? The _SOCK is
> redundant.
> -Pieter
> On Wed, Oct 31, 2012 at 7:58 AM, Hardeep Singh <hshardeesi at gmail.com>wrote:
>> 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
>> _______________________________________________
>> 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/20121106/c60bb83f/attachment.htm>

More information about the zeromq-dev mailing list