diff options
| -rw-r--r-- | doc/zmq_getsockopt.txt | 6 | ||||
| -rw-r--r-- | doc/zmq_recv.txt | 16 | ||||
| -rw-r--r-- | doc/zmq_send.txt | 13 | ||||
| -rw-r--r-- | doc/zmq_socket.txt | 14 |
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 |