From 5ba1cb20fe6f6699cef1cc726718e760cd4c9af1 Mon Sep 17 00:00:00 2001 From: Martin Lucina Date: Mon, 23 Jan 2012 08:53:25 +0100 Subject: Imported Upstream version 2.0.9.dfsg --- doc/zmq_socket.html | 212 +++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 195 insertions(+), 17 deletions(-) (limited to 'doc/zmq_socket.html') diff --git a/doc/zmq_socket.html b/doc/zmq_socket.html index ddab7e1..4546e37 100644 --- a/doc/zmq_socket.html +++ b/doc/zmq_socket.html @@ -774,6 +774,173 @@ 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 +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.

+
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.

+
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 a single publisher to multiple subscribers in a fanout fashion.

@@ -932,17 +1099,18 @@ N/A a pipeline. Data always flows down the pipeline, and each stage of the pipeline is connected to at least one node. When a pipeline stage is connected to multiple nodes data is load-balanced among all connected nodes.

-

ZMQ_DOWNSTREAM

-

A socket of type ZMQ_DOWNSTREAM is used by a pipeline node to send messages +

ZMQ_PUSH

+

A socket of type ZMQ_PUSH is used by a pipeline node to send messages to downstream pipeline nodes. Messages are load-balanced to all connected downstream nodes. The zmq_recv() function is not implemented for this socket type.

-

When a ZMQ_DOWNSTREAM socket enters an exceptional state due to having -reached the high water mark for all downstream nodes, or if there are no -downstream nodes at all, then any zmq_send(3) operations on the -socket shall block until the exceptional state ends or at least one downstream -node becomes available for sending; messages are not discarded.

-
Summary of ZMQ_DOWNSTREAM characteristics
+

When a ZMQ_PUSH socket enters an exceptional state due to having reached the +high water mark for all downstream nodes, or if there are no downstream +nodes at all, then any zmq_send(3) operations on the socket shall +block until the exceptional state ends or at least one downstream node +becomes available for sending; messages are not discarded.

+

Deprecated alias: ZMQ_DOWNSTREAM.

+
Summary of ZMQ_PUSH characteristics
@@ -1010,12 +1178,13 @@ Block
Compatible peer sockets @@ -950,7 +1118,7 @@ Compatible peer sockets

-ZMQ_UPSTREAM +ZMQ_PULL

-

ZMQ_UPSTREAM

-

A socket of type ZMQ_UPSTREAM is used by a pipeline node to receive -messages from upstream pipeline nodes. Messages are fair-queued from among -all connected upstream nodes. The zmq_send() function is not implemented -for this socket type.

-
Summary of ZMQ_UPSTREAM characteristics
+

ZMQ_PULL

+

A socket of type ZMQ_PULL is used by a pipeline node to receive messages +from upstream pipeline nodes. Messages are fair-queued from among all +connected upstream nodes. The zmq_send() function is not implemented for +this socket type.

+

Deprecated alias: ZMQ_UPSTREAM.

+
Summary of ZMQ_PULL characteristics
@@ -1197,6 +1366,14 @@ The requested socket type is invalid. The maximum number of sockets within this context has been exceeded.

+
+EFAULT +
+
+

+The provided context was not valid (NULL). +

+

SEE ALSO

@@ -1218,7 +1395,8 @@ Martin Lucina <mato@kotelna.sk>.

<
-- cgit v1.2.3
Compatible peer sockets @@ -1023,7 +1192,7 @@ Compatible peer sockets

-ZMQ_DOWNSTREAM +ZMQ_PUSH