Home ›

Stream Control Transmission Protocol (SCTP) Associations

Issue 162

From Issue #162
October 2007

Oct 01, 2007  By Jan Newmarch
 in
This second in a series of articles on the SCTP network protocol examines associations and connections.

Listing 3. streamcount_echo_server.c


#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>

#include <netinet/sctp.h>

#define ECHO_PORT 2013

char *usage_msg = "usage: streamcount_echo_server istreams ostreams";

void usage() {
        fprintf(stderr, "%s\n", usage_msg);
        exit(1);
}


int main(int argc, char *argv[]) {
        int sockfd, client_sockfd;
        int len;
        struct sockaddr_in serv_addr, client_addr;
        int port = ECHO_PORT;
        struct sctp_initmsg initmsg;
        struct sctp_status status;

        if (argc != 3) usage();

        /* create endpoint */
        sockfd = socket(AF_INET, SOCK_STREAM,
                        IPPROTO_SCTP
                );
        if (sockfd < 0) {
                perror("socket");
                exit(2);
        }

        serv_addr.sin_family = AF_INET;
        serv_addr.sin_addr.s_addr = INADDR_ANY;
        serv_addr.sin_port = htons(port);

        if (bind(sockfd, (struct sockaddr *) &serv_addr,
                 sizeof(serv_addr)) == -1) {
                perror("sctp bind");
                exit(2);
        }


        memset(&initmsg, 0, sizeof(initmsg));
        initmsg.sinit_max_instreams = atoi(argv[1]);
        initmsg.sinit_num_ostreams = atoi(argv[2]);
        printf("Asking for: input streams: %d, output streams: %d\n",
               initmsg.sinit_max_instreams,
               initmsg.sinit_num_ostreams);

        if (setsockopt(sockfd, IPPROTO_SCTP,
                       SCTP_INITMSG, &initmsg, sizeof(initmsg))) {
                perror("set sock opt\n");
        }

        /* specify queue */
        listen(sockfd, 5);
        for (;;) {
                len = sizeof(client_addr);
                client_sockfd = accept(sockfd, (struct sockaddr *)
&client_addr, &len);
                if (client_sockfd == -1) {
                        perror(NULL); continue;
                }

                memset(&status, 0, sizeof(status));
                len = sizeof(status);
                if (getsockopt(client_sockfd, IPPROTO_SCTP,
                               SCTP_STATUS, &status, &len) == -1) {
                        perror("get sock opt");
                }
                printf("Got: input streams: %d, output streams: %d\n",
                       status.sstat_instrms,
                       status.sstat_outstrms);

                /* give the client time to do something */
                sleep(2);
                close(client_sockfd);

        }
}
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);

______________________

White Paper
More Resources
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.

Learn More

Sponsored by AMD

White Paper
More Resources
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