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

Hardeep Singh hshardeesi at gmail.com
Tue Nov 6 17:49:06 CET 2012


Sure, please go ahead and change the name.

And for the second question it's latter, as many bytes as read from the tcp
socket.

Thanks!
- Hardeep

On Tue, Nov 6, 2012 at 4:13 AM, Pieter Hintjens <ph at imatix.com> wrote:

> 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?
>
> -Pieter
>
>
> 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
>>>
>>>
>>
>
> _______________________________________________
> 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/a6e94d22/attachment.htm>


More information about the zeromq-dev mailing list