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
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
