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

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


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/dddb56e3/attachment.htm>


More information about the zeromq-dev mailing list