Stream Control Transmission Protocol (SCTP) Associations
An SCTP association is a generalisation of a TCP connection. Usually a TCP connection is one-to-one between two network interfaces, one on a server and the other on a client. In contrast, an SCTP association is many-to-many in two ways:
Multiple network interfaces on a server can be associated with multiple interfaces on a client. For example, suppose the server and client both have an Ethernet card and a Wi-Fi card connected to the Internet. Then, data can flow over a single association in up to four possible ways: Ethernet to Ethernet, Ethernet to Wi-Fi, Wi-Fi to Ethernet or Wi-Fi to Wi-Fi.
An association also can carry multiple logical streams. These are numbered from zero upward. So, for example, stream zero could carry control instructions, while stream one could carry small pieces of data (such as small files), and stream two could carry larger pieces of data (such as an MPEG movie). The three streams are logically independent, so that delays on one stream do not cause delays on any other stream.
Note that a single socket can have multiple associations—that is, one socket can be used to talk to multiple other hosts. In general, these different associations are distinguished by having an association ID. The socket API for SCTP distinguishes between situations where exactly one association can exist (a one-to-one socket) or where a socket can manage many associations (a one-to-many socket). The first case corresponds to the TCP-like case that I discussed in the first article on SCTP [LJ, September 2007]. The second case will be covered in the next article. In this article, I look only at a single association, which is applicable to both the one-to-one and the one-to-many sockets.
TCP and UDP use a single network interface on an endpoint, by specifying its IP address in a socketaddr structure. If you specify the wildcard address INADDR_ANY, a server will listen on all interfaces while a client will choose only one. In any case, communication takes place only between a single interface on each endpoint. As an aside, if you want to know what all the interfaces on your machine are, use the call ioctl() with parameter SIOCGIFCONF. How to do this is described in WR Stevens et al., Unix Network Programming, vol 1, section 17.5.
Using only one interface reduces reliability when more than one is available. A network cable may have poor connections, or you may be too far from a wireless access point for a reliable signal. On the other hand, using all of the interfaces may not always be desirable. For example, in Australia, the download charges for 3-G or WiMAX connections are ridiculously expensive, so you would use that interface only if no others were available. Or, a bridge would expose the internal and external interfaces separately to different groups of users.
SCTP allows an application to choose a subset of interfaces on either the source or destination side of an association. Some implementations also will allow interfaces to be added or removed dynamically, so the application can adjust to different states of the network connections. By registering for association-change events (which will be discussed in the next article), one endpoint can track changes in the interfaces at the other end.
The normal socket call bind() just takes a single sockaddr parameter to bind the socket to a single IP address (or to the wildcard address). SCTP extends this by introducing a new call, sctp_bindx(), which takes an array of sockaddrs to bind the socket to all of these addresses. The socket is bound only to a single port though; all of the port numbers in the array of sockaddrs must have the same port number. And, if addresses are added or removed later, they must have the same bound port value. Otherwise, the call fails.
There is another wrinkle to sctp_bindx() regarding IPv4 and IPv6 addresses. The socket can be passed a set of only IPv4 sockaddrs, a set of only IPv6 sockaddrs or a mixture of both. The two types of socket address structures, sockaddr_in and sockaddr_in6, have different sizes, so mixing these in the same array can cause alignment issues. SCTP packs the structures together with no wasted space between them. So, you can't just use an index into the array, you have to copy the right number of bytes for each structure and then move up by that amount.
The call to bind a set of addresses is:
int sctp_bindx(int sd, struct sockaddr *addrs, ↪int addrcount, int flags)
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide