diff options
| -rw-r--r-- | doc/zmq_getsockopt.txt | 13 | ||||
| -rw-r--r-- | doc/zmq_recv.txt | 7 | ||||
| -rw-r--r-- | doc/zmq_recvmsg.txt | 7 | ||||
| -rw-r--r-- | doc/zmq_send.txt | 11 | ||||
| -rw-r--r-- | doc/zmq_sendmsg.txt | 11 | ||||
| -rw-r--r-- | doc/zmq_socket.txt | 33 |
6 files changed, 8 insertions, 74 deletions
diff --git a/doc/zmq_getsockopt.txt b/doc/zmq_getsockopt.txt index 99065c0..36abbdb 100644 --- a/doc/zmq_getsockopt.txt +++ b/doc/zmq_getsockopt.txt @@ -39,19 +39,6 @@ Default value:: N/A Applicable socket types:: all -ZMQ_RCVLABEL: Inquires whether last message received was a label -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The 'ZMQ_RCVLABEL' option shall return True (1) if the message part last -received from the 'socket' was an address label. Otherwise, this option -shall return False (0). - -[horizontal] -Option value type:: int -Option value unit:: boolean -Default value:: N/A -Applicable socket types:: all - - ZMQ_RCVMORE: More message data parts to follow ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The 'ZMQ_RCVMORE' option shall return True (1) if the message part last diff --git a/doc/zmq_recv.txt b/doc/zmq_recv.txt index c9c3ce8..d1ef3e1 100644 --- a/doc/zmq_recv.txt +++ b/doc/zmq_recv.txt @@ -29,8 +29,7 @@ function shall fail with 'errno' set to EAGAIN. Multi-part messages ~~~~~~~~~~~~~~~~~~~ -A 0MQ message is composed of 1 or more message parts, starting with zero or -more address 'label' parts, followed by 1 or more 'data' parts. Each message +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 except @@ -38,9 +37,7 @@ by available memory. An application that processes multipart messages must use the _ZMQ_RCVMORE_ linkzmq:zmq_getsockopt[3] option after calling _zmq_recv()_ to determine if -there are further parts to receive. An application that manipulates address -labels must use _ZMQ_RCVLABEL_ to determine the zero or more label parts -that precede the data part(s). +there are further parts to receive. RETURN VALUE ------------ diff --git a/doc/zmq_recvmsg.txt b/doc/zmq_recvmsg.txt index 358ea3f..6e41b1e 100644 --- a/doc/zmq_recvmsg.txt +++ b/doc/zmq_recvmsg.txt @@ -29,8 +29,7 @@ function shall fail with 'errno' set to EAGAIN. Multi-part messages ~~~~~~~~~~~~~~~~~~~ -A 0MQ message is composed of 1 or more message parts, starting with zero or -more address 'label' parts, followed by 1 or more 'data' parts. Each message +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 except @@ -38,9 +37,7 @@ by available memory. An application that processes multipart messages must use the _ZMQ_RCVMORE_ linkzmq:zmq_getsockopt[3] option after calling _zmq_recvmsg()_ to determine if -there are further parts to receive. An application that manipulates address -labels must use _ZMQ_RCVLABEL_ to determine the zero or more label parts -that precede the data part(s). +there are further parts to receive. RETURN VALUE diff --git a/doc/zmq_send.txt b/doc/zmq_send.txt index 133de97..f00e449 100644 --- a/doc/zmq_send.txt +++ b/doc/zmq_send.txt @@ -23,11 +23,6 @@ Specifies that the operation should be performed in non-blocking mode. If the message cannot be queued on the 'socket', the _zmq_send()_ function shall fail with 'errno' set to EAGAIN. -*ZMQ_SNDLABEL*:: -Specifies that the message part being sent is an address label, and that -further message parts are to follow. Refer to linkzmq:zmq_socket[3] for the -semantics of address labels in each socket pattern. - *ZMQ_SNDMORE*:: Specifies that the message being sent is a multi-part message, and that further message parts are to follow. Refer to the section regarding multi-part messages @@ -40,16 +35,14 @@ the 'socket' and 0MQ has assumed responsibility for the message. Multi-part messages ~~~~~~~~~~~~~~~~~~~ -A 0MQ message is composed of 1 or more message parts, starting with zero or -more address 'label' parts, followed by 1 or more 'data' parts. Each message +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 except by available memory. An application that sends multipart messages must use the _ZMQ_SNDMORE_ flag -when sending each data part except the final one. An application that sends -address labels must use _ZMQ_SNDLABEL_ when sending each label. +when sending each data part except the final one. RETURN VALUE diff --git a/doc/zmq_sendmsg.txt b/doc/zmq_sendmsg.txt index 244c0bd..d069bd7 100644 --- a/doc/zmq_sendmsg.txt +++ b/doc/zmq_sendmsg.txt @@ -23,11 +23,6 @@ Specifies that the operation should be performed in non-blocking mode. If the message cannot be queued on the 'socket', the _zmq_sendmsg()_ function shall fail with 'errno' set to EAGAIN. -*ZMQ_SNDLABEL*:: -Specifies that the message part being sent is an address 'label', and that -further message parts are to follow. Refer to linkzmq:zmq_socket[3] for the -semantics of address labels in each socket pattern. - *ZMQ_SNDMORE*:: Specifies that the message being sent is a multi-part message, and that further message parts are to follow. Refer to the section regarding multi-part messages @@ -44,16 +39,14 @@ the 'socket' and 0MQ has assumed responsibility for the message. Multi-part messages ~~~~~~~~~~~~~~~~~~~ -A 0MQ message is composed of 1 or more message parts, starting with zero or -more address 'label' parts, followed by 1 or more 'data' parts. Each message +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 except by available memory. An application that sends multipart messages must use the _ZMQ_SNDMORE_ flag -when sending each data part except the final one. An application that sends -address labels must use _ZMQ_SNDLABEL_ when sending each label. +when sending each data part except the final one. RETURN VALUE ------------ diff --git a/doc/zmq_socket.txt b/doc/zmq_socket.txt index e138ebe..1ba2f42 100644 --- a/doc/zmq_socket.txt +++ b/doc/zmq_socket.txt @@ -81,11 +81,6 @@ any linkzmq:zmq_send[3] operations on the socket shall block until the exceptional state ends or at least one _service_ becomes available for sending; messages are not discarded. -'ZMQ_REQ' socket adds a unique 'request ID' label to every outbound message. -When receiving a reply, it checks whether the 'request ID' of the reply matches -the last 'request ID' sent. If it does not, the message is silently dropped and -waiting for the reply is resumed. - [horizontal] .Summary of ZMQ_REQ characteristics Compatible peer sockets:: 'ZMQ_REP' @@ -108,10 +103,6 @@ When a 'ZMQ_REP' socket enters an exceptional state due to having reached the high water mark for a _client_, then any replies sent to the _client_ in question shall be dropped until the exceptional state ends. -'ZMQ_REP' socket strips all the labels from the incoming message, stores them -and passes the remaining data parts to the user. When user sends the reply, -the stored labels are re-attached to the reply. - [horizontal] .Summary of ZMQ_REP characteristics Compatible peer sockets:: 'ZMQ_REQ' @@ -136,8 +127,6 @@ 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. -'ZMQ_XREQ' socket doesn't inspect or modify the message labels. - [horizontal] .Summary of ZMQ_XREQ characteristics Compatible peer sockets:: 'ZMQ_XREP', 'ZMQ_REP' @@ -162,14 +151,6 @@ messages sent to the socket shall be dropped until the exceptional state ends. Likewise, any messages to be routed to a non-existent peer or a peer for which the individual high water mark has been reached shall also be dropped. -When receiving messages a 'ZMQ_XREP' socket attaches a label uniquely -identifying the originating peer to the message before passing it to the -application. - -When sending messages a 'ZMQ_XREP' socket removes the first label from the -message and uses it to determine which the peer the message shall be routed to. -If the peer does not exist anymore the message is silently discarded. - [horizontal] .Summary of ZMQ_XREP characteristics Compatible peer sockets:: 'ZMQ_XREQ', 'ZMQ_REQ' @@ -196,8 +177,6 @@ high water mark for a _subscriber_, then any messages that would be sent to the _subscriber_ in question shall instead be dropped until the exceptional state ends. The _zmq_send()_ function shall never block for this socket type. -This socket type doesn't use message labels. - [horizontal] .Summary of ZMQ_PUB characteristics Compatible peer sockets:: 'ZMQ_SUB', 'ZMQ_XSUB' @@ -215,8 +194,6 @@ any messages, use the 'ZMQ_SUBSCRIBE' option of linkzmq:zmq_setsockopt[3] to specify which messages to subscribe to. The _zmq_send()_ function is not implemented for this socket type. -This socket type doesn't use message labels. - [horizontal] .Summary of ZMQ_SUB characteristics Compatible peer sockets:: 'ZMQ_PUB', 'ZMQ_XPUB' @@ -233,8 +210,6 @@ in form of incoming messages. Subscription message is a byte 1 (for subscriptions) or byte 0 (for unsubscriptions) followed by the subscription body. -This socket type doesn't use message labels. - [horizontal] .Summary of ZMQ_XPUB characteristics Compatible peer sockets:: 'ZMQ_SUB', 'ZMQ_XSUB' @@ -250,8 +225,6 @@ Same as ZMQ_SUB except that you subscribe by sending subscription messages to the socket. Subscription message is a byte 1 (for subscriptions) or byte 0 (for unsubscriptions) followed by the subscription body. -This socket type doesn't use message labels. - [horizontal] .Summary of ZMQ_XSUB characteristics Compatible peer sockets:: 'ZMQ_PUB', 'ZMQ_XPUB' @@ -282,8 +255,6 @@ _nodes_ at all, then any linkzmq: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. -This socket type doesn't use message labels. - [horizontal] .Summary of ZMQ_PUSH characteristics Compatible peer sockets:: 'ZMQ_PULL' @@ -301,8 +272,6 @@ 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. -This socket type doesn't use message labels. - [horizontal] .Summary of ZMQ_PULL characteristics Compatible peer sockets:: 'ZMQ_PUSH' @@ -330,8 +299,6 @@ high water mark for the connected peer, or if no peer is connected, then any linkzmq:zmq_send[3] operations on the socket shall block until the peer becomes available for sending; messages are not discarded. -This socket type doesn't use message labels. - NOTE: 'ZMQ_PAIR' sockets are experimental, and are currently missing several features such as auto-reconnection. |