SCTP_RECVMSG(3) FreeBSD Library Functions Manual SCTP_RECVMSG(3)
NAME
sctp_recvmsg, sctp_recvv - receive a message from an SCTP socket
LIBRARY
Standard C Library (libc, -lc)
SYNOPSIS
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/sctp.h>
ssize_t
sctp_recvmsg(int s, void *msg, size_t len, struct sockaddr *from,
socklen_t *fromlen, struct sctp_sndrcvinfo *sinfo, int *flags);
ssize_t
sctp_recvv(int s, const struct iovec *iov, int iovlen,
struct sockaddr *from, socklen_t *fromlen, void *info,
socklen_t *infolen, unsigned int *infotype, int *flags);
DESCRIPTION
The sctp_recvmsg() and sctp_recvv() functions are used to receive a
message from another SCTP endpoint. They are used by one-to-one
(SOCK_STREAM) type sockets after a successful connect() call or after the
application has performed a listen() followed by a successful accept().
For a one-to-many (SOCK_SEQPACKET) type socket, an endpoint may call
sctp_recvmsg() or sctp_recvv() after having implicitly started an
association via one of the send calls including sctp_sendmsg(), sendto()
and sendmsg(). Or, an application may also receive a message after
having called listen() with a positive backlog to enable the reception of
new associations.
The address of the sender is held in the from argument with fromlen
specifying its size. At the completion of a successful sctp_recvmsg()
call from will hold the address of the peer and fromlen will hold the
length of that address. Note that the address is bounded by the initial
value of fromlen which is used as an in/out variable.
The length of the message msg to be received is bounded by len. If the
message is too long to fit in the users receive buffer, then the flags
argument will not have the MSG_EOR flag applied. If the message is a
complete message then the flags argument will have MSG_EOR set. Locally
detected errors are indicated by a return value of -1 with errno set
accordingly. The flags argument may also hold the value
MSG_NOTIFICATION. When this occurs it indicates that the message
received is not from the peer endpoint, but instead is a notification
from the SCTP stack (see sctp(4) for more details). Note that no
notifications are ever given unless the user subscribes to such
notifications using the SCTP_EVENTS socket option.
If no messages are available at the socket then sctp_recvmsg() normally
blocks on the reception of a message or NOTIFICATION, unless the socket
has been placed in non-blocking I/O mode. The select(2) system call may
be used to determine when it is possible to receive a message.
The sinfo argument is defined as follows.
struct sctp_sndrcvinfo {
uint16_t sinfo_stream; /* Stream arriving on */
uint16_t sinfo_ssn; /* Stream Sequence Number */
uint16_t sinfo_flags; /* Flags on the incoming message */
uint32_t sinfo_ppid; /* The ppid field */
uint32_t sinfo_context; /* context field */
uint32_t sinfo_timetolive; /* not used by sctp_recvmsg */
uint32_t sinfo_tsn; /* The transport sequence number */
uint32_t sinfo_cumtsn; /* The cumulative acknowledgment point */
sctp_assoc_t sinfo_assoc_id; /* The association id of the peer */
};
The sinfo->sinfo_ppid field is an opaque 32 bit value that is passed
transparently through the stack from the peer endpoint. Note that the
stack passes this value without regard to byte order.
The sinfo->sinfo_flags field may include the following:
#define SCTP_UNORDERED 0x0400 /* Message is un-ordered */
The SCTP_UNORDERED flag is used to specify that the message arrived with
no specific order and was delivered to the peer application as soon as
possible. When this flag is absent the message was delivered in order
within the stream it was received.
The sinfo->sinfo_stream field is the SCTP stream that the message was
received on. Streams in SCTP are reliable (or partially reliable) flows
of ordered messages.
The sinfo->sinfo_context field is used only if the local application set
an association level context with the SCTP_CONTEXT socket option.
Optionally a user process can use this value to index some application
specific data structure for all data coming from a specific association.
The sinfo->sinfo_ssn field will hold the stream sequence number assigned
by the peer endpoint if the message is not unordered. For unordered
messages this field holds an undefined value.
The sinfo->sinfo_tsn field holds a transport sequence number (TSN) that
was assigned to this message by the peer endpoint. For messages that fit
in or less than the path MTU this will be the only TSN assigned. Note
that for messages that span multiple TSNs this value will be one of the
TSNs that was used on the message.
The sinfo->sinfo_cumtsn field holds the current cumulative acknowledgment
point of the transport association. Note that this may be larger or
smaller than the TSN assigned to the message itself.
The sinfo->sinfo_assoc_id is the unique association identification that
was assigned to the association. For one-to-many (SOCK_SEQPACKET) type
sockets this value can be used to send data to the peer without the use
of an address field. It is also quite useful in setting various socket
options on the specific association (see sctp(4)).
The sinfo->info_timetolive field is not used by sctp_recvmsg().
The sctp_recvv() function works as sctp_recvmsg() with two differences.
Firstly, the receive buffer is passed as an array containing iocnt
objects of type struct iovec, where the received data will be scattered
in the same manner as readv(2). Secondly, the sinfo argument is replaced
by the tuple info, infolen, and infotype, which allow different
information to be received based on the socket options.
To receive an sctp_rcvinfo structure, set the SCTP_RECVRCVINFO socket
option, and pass a pointer to a struct sctp_rcvinfo structure in info.
The sctp_rcvinfo structure has the following format:
struct sctp_rcvinfo {
uint16_t rcv_sid; /* Stream arriving on */
uint16_t rcv_ssn; /* Stream Sequence Number */
uint16_t rcv_flags; /* Flags on the incoming message */
uint32_t rcv_ppid; /* The ppid field */
uint32_t rcv_tsn; /* The transport sequence number */
uint32_t rcv_cumtsn; /* The cumulative TSN */
uint32_t rcv_context; /* Opaque context field */
sctp_assoc_t rcv_assoc_id; /* Peer association id */
};
These fields have the same meaning as the equivalent fields in struct
sctp_sndrcvinfo, defined above.
To receive an sctp_nxtinfo structure, set the SCTP_RECVNXTINFO socket
option, and pass a pointer to a struct sctp_nxtinfo structure in info.
The struct sctp_nxtinfo structure has the following format:
struct sctp_nxtinfo {
uint16_t nxt_sid; /* Next message's stream number */
uint16_t nxt_flags; /* Flags (see below) */
uint32_t nxt_ppid; /* The ppid field */
uint32_t nxt_length; /* Length of next message */
sctp_assoc_t nxt_assoc_id; /* Peer association id */
};
The fields nxt_sid, nxt_ppid, and nxt_assoc_id have the same meaning as
in struct sctp_rcvinfo, except they refer to the next message rather than
the message that was received. The field nxt_length contains the length
of the part of the next message currently available in the socket buffer.
This may not represent the length of the entire message unless the
SCTP_COMPLETE flag is set in nxt_flags.
The nxt_flags field is a bitmask which may contain any of the following
values:
o SCTP_UNORDERED: The next message was sent unordered.
o SCTP_COMPLETE: The entirety of the next message has been received in
the socket buffer. In this case, the nxt_length field contains the
length of the entire message.
o SCTP_NOTIFICATION: The next message is a notification, not a user
message.
If both the SCTP_RECVRCVINFO and SCTP_RECVNXTINFO socket options are set,
then pass a pointer to a struct sctp_recvv_rn structure in info. This
struct has the following format:
struct sctp_recvv_rn {
struct sctp_rcvinfo recvv_rcvinfo;
struct sctp_nxtinfo recvv_nxtinfo;
};
The value pointed to by infolen should initially contain the length of
the structure to which info points. When the function returns, it will
be set to the length of the returned structure. Additionally, *infotype
will be set to one of the following values depending on what type of info
was returned:
o SCTP_RECVV_NOINFO: no information was returned.
o SCTP_RECVV_RCVINFO: *info contains an object of type struct
sctp_rcvinfo.
o SCTP_RECVV_NXTINFO: *info contains an object of type struct
sctp_nxtinfo.
o SCTP_RECVV_RN: *info contains an object of type struct sctp_recvv_rn.
RETURN VALUES
The call returns the number of bytes received, or -1 if an error
occurred.
ERRORS
The sctp_recvmsg() system call fails if:
[EBADF] An invalid descriptor was specified.
[ENOTSOCK] The argument s is not a socket.
[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 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.
[EHOSTUNREACH] The remote host was unreachable.
[ENOTCONN] On a one-to-one style socket no association exists.
[ECONNRESET] An abort was received by the stack while the user was
attempting to send data to the peer.
[ENOENT] On a one to many style socket no address is specified
so that the association cannot be located or the
SCTP_ABORT flag was specified on a non-existing
association.
[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 and
is a one-to-one style socket.
NOTES
The sctp_recvmsg() function is deprecated. New applications should use
sctp_recvv().
SEE ALSO
getsockopt(2), recv(2), select(2), sendmsg(2), setsockopt(2), socket(2),
write(2), sctp_send(3), sctp_sendmsg(3), sctp(4)
R. Stewart, M. Tuexen, K. Poon, P. Lei, and V. Yasevich, Sockets API
Extensions for the Stream Control Transmission Protocol (SCTP), RFC 6458,
December 2011.
STANDARDS
The functions described in this document conform to RFC 6458.
FreeBSD 15.1-STABLE-HBSD May 2, 2024 SCTP_RECVMSG(3)