Stream Control Transmission Protocol (SCTP) Associations

 in
This second in a series of articles on the SCTP network protocol examines associations and connections.
Association ID

For the one-to-one socket we discussed in the first article in this series, there can be only one association at any time. For the one-to-many sockets we will cover in the next article, there can be many associations active at any one time—a peer can be connected to many other peers simultaneously. This is different from TCP where only one connection on a socket can exist and also is different from UDP where no connections exist and messages are just sent to arbitrary peers.

When there can be many associations, you need to be able to distinguish between them. This is done by an opaque data type called an association ID. You need to use this sometimes, but not every time. For one-to-one sockets, there is only one association, so the association ID is always ignored. For one-to-many sockets, when the association is “obvious”, the association ID again is ignored. This occurs, for example, when you write to a peer and give the peer's socket address; there can be only one association to a peer (but many associations to many peers), so if the peer is known, the association is known, and there is no need for the ID. But the association ID has to be used when the SCTP stack cannot work out for itself which association is meant. One place where this happens is in the getsockopt() call described previously to find the number of streams of an association on a one-to-many socket. I will defer the discussion of how to find the association ID to the next article, where I look at one-to-many sockets.

Writing to and Reading from a Stream

There are several ways of writing to a stream and telling to which stream a read belongs. Some of them make use of a structure of type sctp_sndrcvinfo:

struct sctp_sndrcvinfo { 
      uint16_t sinfo_stream; 
      uint16_t sinfo_ssn; 
      uint16_t sinfo_flags; 
      uint32_t sinfo_ppid; 
      uint32_t sinfo_context; 
      uint32_t sinfo_timetolive; 
      uint32_t sinfo_tsn; 
      uint32_t sinfo_cumtsn; 
      sctp_assoc_t sinfo_assoc_id; 
}

Most of the fields in this structure are not of interest to us at the moment. The interesting one is the first one, sinfo_stream. To write to a particular stream, zero out all fields and set this one; to read, zero out all fields again, do the read, and then examine this field. (As an aside, if the SCTP stack cannot work out which association is meant, the last field, sinfo_assoc_id, must be set.)

The function call to write a message is:

int sctp_send(int sd, 
              const void *msg, 
              size_t len, 
              const struct sctp_sndrcvinfo *sinfo, 
              int flags);

______________________

Webcast
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers

Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.

Learn More

Sponsored by AMD

White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions