The Socket API, Part 5: SCTP

转：http://www.linuxforu.com/2011/12/socket-api-part-5-sctp/

By Pankaj Tanwar on December 29, 2011 in Coding, Developers · 11 Comments



This article on socket programming deals with the Stream Control Transmission Protocol (SCTP).
Similar to TCP and UDP, SCTP provides some features of both. It is message-oriented, and provides a reliable sequenced delivery of messages. SCTP supports multi-homing, i.e., multiple IPs on both sides of the connection. So it is called an association instead of a connection, as a connection involves communication between two IPs, while an association refers to communication between two systems that may have multiple IPs.

SCTP can provide multiple streams between connection endpoints, and each stream will have its own reliable sequenced delivery of messages, so any lost message will not block the delivery of messages in any of the other streams. SCTP is not vulnerable to SYN flooding, as it requires a 4-way handshake.
We will discuss the science later, and now jump to the code, as we usually do. But first you need to know the types of SCTP sockets:

A one-to-one socket that corresponds to exactly one SCTP association (similar to TCP).

A one-to-many socket, where many SCTP associations can be active on a socket simultaneously (similar to UDP receiving datagrams from several endpoints).

One-to-one sockets (also called TCP-style sockets) were developed to ease porting existing TCP applications to SCTP, so the difference between a server implemented using TCP and SCTP is not much. We just need to modify the call to

socket()

to

socket(AF_INET, SOCK_STREAM, and IPPROTO_SCTP)

while everything else stays the same — the calls to

listen()

,

accept()

for the server, and

connect()

for the client, with

read()

and

write()

calls for both.

Now let’s jump to the one-to-many or UDP-style socket, and write a server using multiple streams that the client follows.

First, here is the code for the server,

smtpserver.c

:

And here’s the code of the client,

sctpclient.c

:

The server is sending three messages on three different streams, and the client is just receiving the messages and printing them on the screen (see Figures 1 and 2).




Figure 1: Server output




Figure 2: Client output

The code is similar to the TCP client, as we are again making calls to the same functions [refer toParts 1, 2, 3 and 4 of this series.]. The difference is that we are creating an iterative server, similar to the one for UDP, but we have an

accept()

call here. The client does the reverse, and receives the messages coming from the server to the client. Now let’s try to understand the functions that we used:

We are using this function to send a message from a socket while using the advanced features of SCTP. The first argument to the function is

sd

, the socket descriptor, from which the message

msg

of length

len

is sent. The fourth argument is to give the destination address —

tolen

specifies the length of the destination address, while

stream_no

identifies the stream number to send this message to. The

flags

parameter is used to send some options to the receiver. You can check out the manual pages for

sctp_sendmsg()

.

The

timetolive

parameter is time in milliseconds after which the message will expire if not sent by then; the zero here indicates that no time-out is set. The context is the value passed to the upper layer along with the undelivered message, if an error occurs while sending the message. When successful, it will return the number of bytes sent, or -1 on error.

Next is the

stcp_recvmsg()

function:

This function does the reverse of the

sctp_sendmsg

function and is used to receive a message. The parameters are similar. The socket

sd

receives the

msg

of length

len

from the address

*from

with a length

*fromlen

, and

*sinfo

is a pointer to the address, which will be filled upon receipt of the message.

mag_flags

is a pointer to an integer with flags like

MSG_NOTIFICATION

or

MSG_EOR

. It returns the number of bytes received, or -1 on error.

This function is used to set the options for the socket

sockfd

. The next argument is the level at which the option resides. To manipulate options at the sockets API level, the level is specified as

SOL_SOCKET

.

optname

and any specified options are passed uninterpreted to the appropriate protocol module for interpretation. The

level

and

optname

are defined in

sys/sockets.h

. The arguments

optval

and

optlen

are used to access option values for

setsockopt()

that are stored in the structure. The options we set in the server are:

Here, the first two lines tell us that the output and input streams available are three, and the maximum attempts will be two. The same options are set in the client program. Other options are set for the events. This structure will be filled when an event like “message received” occurs, and our program is notified. Its counterpart function is

getsockopts()

(look up the man pages for help). The rest of the code is simple to understand.

Now compile and run the program; make sure you have installed

sctp-tools

so that you’ll have

sctp.h

at

netinet/

. To compile, use

gcc sctpserver.c -lsctp -o server && gcc sctpclient.c -lsctp -o client

; and to run, use the following code:

I’m wrapping up the series for now, but will keep adding more to the topic, on and off.