summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--doc/zmq_getsockopt.txt6
-rw-r--r--doc/zmq_recv.txt16
-rw-r--r--doc/zmq_send.txt13
-rw-r--r--doc/zmq_socket.txt14
4 files changed, 24 insertions, 25 deletions
diff --git a/doc/zmq_getsockopt.txt b/doc/zmq_getsockopt.txt
index 4aef71c..3225a18 100644
--- a/doc/zmq_getsockopt.txt
+++ b/doc/zmq_getsockopt.txt
@@ -10,7 +10,7 @@ zmq_getsockopt - get 0MQ socket options
SYNOPSIS
--------
-*int zmq_getsockopt (void '*socket', int 'option_name', void '*option_value', size_t 'option_len');*
+*int zmq_getsockopt (void '*socket', int 'option_name', void '*option_value', size_t '*option_len');*
DESCRIPTION
@@ -19,7 +19,9 @@ The _zmq_getsockopt()_ function shall retrieve the value for the option
specified by the 'option_name' argument for the 0MQ socket pointed to by the
'socket' argument, and store it in the buffer pointed to by the 'option_value'
argument. The 'option_len' argument is the size in bytes of the buffer pointed
-to by 'option_value'.
+to by 'option_value'; upon successful completion _zmq_getsockopt()_ shall
+modify the 'option_value' argument to indicate the actual size of the option
+value stored in the buffer.
The following options can be retrieved with the _zmq_getsockopt()_ function:
diff --git a/doc/zmq_recv.txt b/doc/zmq_recv.txt
index 50be810..42df99a 100644
--- a/doc/zmq_recv.txt
+++ b/doc/zmq_recv.txt
@@ -31,10 +31,12 @@ to EAGAIN.
Multi-part messages
~~~~~~~~~~~~~~~~~~~
-A 0MQ message is composed of 1 to N message parts; each message part is an
-independent 'zmq_msg_t' in its own right. The total number of message parts is
-unlimited. Consequently, wherever this documentation uses the term _message_ it
-may be substituted for _message part_.
+A 0MQ message is composed of 1 or more message parts; each message part is an
+independent 'zmq_msg_t' in its own right. 0MQ ensures atomic delivery of
+messages; peers shall receive either all _message parts_ of a message or none
+at all.
+
+The total number of message parts is unlimited.
An application wishing to determine if a message is composed of multiple parts
does so by retrieving the value of the _ZMQ_RCVMORE_ socket option on the
@@ -43,9 +45,6 @@ follow, or if the message is not composed of multiple parts, _ZMQ_RCVMORE_
shall report a value of zero. Otherwise, _ZMQ_RCVMORE_ shall report a value of
1, indicating that more message parts are to follow.
-0MQ shall ensure the atomicity of a multi-part message; peers shall receive
-either all _message parts_ of a multi-part message or none at all.
-
RETURN VALUE
------------
@@ -84,6 +83,7 @@ assert (rc == 0);
.Receiving a multi-part message
----
int64_t more;
+int64_t more_size = sizeof more;
do {
/* Create an empty 0MQ message to hold the message part */
zmq_msg_t part;
@@ -93,7 +93,7 @@ do {
rc = zmq_recv (socket, &part, 0);
assert (rc == 0);
/* Determine if more message parts are to follow */
- rc = zmq_getsockopt (socket, ZMQ_RCVMORE, &more, sizeof more);
+ rc = zmq_getsockopt (socket, ZMQ_RCVMORE, &more, &more_size);
assert (rc == 0);
} while (more);
----
diff --git a/doc/zmq_send.txt b/doc/zmq_send.txt
index e4439f5..300f812 100644
--- a/doc/zmq_send.txt
+++ b/doc/zmq_send.txt
@@ -36,10 +36,12 @@ responsibility for the message.
Multi-part messages
~~~~~~~~~~~~~~~~~~~
-A 0MQ message is composed of 1 to N message parts; each message part is an
-independent 'zmq_msg_t' in its own right. The total number of message parts is
-unlimited. Consequently, wherever this documentation uses the term _message_ it
-may be substituted for _message part_.
+A 0MQ message is composed of 1 or more message parts; each message part is an
+independent 'zmq_msg_t' in its own right. 0MQ ensures atomic delivery of
+messages; peers shall receive either all _message parts_ of a message or none
+at all.
+
+The total number of message parts is unlimited.
An application wishing to send a multi-part message does so by specifying the
'ZMQ_SNDMORE' flag to _zmq_send()_. The presence of this flag indicates to 0MQ
@@ -48,9 +50,6 @@ are to follow. When the application wishes to send the final message part it
does so by calling _zmq_send()_ without the 'ZMQ_SNDMORE' flag; this indicates
that no more message parts are to follow.
-0MQ shall ensure the atomicity of a multi-part message; peers shall receive
-either all _message parts_ of a multi-part message or none at all.
-
RETURN VALUE
------------
diff --git a/doc/zmq_socket.txt b/doc/zmq_socket.txt
index ebae5e1..119ac31 100644
--- a/doc/zmq_socket.txt
+++ b/doc/zmq_socket.txt
@@ -70,10 +70,9 @@ for this socket type.
Pipeline pattern
~~~~~~~~~~~~~~~~
The pipeline pattern is used for distributing data to _nodes_ arranged in
-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 processed by all connected _nodes_ in
-parallel.
+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_.
Socket type:: 'ZMQ_DOWNSTREAM'
Compatible peer sockets:: 'ZMQ_UPSTREAM'
@@ -94,8 +93,8 @@ for this socket type.
Exclusive pair pattern
~~~~~~~~~~~~~~~~~~~~~~
-The exclusive pair pattern is used for communicating exclusively between two
-peers.
+The exclusive pair is an advanced pattern used for communicating exclusively
+between two peers.
Socket type:: 'ZMQ_PAIR'
Compatible peer sockets:: 'ZMQ_PAIR'
@@ -105,8 +104,7 @@ time. No message routing or filtering is performed on messages sent over a
'ZMQ_PAIR' socket.
NOTE: 'ZMQ_PAIR' sockets are experimental, and are currently missing several
-features such as auto-reconnection. Developers should consider other patterns
-in preference to the exclusive pair pattern.
+features such as auto-reconnection.
RETURN VALUE