From 02b155cb8296db56e8c80410793aa6c577dc3d4a Mon Sep 17 00:00:00 2001 From: f18m Date: Fri, 3 Nov 2023 10:58:32 +0100 Subject: [PATCH] rollback unwanted mass changes --- doc/zmq.adoc | 4 ++-- doc/zmq_bind.adoc | 6 +++--- doc/zmq_connect.adoc | 4 ++-- doc/zmq_ctx_set.adoc | 2 +- doc/zmq_ctx_term.adoc | 2 +- doc/zmq_getsockopt.adoc | 2 +- doc/zmq_inproc.adoc | 2 +- doc/zmq_msg_recv.adoc | 2 +- doc/zmq_pgm.adoc | 4 ++-- doc/zmq_recv.adoc | 2 +- doc/zmq_recvmsg.adoc | 2 +- doc/zmq_setsockopt.adoc | 14 +++++++------- doc/zmq_socket.adoc | 6 +++--- doc/zmq_unbind.adoc | 2 +- 14 files changed, 27 insertions(+), 27 deletions(-) diff --git a/doc/zmq.adoc b/doc/zmq.adoc index 4091571496..146e3c9f37 100644 --- a/doc/zmq.adoc +++ b/doc/zmq.adoc @@ -107,7 +107,7 @@ Sockets ~~~~~~~ 0MQ sockets present an abstraction of an asynchronous _message queue_, with the exact queueing semantics depending on the socket type in use. See -* xref:zmq_socket.adoc[zmq_socket] for the socket types provided. +xref:zmq_socket.adoc[zmq_socket] for the socket types provided. The following functions are provided to work with sockets: @@ -139,7 +139,7 @@ Monitoring socket events:: 0MQ provides a mechanism for applications to multiplex input/output events over a set containing both 0MQ sockets and standard sockets. This mechanism mirrors the standard _poll()_ system call, and is described in detail in -* xref:zmq_poll.adoc[zmq_poll] This API is deprecated, however. +xref:zmq_poll.adoc[zmq_poll] This API is deprecated, however. There is a new DRAFT API with multiple zmq_poller_* function, which is described in xref:zmq_poller.adoc[zmq_poller] diff --git a/doc/zmq_bind.adoc b/doc/zmq_bind.adoc index 24f04fc7de..9dc8c0ded0 100644 --- a/doc/zmq_bind.adoc +++ b/doc/zmq_bind.adoc @@ -28,11 +28,11 @@ The 'endpoint' is a string consisting of a 'transport'`://` followed by an Every 0MQ socket type except 'ZMQ_PAIR' and 'ZMQ_CHANNEL' supports one-to-many and many-to-one semantics. The precise semantics depend on the socket type and are defined in -* xref:zmq_socket.adoc[zmq_socket] +xref:zmq_socket.adoc[zmq_socket] The 'ipc', 'tcp', 'vmci' and 'udp' transports accept wildcard addresses: see -* xref:zmq_ipc.adoc[zmq_ipc], xref:zmq_tcp.adoc[zmq_tcp], xref:zmq_vmci.adoc[zmq_vmci] and -* xref:zmq_udp.adoc[zmq_udp] for details. +xref:zmq_ipc.adoc[zmq_ipc], xref:zmq_tcp.adoc[zmq_tcp], xref:zmq_vmci.adoc[zmq_vmci] and +xref:zmq_udp.adoc[zmq_udp] for details. NOTE: the address syntax may be different for _zmq_bind()_ and _zmq_connect()_ especially for the 'tcp', 'pgm' and 'epgm' transports. diff --git a/doc/zmq_connect.adoc b/doc/zmq_connect.adoc index d14d391372..57087ca62e 100644 --- a/doc/zmq_connect.adoc +++ b/doc/zmq_connect.adoc @@ -28,7 +28,7 @@ The 'endpoint' is a string consisting of a 'transport'`://` followed by an Every 0MQ socket type except 'ZMQ_PAIR' and 'ZMQ_CHANNEL' supports one-to-many and many-to-one semantics. The precise semantics depend on the socket type and are defined in -* xref:zmq_socket.adoc[zmq_socket] +xref:zmq_socket.adoc[zmq_socket] NOTE: for most transports and socket types the connection is not performed immediately but as needed by 0MQ. Thus a successful call to _zmq_connect()_ @@ -42,7 +42,7 @@ NOTE: following a _zmq_connect()_, for socket types except for ZMQ_ROUTER, the socket enters its normal 'ready' state. By contrast, following a _zmq_bind()_ alone, the socket enters a 'mute' state in which the socket blocks or drops messages according to the socket type, as defined in -* xref:zmq_socket.adoc[zmq_socket] A ZMQ_ROUTER socket enters its normal 'ready' state +xref:zmq_socket.adoc[zmq_socket] A ZMQ_ROUTER socket enters its normal 'ready' state for a specific peer only when handshaking is complete for that peer, which may take an arbitrary time. diff --git a/doc/zmq_ctx_set.adoc b/doc/zmq_ctx_set.adoc index 162d2887fe..f90f8d20ec 100644 --- a/doc/zmq_ctx_set.adoc +++ b/doc/zmq_ctx_set.adoc @@ -130,7 +130,7 @@ The 'ZMQ_ZERO_COPY_RECV' argument specifies whether the message decoder should use a zero copy strategy when receiving messages. The zero copy strategy can lead to increased memory usage in some cases. This option allows you to use the older copying strategy. You can query the value of this option with -* xref:zmq_ctx_get.adoc[zmq_ctx_get] using the 'ZMQ_ZERO_COPY_RECV' option. +xref:zmq_ctx_get.adoc[zmq_ctx_get] using the 'ZMQ_ZERO_COPY_RECV' option. NOTE: in DRAFT state, not yet available in stable releases. [horizontal] diff --git a/doc/zmq_ctx_term.adoc b/doc/zmq_ctx_term.adoc index 32ca89133a..cec9ea947b 100644 --- a/doc/zmq_ctx_term.adoc +++ b/doc/zmq_ctx_term.adoc @@ -33,7 +33,7 @@ For further details regarding socket linger behaviour refer to the _ZMQ_LINGER_ option in xref:zmq_setsockopt.adoc[zmq_setsockopt] This function replaces the deprecated functions xref:zmq_term.adoc[zmq_term] and -* xref:zmq_ctx_destroy.adoc[zmq_ctx_destroy] +xref:zmq_ctx_destroy.adoc[zmq_ctx_destroy] == RETURN VALUE diff --git a/doc/zmq_getsockopt.adoc b/doc/zmq_getsockopt.adoc index 4e5b75f359..e849f84681 100644 --- a/doc/zmq_getsockopt.adoc +++ b/doc/zmq_getsockopt.adoc @@ -380,7 +380,7 @@ ZMQ_LINGER: Retrieve linger period for socket shutdown The 'ZMQ_LINGER' option shall retrieve the linger period for the specified 'socket'. The linger period determines how long pending messages which have yet to be sent to a peer shall linger in memory after a socket is closed with -* xref:zmq_close.adoc[zmq_close], and further affects the termination of the socket's +xref:zmq_close.adoc[zmq_close], and further affects the termination of the socket's context with xref:zmq_ctx_term.adoc[zmq_ctx_term] The following outlines the different behaviours: diff --git a/doc/zmq_inproc.adoc b/doc/zmq_inproc.adoc index 652f2a14cc..c9b681e0a9 100644 --- a/doc/zmq_inproc.adoc +++ b/doc/zmq_inproc.adoc @@ -12,7 +12,7 @@ sharing a single 0MQ 'context'. NOTE: No I/O threads are involved in passing messages using the 'inproc' transport. Therefore, if you are using a 0MQ 'context' for in-process messaging only you can initialise the 'context' with zero I/O threads. See -* xref:zmq_init.adoc[zmq_init] for details. +xref:zmq_init.adoc[zmq_init] for details. == ADDRESSING diff --git a/doc/zmq_msg_recv.adoc b/doc/zmq_msg_recv.adoc index 112cc5abc4..584acf92ce 100644 --- a/doc/zmq_msg_recv.adoc +++ b/doc/zmq_msg_recv.adoc @@ -36,7 +36,7 @@ message or none at all. The total number of message parts is unlimited except by available memory. An application that processes multi-part messages must use the _ZMQ_RCVMORE_ -* xref:zmq_getsockopt.adoc[zmq_getsockopt] option after calling _zmq_msg_recv()_ to determine if +xref:zmq_getsockopt.adoc[zmq_getsockopt] option after calling _zmq_msg_recv()_ to determine if there are further parts to receive. diff --git a/doc/zmq_pgm.adoc b/doc/zmq_pgm.adoc index f94d403aea..4b032df447 100644 --- a/doc/zmq_pgm.adoc +++ b/doc/zmq_pgm.adoc @@ -21,7 +21,7 @@ The 'pgm' and 'epgm' transports can only be used with the 'ZMQ_PUB' and Further, PGM sockets are rate limited by default. For details, refer to the 'ZMQ_RATE', and 'ZMQ_RECOVERY_IVL' options documented in -* xref:zmq_setsockopt.adoc[zmq_setsockopt] +xref:zmq_setsockopt.adoc[zmq_setsockopt] CAUTION: The 'pgm' transport implementation requires access to raw IP sockets. Additional privileges may be required on some operating systems for this @@ -67,7 +67,7 @@ Consecutive PGM datagrams are interpreted by 0MQ as a single continuous stream of data where 0MQ messages are not necessarily aligned with PGM datagram boundaries and a single 0MQ message may span several PGM datagrams. This stream of data consists of 0MQ messages encapsulated in 'frames' as described in -* xref:zmq_tcp.adoc[zmq_tcp] +xref:zmq_tcp.adoc[zmq_tcp] PGM datagram payload diff --git a/doc/zmq_recv.adoc b/doc/zmq_recv.adoc index 59ae1244e9..8604aac074 100644 --- a/doc/zmq_recv.adoc +++ b/doc/zmq_recv.adoc @@ -32,7 +32,7 @@ message or none at all. The total number of message parts is unlimited except by available memory. An application that processes multi-part messages must use the _ZMQ_RCVMORE_ -* xref:zmq_getsockopt.adoc[zmq_getsockopt] option after calling _zmq_recv()_ to determine if +xref:zmq_getsockopt.adoc[zmq_getsockopt] option after calling _zmq_recv()_ to determine if there are further parts to receive. == RETURN VALUE diff --git a/doc/zmq_recvmsg.adoc b/doc/zmq_recvmsg.adoc index 3a9a1ef962..1d232a4cd6 100644 --- a/doc/zmq_recvmsg.adoc +++ b/doc/zmq_recvmsg.adoc @@ -34,7 +34,7 @@ message or none at all. The total number of message parts is unlimited except by available memory. An application that processes multi-part messages must use the _ZMQ_RCVMORE_ -* xref:zmq_getsockopt.adoc[zmq_getsockopt] option after calling _zmq_recvmsg()_ to determine if +xref:zmq_getsockopt.adoc[zmq_getsockopt] option after calling _zmq_recvmsg()_ to determine if there are further parts to receive. diff --git a/doc/zmq_setsockopt.adoc b/doc/zmq_setsockopt.adoc index b0add48bb9..d7c3cffd56 100644 --- a/doc/zmq_setsockopt.adoc +++ b/doc/zmq_setsockopt.adoc @@ -171,7 +171,7 @@ sockets, see xref:zmq_curve.adoc[zmq_curve] You can provide the key as 32 binary bytes, or as a 40-character string encoded in the Z85 encoding format and terminated in a null byte. The public key must always be used with the matching secret key. To generate a public/secret key pair, use -* xref:zmq_curve_keypair.adoc[zmq_curve_keypair] To derive the public key from a secret key, +xref:zmq_curve_keypair.adoc[zmq_curve_keypair] To derive the public key from a secret key, use xref:zmq_curve_public.adoc[zmq_curve_public] NOTE: an option value size of 40 is supported for backwards compatibility, @@ -206,7 +206,7 @@ Applicable socket types:: all, when using TCP transport ZMQ_CURVE_SERVER: Set CURVE server role ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Defines whether the socket will act as server for CURVE security, see -* xref:zmq_curve.adoc[zmq_curve] A value of '1' means the socket will act as +xref:zmq_curve.adoc[zmq_curve] A value of '1' means the socket will act as CURVE server. A value of '0' means the socket will not act as CURVE server, and its security role then depends on other option settings. Setting this to '0' shall reset the socket security to NULL. When you @@ -228,7 +228,7 @@ sockets, see xref:zmq_curve.adoc[zmq_curve] You can provide the key as 32 binary bytes, or as a 40-character string encoded in the Z85 encoding format and terminated in a null byte. This key must have been generated together with the server's secret key. To generate a public/secret key pair, use -* xref:zmq_curve_keypair.adoc[zmq_curve_keypair] +xref:zmq_curve_keypair.adoc[zmq_curve_keypair] NOTE: an option value size of 40 is supported for backwards compatibility, though is deprecated. @@ -270,7 +270,7 @@ Applicable socket types:: ZMQ_DEALER, ZMQ_CLIENT and ZMQ_PEER ZMQ_GSSAPI_PLAINTEXT: Disable GSSAPI encryption ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Defines whether communications on the socket will be encrypted, see -* xref:zmq_gssapi.adoc[zmq_gssapi] A value of '1' means that communications will be +xref:zmq_gssapi.adoc[zmq_gssapi] A value of '1' means that communications will be plaintext. A value of '0' means communications will be encrypted. [horizontal] @@ -294,7 +294,7 @@ Applicable socket types:: all, when using TCP transport ZMQ_GSSAPI_SERVER: Set GSSAPI server role ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Defines whether the socket will act as server for GSSAPI security, see -* xref:zmq_gssapi.adoc[zmq_gssapi] A value of '1' means the socket will act as GSSAPI +xref:zmq_gssapi.adoc[zmq_gssapi] A value of '1' means the socket will act as GSSAPI server. A value of '0' means the socket will act as GSSAPI client. [horizontal] @@ -482,7 +482,7 @@ ZMQ_LINGER: Set linger period for socket shutdown The 'ZMQ_LINGER' option shall set the linger period for the specified 'socket'. The linger period determines how long pending messages which have yet to be sent to a peer shall linger in memory after a socket is disconnected with -* xref:zmq_disconnect.adoc[zmq_disconnect] or closed with xref:zmq_close.adoc[zmq_close], and further +xref:zmq_disconnect.adoc[zmq_disconnect] or closed with xref:zmq_close.adoc[zmq_close], and further affects the termination of the socket's context with xref:zmq_ctx_term.adoc[zmq_ctx_term] The following outlines the different behaviours: @@ -585,7 +585,7 @@ Applicable socket types:: all, when using TCP transport ZMQ_PLAIN_SERVER: Set PLAIN server role ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Defines whether the socket will act as server for PLAIN security, see -* xref:zmq_plain.adoc[zmq_plain] A value of '1' means the socket will act as +xref:zmq_plain.adoc[zmq_plain] A value of '1' means the socket will act as PLAIN server. A value of '0' means the socket will not act as PLAIN server, and its security role then depends on other option settings. Setting this to '0' shall reset the socket security to NULL. diff --git a/doc/zmq_socket.adoc b/doc/zmq_socket.adoc index 1b8b125153..385c253dab 100644 --- a/doc/zmq_socket.adoc +++ b/doc/zmq_socket.adoc @@ -19,7 +19,7 @@ The newly created socket is initially unbound, and not associated with any endpoints. In order to establish a message flow a socket must first be connected to at least one endpoint with xref:zmq_connect.adoc[zmq_connect], or at least one endpoint must be created for accepting incoming connections with -* xref:zmq_bind.adoc[zmq_bind] +xref:zmq_bind.adoc[zmq_bind] .Key differences to conventional sockets Generally speaking, conventional sockets present a _synchronous_ interface to @@ -85,7 +85,7 @@ will accept messages, queue them, and send them as rapidly as the network allows. The outgoing buffer limit is defined by the high water mark for the socket. If the outgoing buffer is full, or, for connection-oriented transports, if the ZMQ_IMMEDIATE option is set and there is no connected peer, -* xref:zmq_send.adoc[zmq_send] will block. +xref:zmq_send.adoc[zmq_send] will block. The 'ZMQ_CLIENT' socket will not drop messages. When a 'ZMQ_CLIENT' socket is connected to multiple 'ZMQ_SERVER' sockets, @@ -616,7 +616,7 @@ peers, and each message received is fair-queued from all connected peers. When a 'ZMQ_DEALER' socket enters the 'mute' state due to having reached the high water mark for all peers, or, for connection-oriented transports, if the ZMQ_IMMEDIATE option is set and there are no peers at all, then any -* xref:zmq_send.adoc[zmq_send] operations on the socket shall block until the mute state +xref:zmq_send.adoc[zmq_send] operations on the socket shall block until the mute state ends or at least one peer becomes available for sending; messages are not discarded. When a 'ZMQ_DEALER' socket is connected to a 'ZMQ_REP' socket each message sent diff --git a/doc/zmq_unbind.adoc b/doc/zmq_unbind.adoc index 520081418c..b521cd7296 100644 --- a/doc/zmq_unbind.adoc +++ b/doc/zmq_unbind.adoc @@ -24,7 +24,7 @@ The 'endpoint' argument is as described in xref:zmq_bind.adoc[zmq_bind] Unbinding wild-card address from a socket ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When wild-card `*` 'endpoint' (described in xref:zmq_tcp.adoc[zmq_tcp], -* xref:zmq_ipc.adoc[zmq_ipc], xref:zmq_udp.adoc[zmq_udp] and xref:zmq_vmci.adoc[zmq_vmci]) was used in +xref:zmq_ipc.adoc[zmq_ipc], xref:zmq_udp.adoc[zmq_udp] and xref:zmq_vmci.adoc[zmq_vmci]) was used in _zmq_bind()_, the caller should use real 'endpoint' obtained from the ZMQ_LAST_ENDPOINT socket option to unbind this 'endpoint' from a socket.