Multiple Associations with Stream Control Transmission Protocol

In two previous articles [in the September and October 2007 issues of LJ], I looked at the basics of SCTP, how you can use SCTP as a replacement for TCP and how you can use SCTP to process multiple streams within a single association. In this final article, I look at how a single endpoint deals with multiple associations (connections to other endpoints). First though, I explain how SCTP can give extra information about what is going on through events.

The SCTP stack can generate events when “interesting” things happen. By default, all event generation is turned off except for data events. In the last article, I discussed the SCTP call sctp_rcvmsg(). By default, this just returns the data read. But, I also wanted to find out on which stream the data came, and for this I had to turn on the data_io_event so the SCTP stack would fill in the sctp_sndrcvinfo structure, which has the sinfo_stream field. Events are listed in the sctp_event_subscribe structure:

struct sctp_event_subscribe { 
    uint8_t sctp_data_io_event; 
    uint8_t sctp_association_event; 
    uint8_t sctp_address_event; 
    uint8_t sctp_send_failure_event; 
    uint8_t sctp_peer_error_event; 
    uint8_t sctp_shutdown_event; 
    uint8_t sctp_partial_delivery_event; 
    uint8_t sctp_adaptation_layer_event; 
    uint8_t sctp_authentication_event; 
};

An application sets fields to one for events it is interested in and zero for the others. It then makes a call to setsockopt() with SCTP_EVENTS. For example:

memset(&event, 0, sizeof(event)); 
event.sctp_data_io_event = 1; 
event.sctp_association_event = 1; 
setsockopt(fd, IPPROTO_SCTP, SCTP_EVENTS, 
           &event, sizeof(event));

Events are delivered inline along with “ordinary” data whenever a read (using sctp_recvmsg or similar) is done. If the application turns on events, reads will contain a mixture of events and data. The application then will need to examine each read to see whether it is an event or data to be processed. This is quite straightforward. If the flags field in the sctp_recvmsg() call has the MSG_NOTIFICATION bit set, the read message contains an event; otherwise, it contains data as before. Pseudo-code for this is:

nread = sctp_rcvmsg(..., msg, ..., &flags); 
if (flags & MSG_NOTIFICATION) 
    handle_event(msg); 
else 
    handle_data(msg, nread);

Events can be used to tell the following: if a new association has started or if an old one has terminated; if a peer has changed state by, say, one of the interfaces becoming unavailable or a new interface becoming available; if a send has failed, a remote error has occurred or a remote peer has shut down; if partial delivery has failed; and if authentication information is available.

If an event is received in the event buffer, first its type must be found, and then the buffer can be cast to a suitable type for that event. For example, the code to handle a shutdown event is:

void handle_event(void *buf) { 
    union sctp_notification *notification; 
    struct sn_header *head; 

    notification = buf; 
    switch(notification->sn_header.sn_type) { 
    case SCTP_SHUTDOWN_EVENT: { 
        struct sctp_shutdown_event *shut; 
        shut = (struct sctp_shutdown_event *) buf; 
        printf("Shutdown on assoc id %d\n", 
                shut->sse_assoc_id); 
        break; 
    }
    default: 
        printf("Unhandled event type %d\n", 
               notification->sn_header.sn_type);
    }
}

A socket can support multiple associations. If you close a socket, it closes all of the associations! It is sometimes desirable to close only a single association but not the socket, so that the socket can continue to be used for the other associations.

SCTP can abort an association or close it gracefully. Graceful shutdown will ensure that any queued messages are delivered properly before shutdown, while abort does not do this. Either of these are signaled by setting the sinfo_flags in the sctp_sndrcvinfo structure to the appropriate value. A graceful shutdown is signaled by setting the shutdown flag and writing a message (with no data):

sinfo.sinfo_flags = SCTP_EOF; sctp_send(..., &sinfo, ...);

The reader then will be sent an sctp_shutdown_event if it has that event type enabled. The code to handle such an event was shown above. This can be done only on one-to-many sockets though. For one-to-one sockets, you are limited to using close().