[zeromq-dev] [Q] proper message sequence for XREQ to XREP and back again
Pieter Hintjens
ph at imatix.com
Wed Aug 25 22:48:04 CEST 2010
Chuck,
Would you like to post this to the wiki recipes section? Would make it
easier for people to find it later. I'll cover this in the guide as well.
Cheers
Pieter
Sent from my Android mobile phone.
On Aug 25, 2010 10:10 PM, "Chuck Remes" <cremes.devlist at mac.com> wrote:
>
> On Aug 25, 2010, at 2:57 PM, Chuck Remes wrote:
>
>>
>> On Aug 25, 2010, at 2:39 PM, Chuck Remes wrote:
>>
>>>
>>> On Aug 25, 2010, at 2:16 PM, Chuck Remes wrote:
>>>
>>>> I have a client (XREQ socket) that connects to a server (XREP socket)
via an intermediary Forwarder device proxy (XREP & XREQ bound to different
ports).
>>>>
>>>> I can successfully send data from the client to the server. I see the
traffic flow through each step by printing the message contents inside the
forwarder.
>>>>
>>>> However, on the return leg from the server to the client, the response
never makes it to the client. I see it get received by the forwarder but
then it disappears.
>>>>
>>>> Reading through the updated docs (thanks for XREQ and XREP docs!) it
mentions a delimiter message part which is I guess a null message created by
zmq_msg_init. The docs mention that when talking from XREQ to REP or from
XREP to REQ, this delimiter message part must be present to separate the
identities for routing from the body.
>>>>
>>>> Do I need to manually recreate that when communicating between XREQ and
XREP sockets?
>>>>
>>>> My message flow looks like this:
>>>>
>>>> 1. Client sends single body message part via XREQ.
>>>>
>>>> 2. Forwarder receives all message parts from client on XREP socket.
>>>>
>>>> 3. Forwarder rewrites those exact messages to the outbound XREQ socket.
>>>>
>>>> 4. Server receives message parts on XREP socket. Server saves the first
message part for return routing.
>>>>
>>>> 5. Server sends routing message part + body message part via XREP
socket.
>>>>
>>>> 6. Forwarder receives reply on XREQ socket.
>>>>
>>>> 7. Forwarder rewrites reply to XREP socket connected back to client.
Data never makes it to the client.
>>>>
>>>>
>>>> I have tried adding a null message part in Step 5 (send route ID, null
part, body part) but that didn't help.
>>>>
>>>> Any ideas on how to fix this? I'm using 2.0.8.
>>>
>>> I've made one change. In Step 1, I now send a null message part + body
via XREQ. It doesn't appear to help.
>>>
>>> Also, I incorrectly said this used a Forwarder. It uses a Queue device.
>>>
>>> Here's what I see from the queue device when I add some debug
statements.
>>>
>>>
>>> On the inbound side of the Queue, I get.
>>> [in] [60144129.xreq.contract]
>>> [in] []
>>> [in] [{"request":"snip"}]
>>>
>>> That exact data should be written to the outbound XREQ socket.
Presumably it should automatically prepend its own identity.
>>>
>>> The Server sees the routing info as the identity of the queue (which I
have overridden to make it more readable). It does *not* see the message
part containing the identity of the original socket.
>>>
>>> routing info [queue.465347480]
>>>
>>> On the route back through the Queue, it sees this traffic.
>>>
>>> [out] []
>>> [out] [{"request_no":1,"payload": "snip"]
>>
>> Ha! I figured it out. It was a bug in my server code. It was not properly
retaining *all* of the routing identities for the return route. It only
grabbed the first one and discarded the remainder.
>>
>> I now have it working.
>>
>> For those of you following along, here's the right way to do it.
>>
>> A. The client does not need to do anything special. It can just send the
message body as a single part. It is *not* necessary to prepend a null
message part; the framework will handle that for you.
>>
>> B. In the server, save the return routing information by, for example,
looping over the messages until you hit a null part. Preface your response
with all of the routing message parts prior to appending your own body
message parts.
>>
>> The framework handles prepending or popping the routing information from
the message parts as it traverses through each layer.
>
> <sigh>
>
> Slight correction. You *should* prepend your original message with a null
packet so that the server at the end of the line can see the
separator/delimiter between the routing info and the body parts.
>
> cr
> _______________________________________________
> 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/20100825/56a24291/attachment.htm>
More information about the zeromq-dev
mailing list