[zeromq-dev] XREP/XREQ in 2.0.7

Chuck Remes cremes.devlist at mac.com
Mon Jul 12 17:00:10 CEST 2010


On Jul 12, 2010, at 9:49 AM, Matt Weinstein wrote:

> AFAIK
> 
> XREQ/XREP are packet concentrators and forwarders, which are used as  
> convenient plumbing to e.g. back-to-back two binds().
> 
> XREQ/XREP sockets receive additional "header" packets which are used  
> to route responses, etc.
> 
> These packet include the UUID of the requester (17 bytes?) and a  
> trailing null packet to indicate end of header.
> 
> Sender sends:
> 	[ data ] ....
> 
> XREP receives:
> 
> 	[ UUID ] [ Ø ] [ data ] ....
> 
> Where UUID is the corresponding "identity" of the requester's pipe.
> 
> Take a look at the source code.
> 
> BTW, you probably don't need to be interpreting these packets unless  
> you are tweaking the protocol...
> 
> Corrections welcome!

My understanding of XREQ/XREP is a bit different.

These sockets do not enforce the send/recv/send/recv state changes that the REQ/REP sockets do. Sending with an XREQ socket adds a message part containing the socket identity (can be set by the user via setsockopt or is system-generated). The second message part contains the data or body. There should not be any parsing of messages looking for NUL characters or the like because the framework handles that transparently and delivers each message part to you.

On the XREP side, the identity header must be saved for sending replies. The saved header should be sent as a separate message part (see ZMQ_SNDMORE) prior to transmitting the body of the reply. This allows the framework to match up the reply with the correct sender.

As far as I know, REQ and REP sockets are built on top of the XREQ/XREP sockets. All of the extra housekeeping is handled by the framework when using those sockets so you needn't save any header data for them.

cr




More information about the zeromq-dev mailing list