Elementary SCTP Sockets
Introduction
SCTP is a newer transport protocol, standardized in the IETF in 2000 (compared with TCP, which was standardized in 1981). It was first designed to meet the needs of the growing IP telephony market; in particular, transporting telephony signaling across the Internet. The requirements it was designed to fulfill are described in RFC 2719 [Ong et al. 1999]. SCTP is a reliable, message-oriented protocol, providing multiple streams between endpoints and transport-level support for multihoming. Since it is a newer transport protocol, it does not have the same ubiquity as TCP or UDP; however, it provides some new features that may simplify certain application designs. We will discuss the reasons to consider using SCTP instead of TCP in Section 23.12(See 9.12.12).
Interface Models
There are two types of SCTP sockets: a one-to-one socket and a one-to-many socket. A one-to-one socket corresponds to exactly one SCTP association. (Recall from Section 2.5(See 7.2.5) that an SCTP association is a connection between two systems, but may involve more than two IP addresses due to multihoming.) This mapping is similar to the relationship between a TCP socket and a TCP connection. With a one-to-many socket, several SCTP associations can be active on a given socket simultaneously. This mapping is similar to the manner in which a UDP socket bound to a particular port can receive interleaved datagrams from several remote UDP endpoints that are all simultaneously sending data.
When deciding which style of interface to use, the application needs to consider several factors, including:
- What type of server is being written, iterative or concurrent?
- How many socket descriptors does the server wish to manage?
- Is it important to optimize the association setup to enable data on the third (and possibly fourth) packet of the four-way handshake?
- How much connection state does the application wish to maintain?
The One-to-One Style
The one-to-one style was developed to ease the porting of existing TCP applications to SCTP. It provides nearly an identical model to that described in Chapter 4(See 8.2).
1.Any socket options must be converted to the SCTP equivalent. Two commonly found options are TCP_NODELAY and TCP_MAXSEG. These can be easily mapped to SCTP_NODELAY and SCTP_MAXSEG.
2.SCTP preserves message boundaries; thus, application-layer message boundaries are not required. For example, an application protocol based on TCP might do a write() system call to write a two-byte message length field, x, followed by a write() system call that writes x bytes of data. However, if this is done with SCTP, the receiving SCTP will receive two separate messages (i.e., the read call will return twice: once with a two-byte message, and then again with an x byte message).
3.Some TCP applications use a half-close to signal the end of input to the other side. To port such applications to SCTP, the application-layer protocol will need to be rewritten so that the application signals the end of input in the application data stream.
4.The send function can be used in the normal fashion. For the sendto and sendmsg functions, any address information included is treated as an override of the primary destination address (see Section 2.8(See 7.2.8)).
The One-to-Many Style
The one-to-many style provides an application writer the ability to write a server without managing a large number of socket descriptors. A single socket descriptor will represent multiple associations, much the same way that a UDP socket can receive messages from multiple clients. An association identifier is used to identify a single association on a one-to-many-style socket. This association identifier is a value of type sctp_assoc_t; it is normally an integer. It is an opaque value; an application should not use an association identifier that it has not previously been given by the kernel.
1.When the client closes the association, the server side will automatically close as well, thus removing any state for the association inside the kernel.
2.Using the one-to-many style is the only method that can be used to cause data to be piggybacked on the third or fourth packet of the four-way handshake (see Exercise 9.3(See 8.7.16)).
3.Any sendto, sendmsg, or sctp_sendmsg to an address for which an association does not yet exist will cause an active open to be attempted, thus creating (if successful) a new association with that address. This behavior occurs even if the application doing the send has called the listen function to request a passive open.
4.The user must use the sendto, sendmsg, or sctp_sendmsg functions, and may not use the send or write function. (If the sctp_peeloff function is used to create a one-to-one-style socket, send or write may be used on it.)
5.Anytime one of the send functions is called, the primary destination address that was chosen by the system at association initiation time (Section 2.8(See 7.2.8)) will be used unless the MSG_ADDR_OVER flag is set by the caller in a supplied sctp_sndrcvinfo structure. To supply this, the caller needs to use the sendmsg function with ancillary data, or the sctp_sendmsg function.
6.Association events (one of a number of SCTP notifications discussed in Section 9.14(See 8.7.14)) may be enabled, so if an application does not wish to receive these events, it should disable them explicitly using the SCTP_EVENTS socket option. By default, the only event that is enabled is the sctp_data_io_event, which provides ancillary data to the recvmsg and sctp_recvmsg call. This default setting applies to both the one-to-one and one-to-many style.