SEND(2)

πŸ’Œ SEND(2) β€” the system calls manual, but make it cute

okay bestie, sit down, hydrate, because we're about to talk about sending messages from a socket and honestly? it's giving main character energy. this is the SEND(2) page from the System Calls Manual and it's lowkey iconic. πŸ¦‹


✨ NAME ✨

send, sendto, sendmsg, sendmmsg β€” send message(s) from a socket πŸ’…


πŸ“š LIBRARY πŸ“š

Standard C Library (libc, -lc)


🫢 SYNOPSIS 🫢

like, here's the whole friend group:

#include <sys/socket.h>

ssize_t
send(int s, const void *msg, size_t len, int flags);

ssize_t
sendto(int s, const void *msg, size_t len, int flags,
    const struct sockaddr *to, socklen_t tolen);

ssize_t
sendmsg(int s, const struct msghdr *msg, int flags);

ssize_t
sendmmsg(int s, struct mmsghdr * restrict msgvec, size_t vlen,
    int flags);

🌸 DESCRIPTION 🌸

so. the send() and sendmmsg() functions, plus the sendto() and sendmsg() system calls, are the ones you use to transmit one or more messages (that "more" is the sendmmsg() call's whole thing) to another socket. πŸ’–

the send() function? it's picky. it may be used only when the socket is in a connected state. no connection, no send, sorry babe.

the sendto(), sendmsg() and sendmmsg() functions are way more chill β€” they may be used at any time if the socket is connectionless-mode. and if the socket is connection-mode? then the protocol must support implied connect (currently tcp(4) is the only protocol with support, so it's the only one in the group chat) or the socket must be in a connected state before use. periodt.

the address of the target is given by to, with tolen specifying its size β€” or the equivalent msg_name and msg_namelen in struct msghdr. and here's a thing: if the socket is in a connected state, the target address you pass to sendto(), sendmsg() or sendmmsg() is just... ignored. πŸ™ˆ the length of the message is given by len. and if the message is too long to pass atomically through the underlying protocol, the error EMSGSIZE is returned and the message is not transmitted. no partial vibes, it's all or nothing.

sendmmsg() sends multiple messages in one call, which is highkey efficient. they're given by the msgvec vector along with vlen specifying the vector size. the number of octets sent per each message is placed in the msg_len field of each processed element of the vector after transmission. cute, right?

no indication of failure to deliver is implicit in a send(). locally detected errors are indicated by a return value of -1. that's it, that's the signal. 😭

if no messages space is available at the socket to hold the message to be transmitted, then send() normally blocks β€” unless the socket has been placed in non-blocking I/O mode. and the select(2) system call may be used to determine when it is possible to send more data. use your tools, bestie.

the flags argument may include one or more of the following, and we are keeping these exactly as written, no edits, we respect the source:

#define MSG_OOB         0x00001 /* process out-of-band data */
#define MSG_DONTROUTE   0x00004 /* bypass routing, use direct interface */
#define MSG_EOR         0x00008 /* data completes record */
#define MSG_DONTWAIT    0x00080 /* do not block */
#define MSG_EOF         0x00100 /* data completes transaction */
#define MSG_NOSIGNAL    0x20000 /* do not generate SIGPIPE on EOF */

now let's break those down because each one has a personality:

  • the flag MSG_OOB is used to send "out-of-band" data on sockets that support this notion (e.g. SOCK_STREAM); the underlying protocol must also support "out-of-band" data. it's the VIP entrance, but the club has to actually have a VIP entrance.
  • MSG_EOR is used to indicate a record mark for protocols which support the concept.
  • the MSG_DONTWAIT flag requests the call to return when it would block otherwise. not me waiting, actually β€” you wait.
  • MSG_EOF requests that the sender side of a socket be shut down, and that an appropriate indication be sent at the end of the specified data; this flag is only implemented for SOCK_STREAM sockets in the PF_INET protocol family. niche but iconic.
  • MSG_DONTROUTE is usually used only by diagnostic or routing programs. it's giving "I know a shortcut."
  • MSG_NOSIGNAL is used to prevent SIGPIPE generation when writing a socket that may be closed. extremely thoughtful of it.

see recv(2) for a description of the msghdr structure and the mmsghdr structure. go read it, it's the other half of this conversation. 🫢


πŸ’« RETURN VALUES πŸ’«

  • the send(), sendto() and sendmsg() calls return the number of octets sent.
  • the sendmmsg() call returns the number of messages sent (different unit, don't mix them up bestie).
  • if an error occurred, a value of -1 is returned.

🚨 ERRORS 🚨

the send() and sendmmsg() functions and sendto() and sendmsg() system calls fail if:

  • [EBADF] β€” an invalid descriptor was specified.
  • [EACCES] β€” the destination address is a broadcast address, and SO_BROADCAST has not been set on the socket.
  • [ENOTCONN] β€” the socket is connection-mode but is not connected.
  • [ENOTSOCK] β€” the argument s is not a socket. (rude of you, honestly)
  • [EFAULT] β€” an invalid user space address was specified for an argument.
  • [EMSGSIZE] β€” the socket requires that message be sent atomically, and the size of the message to be sent made this impossible.
  • [EAGAIN] β€” the socket is marked non-blocking, or MSG_DONTWAIT is specified, and the requested operation would block.
  • [ENOBUFS] β€” the system was unable to allocate an internal buffer. the operation may succeed when buffers become available.
  • [ENOBUFS] β€” the output queue for a network interface was full. this generally indicates that the interface has stopped sending, but may be caused by transient congestion. (yes, ENOBUFS shows up twice, that's not a typo, that's canon πŸ’€)
  • [EHOSTUNREACH] β€” the remote host was unreachable.
  • [EISCONN] β€” a destination address was specified and the socket is already connected.
  • [ECONNREFUSED] β€” the socket received an ICMP destination unreachable message from the last message sent. this typically means that the receiver is not listening on the remote port.
  • [EHOSTDOWN] β€” the remote host was down.
  • [ENETDOWN] β€” the remote network was down.
  • [EADDRNOTAVAIL] β€” the process using a SOCK_RAW socket was jailed and the source address specified in the IP header did not match the IP address bound to the prison.
  • [EPIPE] β€” the socket is unable to send anymore data (SBS_CANTSENDMORE has been set on the socket). this typically means that the socket is not connected.

πŸ‘€ SEE ALSO πŸ‘€

connect(2), fcntl(2), getsockopt(2), recv(2), select(2), socket(2), write(2), CMSG_DATA(3)


πŸ•°οΈ HISTORY πŸ•°οΈ

  • the send() function appeared in 4.2BSD.
  • the sendmmsg() function appeared in FreeBSD 11.0.

πŸ› BUGS πŸ› (yes we're doing bugs, stay with me)

because sendmsg() does not necessarily block until the data has been transferred, it is possible to transfer an open file descriptor across an AF_UNIX domain socket (see recv(2)), then close() it before it has actually been sent β€” the result being that the receiver gets a closed file descriptor. πŸ’€ it is left to the application to implement an acknowledgment mechanism to prevent this from happening.

so like... the kernel is not gonna hold your hand here. build the ack yourself. that's the assignment. πŸ“


and that's the whole page bestie!! this was Debian's version, dated April 27, 2020 β€” genuinely one of the greats. go send a message. responsibly. πŸŽ€βœ¨

πŸ“¦ where this page comes from