[zeromq-dev] [Q] proper message sequence for XREQ to XREP and back again

[Chuck Remes]

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