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

Pieter Hintjens ph at imatix.com
Tue Nov 6 18:31:29 CET 2012


OK, great. I pushed a patch and changes to zmq_setsockopt man page, and
it's been merged to master.

-Pieter


On Tue, Nov 6, 2012 at 5:49 PM, Hardeep Singh <hshardeesi at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/11f3cc0a/attachment.htm>


More information about the zeromq-dev mailing list