3party/libzmq
0
0
Fork 0
mirror of https://github.com/zeromq/libzmq.git synced 2024-12-28 16:15:23 +08:00
Code Issues Projects Releases Wiki Activity

Basic documentation for XREQ/XREP socket types

Browse Source 
Add some basic documentation for XREQ/XREP socket types, including
a brief description of the most common use case (REQ -> XREP) and (XREQ ->
REP).
This commit is contained in:
Martin Lucina 2010-08-25 12:50:16 +02:00
parent 6d275a8788
commit c9076c5d8b
1 changed files with 59 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

59
doc/zmq_socket.txt
View File

@ -104,6 +104,65 @@ Outgoing routing stratagy:: Last peer
ZMQ_HWM option action:: Drop
ZMQ_XREQ
^^^^^^^^
A socket of type 'ZMQ_XREQ' is an advanced pattern used for extending
request/reply sockets. Each message sent is load-balanced among all connected
peers, and each message received is fair-queued from all connected peers.
When a 'ZMQ_XREQ' socket enters an exceptional state due to having reached the
high water mark for all peers, or if there are no peers at all, then any
linkzmq:zmq_send[3] operations on the socket shall block until the exceptional
state ends or at least one peer becomes available for sending; messages are not
discarded.
When a 'ZMQ_XREQ' socket is connected to a 'ZMQ_REP' socket each message sent
must consist of an empty message part, the _delimiter_, followed by one or more
_body parts_.
[horizontal]
.Summary of ZMQ_XREQ characteristics
Compatible peer sockets:: 'ZMQ_XREP', 'ZMQ_REP'
Direction:: Bidirectional
Send/receive pattern:: Unrestricted
Outgoing routing strategy:: Load-balanced
Incoming routing strategy:: Fair-queued
ZMQ_HWM option action:: Block
ZMQ_XREP
^^^^^^^^
A socket of type 'ZMQ_XREP' is an advanced pattern used for extending
request/reply sockets. When receiving messages a 'ZMQ_XREP' socket shall
prepend a message part containing the _identity_ of the originating peer to the
message before passing it to the application. Messages received are fair-queued
from among all connected peers. When sending messages a 'ZMQ_XREP' socket shall
remove the first part of the message and use it to determine the _identity_ of
the peer the message shall be routed to.
When a 'ZMQ_XREP' socket enters an exceptional state due to having reached the
high water mark for all peers, or if there are no peers at all, then any
messages sent to the socket shall be dropped until the exceptional state ends.
Likewise, any messages routed to a non-existent peer or a peer for which the
individual high water mark has been reached shall also be dropped.
When a 'ZMQ_REQ' socket is connected to a 'ZMQ_XREP' socket, in addition to the
_identity_ of the originating peer each message received shall contain an empty
_delimiter_ message part. Hence, the entire structure of each received message
as seen by the application becomes: one or more _identity_ parts, _delimiter_
part, one or more _body parts_. When sending replies to a 'ZMQ_REQ' socket the
application must include the _delimiter_ part.
[horizontal]
.Summary of ZMQ_XREP characteristics
Compatible peer sockets:: 'ZMQ_XREQ', 'ZMQ_REQ'
Direction:: Bidirectional
Send/receive pattern:: Unrestricted
Outgoing routing strategy:: See text
Incoming routing strategy:: Fair-queued
ZMQ_HWM option action:: Drop
Publish-subscribe pattern
~~~~~~~~~~~~~~~~~~~~~~~~~
The publish-subscribe pattern is used for one-to-many distribution of data from