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

Hardeeps@gail.com hardeeps80 at gmail.com
Tue Nov 6 17:32:53 CET 2012


Sure, please go ahead..

Sent from my iPhone

On Nov 6, 2012, at 4:06 AM, 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
> 
> _______________________________________________
> 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/38380823/attachment.htm>


More information about the zeromq-dev mailing list