NN_RECV(3)
π NN_RECV(3) π
okay bestie, welcome to nn_recv β the nanomsg 1.2.2 era, the "receive a message" girlie. she's giving inbox energy, and she's about to hand you a whole message. sit down, hydrate, let's go π
β¨ NAME β¨
nn_recv β receive a message π«Ά
πΈ SYNOPSIS πΈ
#include <nanomsg/nn.h>
int nn_recv (int s, void *buf, size_t len, int flags);
π DESCRIPTION π
So basically: you pull a message off the socket s and it gets dropped into the buffer that buf points at. Anything in the message that's longer than len? Truncated. gone. bye. βοΈ The bytes that exceed the length you specified in len get cut off, no cap.
BUT WAIT β there's a second option and it's lowkey iconic. nanomsg can allocate the buffer for you π§. To do that, you let the buf parameter be a pointer to a void* variable (yes, a pointer to pointer, we're being fancy), pointing at the receive buffer, and you set len to NN_MSG. If the call succeeds, guess what β the user is responsible for deallocating the message using the nn_freemsg(3) function. that's on you, bestie, not on the library π
The flags argument is a combination of the flags defined below:
NN_DONTWAITβ says the operation should happen in non-blocking mode. If the message can't be received straight away, the function will fail witherrnoset toEAGAIN. no waiting, no queuing, no patience π
β RETURN VALUE β
If it works? you get the number of bytes in the message. slay. β¨
If it doesn't? you get -1, and errno is set to one of the values defined right down below π
π₯ ERRORS π₯
EBADFβ the socket you handed over is invalid. girl, that socket does not exist πENOTSUPβ this socket type simply doesn't support this operation. not every socket is built for this, and that's fine πEFSMβ the operation can't be performed on this socket right now because the socket isn't in the appropriate state. this one can pop up with socket types that switch between several states, so likeβ¦ mood swings, but for sockets π¦EAGAINβ non-blocking mode was requested and there's literally no message to receive at this moment. empty inbox behaviour πEINTRβ the operation got interrupted by a signal being delivered before the message was actually received π΅ETIMEDOUTβ individual socket types may define their own specific timeouts, and if such a timeout gets hit, this error is what you get. time's up, babe β°ETERMβ the library is terminating. we're shutting the whole thing down π«‘
π EXAMPLES π
π Receiving a message into a buffer allocated by the user
This example code will retrieve a message of either 100 bytes or less. If a larger message was sent it will be truncated to 100 bytes.
char buf [100];
nbytes = nn_recv (s, buf, sizeof (buf), 0);
π Receiving a message into a buffer allocated by nanomsg
The following will get a message from the pipe with a buffer allocated by the system. It is large enough to accommodate the entire message. This is a good way to get the entire message without truncating if the size of the message is unknown. It is the user's responsibility to call nn_freemsg(3) after processing the message.
void *buf = NULL;
nbytes = nn_recv (s, &buf, NN_MSG, 0);
if (nbytes < 0) {
/* handle error */
...
}
else {
/* process message */
...
nn_freemsg (buf);
}
Note that this can be more efficient than manually allocating a buffer since it is a zero-copy operation. no copying, just vibes β¨
π SEE ALSO π
nn_send(3) nn_recvmsg(3) nn_socket(3) nanomsg(7)
π AUTHORS π
Martin Sustrik <sustrik@250bpm.com>
and that's the whole page, bestie!! π this one was dated 2026-01-16 and it's serving pure nanomsg 1.2.2 realness, mwah π go receive some messages, you've got this π«Άβ¨
π¦ where this page comes from
- fedora 44: nanomsg-devel 1.2.2-2.fc44 Β· MIT
- fedora 44: nanomsg-devel 1.2.2-2.fc44 Β· MIT
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms