[zeromq-dev] Survey: use of 0MQ request reply

Martin Sustrik sustrik at 250bpm.com
Thu Jun 16 11:40:57 CEST 2011


On 06/16/2011 11:13 AM, Dirkjan Ochtman wrote:
> On Thu, Jun 16, 2011 at 11:09, Martin Sustrik<sustrik at 250bpm.com>  wrote:
>>> In a pure REQ/REP setup, I wonder how identity is checked. I.e. is
>>> there anything that assures that a response is going back to the
>>> client that sent the related request? The REQ/REP names kind of imply
>>> that this is provided, but I guess it's only enforced by order of the
>>> operations (i.e., first response goes to first request). I think I'd
>>> like it more if the client identify was passed explicitly.
>>
>> No. The routing is based on identities.
>
> Right, but that's invisible on the application side, right? There,
> it's just recv and send operations (on the REP side).

Yes.

>>> - Client identity concept on the server without having to set it on
>>> the client; defined streams
>>
>> Yes, that's done internally. Identity is automatically generated if you
>> don't set it by hand.
>
> Right, but it would be nice if for example I can "see" from what
> identity a certain message originates.

You can inspect the backtrace stack with XREP socket, but it's not a 
good idea to use it to drive the business logic.

>>> - Each stream has separate control and data "channels"
>>
>> How would that work?
>
> I'm not sure. Maybe it would be enough if the PUB can inspect the
> subscriptions (i.e. based on the bidi-pipes work).

Yes. XPUB socket does that. You can recv() from it. What you get is 
subscriptions and unsubscriptions.

Martin



More information about the zeromq-dev mailing list