were initially provided and are the only way to access this functionality. At the moment this is the only protocol that has both the capacity and user demand for this feature, so the API has not been standardized across more than a few operating systems. The table here lists the APIs that SCTP added.

While this list of functions contains more APIs than are strictly necessary, it is important to note that many are derivatives of preexisting APIs, such as send(), which need to be extended to work in a multihoming world. The set of APIs needs to be harmonized to make multihoming a first-class citizen in the sockets world. The problem now is that sockets are so successful and ubiquitous that it is very hard to change the existing API set for fear of confusing its users or the preexisting programs that use it.

As systems come to have more network interfaces built in, the ability to write applications that take advantage of multihoming will be an absolute necessity. One can easily imagine the use of such technology in a smartphone, which already has three network interfaces: its primary connection via the cellular network, a WiFi interface, and often a Bluetooth interface as well. There is no reason for an application to lose connectivity if even one of these network interfaces is working properly. The problem for application designers is that they want their code to work, with few or no changes, across a plethora of devices, from cellphones, to laptops, to desktops, etc. With properly defined APIs we would remove the artificial barrier that prevents this. It is only because of the history of the sockets API and the fact that it has been “good enough” to date that this need has not yet been addressed.

High bandwidth, low latency, and multihoming are driving the development of alternatives to the sockets API. With LANs now reaching 10 Gbps, for many applications client/server-style communication is far too inefficient to use the available bandwidth. The communication paradigms supported by the sockets API must be expanded to allow for memory sharing across the kernel boundary, as well as for lower-latency mechanisms to deliver data to applications. Multihoming must become a

Explanation

Bind or unbind an SCTP socket to a list of addresses Connect an SCTP socket with multiple destination addresses

sctp_generic_recvmsg() Receive data from a peer sctp_generic_sendmsg(), Send data to a peer sctp_generic_sendmsg_iov() sctp_getaddrlen() Return the address length of an address family sctp_getassocid() Return an association ID for a specified socket address sctp_getpaddrs(), Return a list of addresses to the caller sctp_getladdrs() sctp_peeloff()

API sctp_bindx() sctp_connectx()

sctp_sendx() sctp_sendmsgx()

Detach an association from a one-to-many socket to a
separate file descriptor
Send a message from an SCTP socket
Send a message from an SCTP socket

first-class feature of the sockets API because devices with multiple active interfaces are becoming the norm for networked systems. Q

REFERENCES

1. Balaji, P., Bhagvat, S., Jin, H.-W., Panda, D.K. 2006.

Asynchronous zero-copy communication for synchronous sockets in the sockets direct protocol (sdp) over infiniband journal. Proceedings of the 20th IEEE International Parallel and Distributed Processing Symposium: 303.

2. Gilligan, R., Thomson, S., Bound, J., McCann, J., Stevens, W. 2003. Basic Socket Interface Extensions for IPv6. RFC 3493 (February); http://www.rfc-editor. org/rfc/rfc3493.txt.

3. Romanow, A., Mogul, J., Talpey, T., Bailey, S. 2005. Remote Direct Memory Access (RDMA) over IP Problem Statement. RFC 4297 (December); http://www.rfc- editor.org/rfc/rfc4297.txt.

4. Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarz-bauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., Paxson, V. 2000. Stream Control Transmission Protocol. RFC 2960 (October); http://www.ietf.org/rfc/rfc2960.txt.

 

LOVE IT, HATE IT? LET US KNOW feedback@queue.acm.org

GEORGE V. NEVILLE-NEIL ( gnn@acm.org) is a columnist for ACM Queue and Communications of the ACM, as well as a member of the Queue Editorial Board. He works on networking and operating-system code and teaches courses on various subjects related to programming. © 2009 ACM 1542-7730 /09/0200 $5.00