diff options
| author | Garrett D'Amore <garrett@damore.org> | 2024-03-31 11:28:24 -0700 |
|---|---|---|
| committer | Garrett D'Amore <garrett@damore.org> | 2024-03-31 11:28:24 -0700 |
| commit | 309583d7b4171cf6851d4ba89e07909642180015 (patch) | |
| tree | bf64e74e9666038e71db0c7826fe706977627cd8 /docs/reference/src/sock | |
| parent | 1bcf60a65ee56054e638c0859da1fe2418160bc6 (diff) | |
| download | nng-309583d7b4171cf6851d4ba89e07909642180015.tar.gz nng-309583d7b4171cf6851d4ba89e07909642180015.tar.bz2 nng-309583d7b4171cf6851d4ba89e07909642180015.zip | |
nng_send*mdbook
Diffstat (limited to 'docs/reference/src/sock')
| -rw-r--r-- | docs/reference/src/sock/nng_recv.md | 7 | ||||
| -rw-r--r-- | docs/reference/src/sock/nng_recv_aio.md | 8 | ||||
| -rw-r--r-- | docs/reference/src/sock/nng_recvmsg.md | 5 | ||||
| -rw-r--r-- | docs/reference/src/sock/nng_send.3.adoc | 90 | ||||
| -rw-r--r-- | docs/reference/src/sock/nng_send.md | 93 | ||||
| -rw-r--r-- | docs/reference/src/sock/nng_send_aio.3.adoc | 81 | ||||
| -rw-r--r-- | docs/reference/src/sock/nng_send_aio.md | 75 | ||||
| -rw-r--r-- | docs/reference/src/sock/nng_sendmsg.3.adoc | 84 | ||||
| -rw-r--r-- | docs/reference/src/sock/nng_sendmsg.md | 82 |
9 files changed, 256 insertions, 269 deletions
diff --git a/docs/reference/src/sock/nng_recv.md b/docs/reference/src/sock/nng_recv.md index 178661f7..f594cafc 100644 --- a/docs/reference/src/sock/nng_recv.md +++ b/docs/reference/src/sock/nng_recv.md @@ -46,11 +46,8 @@ updated with the actual message body length copied into _data_. > [!NOTE] > The semantics of what receiving a message means vary from protocol to > protocol, so examination of the protocol documentation is encouraged. -> (For example, with a [_REQ_][req] socket a message may only be received -> after a request has been sent, and a [_SUB_][sub] socket -> may only receive messages corresponding to topics to which it has subscribed.) -> Furthermore, some protocols may not support receiving data at all, such as -> [_PUB_][pub]. +> Furthermore, some protocols may not support receiving data at all, or +> may require other conditions be met before they can receive. > [!TIP] > The `NNG_FLAG_ALLOC` flag can be used to reduce data copies, thereby diff --git a/docs/reference/src/sock/nng_recv_aio.md b/docs/reference/src/sock/nng_recv_aio.md index 257ec691..8baeb2a4 100644 --- a/docs/reference/src/sock/nng_recv_aio.md +++ b/docs/reference/src/sock/nng_recv_aio.md @@ -38,12 +38,8 @@ but `nng_aio_result()` will be non-zero. > [!NOTE] > The semantics of what receiving a message means varies from protocol to > protocol, so examination of the protocol documentation is encouraged. -> For example, with [_PUB_][pub] socket the data is broadcast, so that -> only peers who have a suitable subscription will be able to receive it. -> Furthermore, some protocols may not support receiving (such as -> _PUB_) or may require other conditions. -> (For example, [_REQ_][req] sockets cannot normally receive data -> until they have first sent a request.) +> Furthermore, some protocols may not support receiving +> or may require other conditions be met before receiving messages. ## ERRORS diff --git a/docs/reference/src/sock/nng_recvmsg.md b/docs/reference/src/sock/nng_recvmsg.md index 3d3912c0..9e081893 100644 --- a/docs/reference/src/sock/nng_recvmsg.md +++ b/docs/reference/src/sock/nng_recvmsg.md @@ -39,9 +39,8 @@ disposing of it when it is no longer needed. > [!NOTE] > The semantics of what receiving a message means vary from protocol to > protocol, so examination of the protocol documentation is encouraged. -> (For example, with a [_REQ_][req] socket a message may only be received -> after a request has been sent). -> Furthermore, some protocols do not support receiving data at all. +> Furthermore, some protocols do not support receiving data at all, or +> may require other conditions be met before receiving messages. ## RETURN VALUES diff --git a/docs/reference/src/sock/nng_send.3.adoc b/docs/reference/src/sock/nng_send.3.adoc deleted file mode 100644 index 4932712a..00000000 --- a/docs/reference/src/sock/nng_send.3.adoc +++ /dev/null @@ -1,90 +0,0 @@ -# nng_send - -## NAME - -nng_send --- send data - -## SYNOPSIS - -``` -#include <nng/nng.h> - -int nng_send(nng_socket s, void *data, size_t size, int flags); -``` - -## DESCRIPTION - -The `nng_send()` function sends a message containing the _data_ of -length _size_ using the xref:nng_socket.5.adoc[socket] _s_. - -NOTE: The semantics of what sending a message means vary from protocol to -protocol, so examination of the protocol documentation is encouraged. -(For example, with an xref:nng_pub.7.adoc[_pub_] socket the data is broadcast, so that -any peers who have a suitable subscription will be able to receive it using -xref:nng_recv.3.adoc[`nng_recv()`] or a similar function.) -Furthermore, some protocols may not support sending data (such as -xref:nng_sub.7.adoc[_sub_]) or may require other conditions. -(For example, xref:nng_rep.7.adoc[_rep_] sockets cannot normally send data, -which are responses to requests, until they have first received a request.) - -The _flags_ may contain either of (or neither of) the following values: - -`NNG_FLAG_NONBLOCK`:: - The function returns immediately, regardless of whether - the socket is able to accept the data or not. If the socket is unable - to accept the data (such as if backpressure exists because the peers - are consuming messages too slowly, or no peer is present), then the - function will return with `NNG_EAGAIN`. If this flag is not specified, - then the function will block if such a condition exists. - -`NNG_FLAG_ALLOC`:: - The _data_ was allocated using xref:nng_alloc.3.adoc[`nng_alloc()`], or was - obtained from a call to xref:nng_recv.3.adoc[`nng_recv()`] with - the `NNG_FLAG_ALLOC` flag. - If this function returns success, then the _data_ is "owned" by the - function, and it will assume responsibility for calling - xref:nng_free.3.adoc[`nng_free()`] when it is no longer needed. - In the absence of this flag, the _data_ is copied by the implementation - before the function returns to the caller. - -TIP: The `NNG_FLAG_ALLOC` flag can be used to reduce data copies, thereby -increasing performance. - -NOTE: Regardless of the presence or absence of `NNG_FLAG_NONBLOCK`, there may -be queues between the sender and the receiver. -Furthermore, there is no guarantee that the message has actually been delivered. -Finally, with some protocols, the semantic is implicitly `NNG_FLAG_NONBLOCK`, -such as with xref:nng_pub.7.adoc[_pub_] sockets, which are best-effort delivery only. - -IMPORTANT: When using `NNG_FLAG_ALLOC`, it is important that the value of _size_ -match the actual allocated size of the data. -Using an incorrect size results -in unspecified behavior, which may include heap corruption, program crashes, -or trans-dimensional mutation of the program's author. - -## RETURN VALUES - -This function returns 0 on success, and non-zero otherwise. - -## ERRORS - -* `NNG_EAGAIN`: The operation would block, but `NNG_FLAG_NONBLOCK` was specified. -* `NNG_ECLOSED`: The socket _s_ is not open. -* `NNG_EINVAL`: An invalid set of _flags_ was specified. -* `NNG_EMSGSIZE`: The value of _size_ is too large. -* `NNG_ENOMEM`: Insufficient memory is available. -* `NNG_ENOTSUP`: The protocol for socket _s_ does not support sending. -* `NNG_ESTATE`: The socket _s_ cannot send data in this state. -* `NNG_ETIMEDOUT`: The operation timed out. - -## SEE ALSO - -[nng_alloc][nng_alloc], -[nng_free][nng_free], -[nng_recv][nng_recv], -[nng_sendmsg][nng_sendmsg], -[nng_strerror][nng_strerror], -[nng_socket][nng_socket], -[nng][nng] - -{{#include ../refs.md}} diff --git a/docs/reference/src/sock/nng_send.md b/docs/reference/src/sock/nng_send.md new file mode 100644 index 00000000..c36cedbb --- /dev/null +++ b/docs/reference/src/sock/nng_send.md @@ -0,0 +1,93 @@ +# nng_send + +## NAME + +nng_send --- send data + +## SYNOPSIS + +```c +#include <nng/nng.h> + +int nng_send(nng_socket s, void *data, size_t size, int flags); +``` + +## DESCRIPTION + +The `nng_send()` function sends a message containing the _data_ of +length _size_ using the [socket][socket] _s_. + +> [!NOTE] +> The semantics of what sending a message means vary from protocol to +> protocol, so examination of the protocol documentation is encouraged. +> For example, on [_PUB_][pub] sockets the data is broadcast, so that +> any peers who have a suitable subscription will be able to receive it. +> Furthermore, some protocols may not support sending data +> or may require other conditions. +> For example, [_REP_][rep] sockets cannot normally send data +> until they have first received a request.) + +The _flags_ may contain either of (or neither of) the following values: + +- {{i:`NNG_FLAG_NONBLOCK`}}: \ + The function returns immediately, regardless of whether + the socket is able to accept the data or not. If the socket is unable + to accept the data (such as if backpressure exists because the peers + are consuming messages too slowly, or no peer is present), then the + function will return with `NNG_EAGAIN`. If this flag is not specified, + then the function will block if such a condition exists. + +- {{i:`NNG_FLAG_ALLOC`}}: \ + The _data_ was allocated using [`nng_alloc()`][nng_alloc], or was + obtained from a call to [`nng_recv()`][nng_recv] with + the `NNG_FLAG_ALLOC` flag. + If this function returns success, then the _data_ is "owned" by the + function, and it will assume responsibility for calling + [`nng_free()`][nng_free] when it is no longer needed. + In the absence of this flag, the _data_ is copied by the implementation + before the function returns to the caller. + +> [!TIP] +> The `NNG_FLAG_ALLOC` flag can be used to reduce data copies, thereby +> increasing performance. However, the [`nng_sendmsg()`][nng_sendmsg] function is even better in this regard, and should be preferred over this +> function when possible. + +> [!NOTE] +> Regardless of the presence or absence of `NNG_FLAG_NONBLOCK`, there may +> be queues between the sender and the receiver. +> Furthermore, there is no guarantee that the message has actually been delivered. +> Finally, with some protocols, the semantic is implicitly `NNG_FLAG_NONBLOCK`, +> such as with _PUB_ sockets, which are best-effort delivery only. + +> [!IMPORTANT] +> When using `NNG_FLAG_ALLOC`, it is important that the value of _size_ +> match the actual allocated size of the data. +> Using an incorrect size results +> in unspecified behavior, which may include heap corruption, program crashes, +> or teleportation of the program's author to an alternate universe. + +## RETURN VALUES + +This function returns 0 on success, and non-zero otherwise. + +## ERRORS + +- `NNG_EAGAIN`: The operation would block, but `NNG_FLAG_NONBLOCK` was specified. +- `NNG_ECLOSED`: The socket _s_ is not open. +- `NNG_EINVAL`: An invalid set of _flags_ was specified. +- `NNG_EMSGSIZE`: The value of _size_ is too large. +- `NNG_ENOMEM`: Insufficient memory is available. +- `NNG_ENOTSUP`: The protocol for socket _s_ does not support sending. +- `NNG_ESTATE`: The socket _s_ cannot send data in this state. +- `NNG_ETIMEDOUT`: The operation timed out. + +## SEE ALSO + +[Sockets][socket], +[nng_alloc][nng_alloc], +[nng_free][nng_free], +[nng_recv][nng_recv], +[nng_send_aio][nng_send_aio], +[nng_sendmsg][nng_sendmsg] + +{{#include ../refs.md}} diff --git a/docs/reference/src/sock/nng_send_aio.3.adoc b/docs/reference/src/sock/nng_send_aio.3.adoc deleted file mode 100644 index 4597619c..00000000 --- a/docs/reference/src/sock/nng_send_aio.3.adoc +++ /dev/null @@ -1,81 +0,0 @@ -# nng_send_aio - -## NAME - -nng_send_aio --- send message asynchronously - -## SYNOPSIS - -``` -#include <nng/nng.h> - -void nng_send_aio(nng_socket s, nng_aio *aio); -``` - -## DESCRIPTION - -The `nng_send_aio()` sends a xref:nng_msg.5.adoc[message] using the -xref:nng_socket.5.adoc[socket] _s_ asynchronously. - -The message to send must have previously been set on the _aio_ -using the xref:nng_aio_set_msg.3.adoc[`nng_aio_set_msg()`] function. -The function assumes ownership of the message. - -If the message was successfully queued for delivery to the socket, -then the _aio_ will be completed, and xref:nng_aio_result.3.adoc[`nng_aio_result()`] -will return zero. In this case the socket will dispose of the -message when it is finished with it. - -NOTE: The operation will be completed, and the callback associated -with the _aio_ executed, as soon as the socket accepts the message -for sending. -This does _not_ indicate that the message was actually delivered, as it -may still be buffered in the sending socket, buffered in the receiving -socket, or in flight over physical media. - -If the operation fails for any reason (including cancellation or timeout), -then the _aio_ callback will be executed and -xref:nng_aio_result.3.adoc[`nng_aio_result()`] -will return a non-zero error status. -In this case, the callback has a responsibility to retrieve the message from -the _aio_ with -xref:nng_aio_get_msg.3.adoc[`nng_aio_get_msg()`] and dispose of it appropriately. -(This may include retrying the send operation on the same or a different -socket, or deallocating the message with xref:nng_msg_free.3.adoc[`nng_msg_free()`].) - -NOTE: The semantics of what sending a message means varies from protocol to -protocol, so examination of the protocol documentation is encouraged. -(For example, with a xref:nng_pub.7.adoc[_pub_] socket the data is broadcast, so that -any peers who have a suitable subscription will be able to receive it using -xref:nng_recv.3.adoc[`nng_recv()`] or a similar function.) -Furthermore, some protocols may not support sending (such as -xref:nng_sub.7.adoc[_sub_]) or may require other conditions. -(For example, xref:nng_rep.7.adoc[_rep_] sockets cannot normally send data, which -are responses to requests, until they have first received a request.) - -## RETURN VALUES - -None. (The operation completes asynchronously.) - -## ERRORS - -* `NNG_ECANCELED`: The operation was aborted. -* `NNG_ECLOSED`: The socket _s_ is not open. -* `NNG_EMSGSIZE`: The message is too large. -* `NNG_ENOMEM`: Insufficient memory is available. -* `NNG_ENOTSUP`: The protocol for socket _s_ does not support sending. -* `NNG_ESTATE`: The socket _s_ cannot send data in this state. -* `NNG_ETIMEDOUT`: The send timeout expired. - -## SEE ALSO - -[nng_aio_get_msg][nng_aio_get_msg], -[nng_aio_set_msg][nng_aio_set_msg], -[nng_msg_alloc][nng_msg_alloc], -[nng_strerror][nng_strerror], -[nng_aio][nng_aio], -[nng_msg][nng_msg], -[nng_socket][nng_socket], -[nng][nng] - -{{#include ../refs.md}} diff --git a/docs/reference/src/sock/nng_send_aio.md b/docs/reference/src/sock/nng_send_aio.md new file mode 100644 index 00000000..9f6b43c8 --- /dev/null +++ b/docs/reference/src/sock/nng_send_aio.md @@ -0,0 +1,75 @@ +# nng_send_aio + +## NAME + +nng_send_aio --- send message asynchronously + +## SYNOPSIS + +``` +#include <nng/nng.h> + +void nng_send_aio(nng_socket s, nng_aio *aio); +``` + +## DESCRIPTION + +The `nng_send_aio()` sends a [message][msg] using the +[socket][socket] _s_ asynchronously. + +The message to send must have previously been set on the _aio_ +using the [`nng_aio_set_msg()`][nng_aio_set_msg] function. +The function assumes ownership of the message. + +If the message was successfully queued for delivery to the socket, +then the _aio_ will complete[^1], and [`nng_aio_result()`][nng_aio_result] +will return zero. In this case the socket will dispose of the +message when it is finished with it. + +[^1]: + This does _not_ indicate that the message was actually delivered, as it + may still be buffered in the sending socket, buffered in the receiving + socket, or in flight over physical media. + +If the operation fails for any reason (including cancellation or timeout), +then the _aio_ {{i:callback}} will be executed and +`nng_aio_result()` will return a non-zero error status. + +In this case, the callback has a responsibility to retrieve the message from +the _aio_ with +[`nng_aio_get_msg()`][nng_aio_get_msg] and dispose of it appropriately. [^2] +(This may include retrying the send operation on the same or a different +socket, or deallocating the message with [`nng_msg_free()`][nng_msg_free].) + +[^2]: Failure to do so will leak the memory associated with the message. + +> [!NOTE] +> The semantics of what sending a message means varies from protocol to +> protocol, so examination of the protocol documentation is encouraged. +> Furthermore, some protocols may not support sending, +> or may only permit sending when other conditions are met. + +## RETURN VALUES + +None. (The operation completes asynchronously.) + +## ERRORS + +- `NNG_ECANCELED`: The operation was aborted. +- `NNG_ECLOSED`: The socket _s_ is not open. +- `NNG_EMSGSIZE`: The message is too large. +- `NNG_ENOMEM`: Insufficient memory is available. +- `NNG_ENOTSUP`: The protocol for socket _s_ does not support sending. +- `NNG_ESTATE`: The socket _s_ cannot send data in this state. +- `NNG_ETIMEDOUT`: The send timeout expired. + +## SEE ALSO + +[Asynchronous I/O][aio], +[Messages][msg], +[Sockets][socket], +[nng_aio_get_msg][nng_aio_get_msg], +[nng_aio_set_msg][nng_aio_set_msg], +[nng_msg_alloc][nng_msg_alloc] + +{{#include ../refs.md}} diff --git a/docs/reference/src/sock/nng_sendmsg.3.adoc b/docs/reference/src/sock/nng_sendmsg.3.adoc deleted file mode 100644 index 004ae78d..00000000 --- a/docs/reference/src/sock/nng_sendmsg.3.adoc +++ /dev/null @@ -1,84 +0,0 @@ -# nng_sendmsg - -## NAME - -nng_sendmsg --- send message - -## SYNOPSIS - -``` -#include <nng/nng.h> - -int nng_sendmsg(nng_socket s, nng_msg *msg, int flags); -``` - -## DESCRIPTION - -The `nng_sendmsg()` sends message _msg_ using the socket _s_. - -If the function returns zero, indicating it has accepted the message for -delivery, then the _msg_ is owned by the socket _s_, and the caller -must not make any further use of it. -The socket will free the message when it is finished. - -If the function returns non-zero, then it is the caller's responsibility -to dispose of the _msg_, which may include freeing it, sending it to -another socket, or simply trying again later. - -TIP: Using this function gives access to the message structure, and may -offer more functionality than the simpler xref:nng_send.3.adoc[`nng_send()`] function. - -NOTE: The semantics of what sending a message means vary from protocol to -protocol, so examination of the protocol documentation is encouraged. -(For example, with a xref:nng_pub.7.adoc[_pub_] socket the data is broadcast, so that -any peers who have a suitable subscription will be able to receive it using -xref:nng_recv.3.adoc[`nng_recv()`] or a similar function.) -Furthermore, some protocols may not support sending (such as -xref:nng_sub.7.adoc[_sub_]) or may require other conditions. -(For example, xref:nng_rep.7.adoc[_rep_] sockets cannot normally send data, which -are responses to requests, until they have first received a request.) - -The _flags_ may contain the following value: - -`NNG_FLAG_NONBLOCK`:: - The function returns immediately, regardless of whether - the socket is able to accept the data or not. - If the socket is unable to accept the data (such as if backpressure exists - because the peers are consuming messages too slowly, or no peer is present), - then the function will return with `NNG_EAGAIN`. - If this flag is not specified, then the function will block if such a - condition exists. - - -NOTE: Regardless of the presence or absence of `NNG_FLAG_NONBLOCK`, there may -be queues between the sender and the receiver. -Furthermore, there is no guarantee that the message has actually been delivered. -Finally, with some protocols, the semantic is implicitly `NNG_FLAG_NONBLOCK`, -such as with xref:nng_pub.7.adoc[_pub_] sockets, which are best-effort delivery only. - -## RETURN VALUES - -This function returns 0 on success, and non-zero otherwise. - -## ERRORS - -* `NNG_EAGAIN`: The operation would block, but `NNG_FLAG_NONBLOCK` was specified. -* `NNG_ECLOSED`: The socket _s_ is not open. -* `NNG_EINVAL`: An invalid set of _flags_ was specified. -* `NNG_EMSGSIZE`: The value of _size_ is too large. -* `NNG_ENOMEM`: Insufficient memory is available. -* `NNG_ENOTSUP`: The protocol for socket _s_ does not support sending. -* `NNG_ESTATE`: The socket _s_ cannot send data in this state. -* `NNG_ETIMEDOUT`: The operation timed out. - -## SEE ALSO - -[nng_msg_alloc][nng_msg_alloc], -[nng_recvmsg][nng_recvmsg], -[nng_send][nng_send], -[nng_strerror][nng_strerror], -[nng_msg][nng_msg], -[nng_socket][nng_socket], -[nng][nng] - -{{#include ../refs.md}} diff --git a/docs/reference/src/sock/nng_sendmsg.md b/docs/reference/src/sock/nng_sendmsg.md new file mode 100644 index 00000000..31ad67de --- /dev/null +++ b/docs/reference/src/sock/nng_sendmsg.md @@ -0,0 +1,82 @@ +# nng_sendmsg + +## NAME + +nng_sendmsg --- send message + +## SYNOPSIS + +```c +#include <nng/nng.h> + +int nng_sendmsg(nng_socket s, nng_msg *msg, int flags); +``` + +## DESCRIPTION + +The `nng_sendmsg()` sends [message][msg] _msg_ using the [socket][socket] _s_. + +If the function returns zero, indicating it has accepted the message for +delivery, then the _msg_ is owned by the socket _s_, and the caller +must not make any further use of it. +The socket will free the message when it is finished. + +If the function returns non-zero, then it is the caller's responsibility +to dispose of the _msg_, which may include freeing it, sending it to +another socket, or simply trying again later. + +> [!TIP] +> Using this function gives access to the message structure, and may +> offer more functionality than the simpler [`nng_send()`][nng_send] function. [^1] [^2] + +[^1]: It is also more efficient. +[^2]: An asynchronous form of this function is available as [`nng_send_aio()`][nng_send_aio]. + +> [!NOTE] +> The semantics of what sending a message means vary from protocol to +> protocol, so examination of the protocol documentation is encouraged. +> Furthermore, some protocols may not support sending messages +> or may require other conditions be met first before sending messages. + +The _flags_ may contain the following value: + +- {{i:`NNG_FLAG_NONBLOCK`}}: + The function returns immediately, regardless of whether + the socket is able to accept the data or not. + If the socket is unable to accept the data (such as if {{i:back-pressure}} exists + because the peers are consuming messages too slowly, or no peer is present), + then the function will return with `NNG_EAGAIN`. + If this flag is not specified, then the function will block if such a + condition exists. + +> [!NOTE] +> Regardless of the presence or absence of `NNG_FLAG_NONBLOCK`, there may +> be queues between the sender and the receiver. +> Furthermore, there is no guarantee that the message has actually been delivered. +> Finally, with some protocols, the semantic is implicitly `NNG_FLAG_NONBLOCK`, +> such as with [_PUB_][pub] sockets, which are {{i:best-effort}} delivery only. + +## RETURN VALUES + +This function returns 0 on success, and non-zero otherwise. + +## ERRORS + +- `NNG_EAGAIN`: The operation would block, but `NNG_FLAG_NONBLOCK` was specified. +- `NNG_ECLOSED`: The socket _s_ is not open. +- `NNG_EINVAL`: An invalid set of _flags_ was specified. +- `NNG_EMSGSIZE`: The value of _size_ is too large. +- `NNG_ENOMEM`: Insufficient memory is available. +- `NNG_ENOTSUP`: The protocol for socket _s_ does not support sending. +- `NNG_ESTATE`: The socket _s_ cannot send data in this state. +- `NNG_ETIMEDOUT`: The operation timed out. + +## SEE ALSO + +[Messages][msg], +[Sockets][socket], +[nng_msg_alloc][nng_msg_alloc], +[nng_recvmsg][nng_recvmsg], +[nng_send][nng_send] + +{{#include ../refs.md}} |
