generic-library/libzmq
1
0
Fork 0
mirror of https://github.com/zeromq/libzmq.git synced 2024-12-12 10:33:52 +01:00
Code Issues Projects Releases Wiki Activity

LABELs removed from the documentation

Browse Source 
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
This commit is contained in:
Martin Sustrik 2011-11-01 14:09:54 +01:00
parent 7563518929
commit 1c071f54a6
6 changed files with 8 additions and 74 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
doc/zmq_getsockopt.txt
View File

@ -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

7
doc/zmq_recv.txt
View File

@ -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
------------

7
doc/zmq_recvmsg.txt
View File

@ -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

11
doc/zmq_send.txt
View File

@ -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

11
doc/zmq_sendmsg.txt
View File

@ -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
------------

33
doc/zmq_socket.txt
View File

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