which interfaces or connections mattered to it. Such features, when they
were implemented, were a part of the
routing software within the operating
system. The only way programs could
get access to them was through an obscure set of nonstandard kernel APIs
called a routing socket.
On a system with multiple network
interfaces it is not possible, using the
standard sockets API, to write an application that can easily be multihomed—
that is, take advantage of both interfaces so if one fails, or if the primary
route over which the packets were flowing breaks, the application would not
lose its connection to the server.
The recently developed Stream Control Transport Protocol (SCTP) 4 incorporates support for multihoming at the
protocol level, but it is impossible to
export this support through the sockets API. Several ad-hoc system calls
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. Table 2 shows the
APIs that SCTP added.
While the list of functions in Table
2 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, providing 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
as systems come
to have more
network interfaces
built in, providing
the ability to write
applications that
take advantage
of multihoming
will be an absolute
necessity.
to work, with few or no changes, across
a plethora of devices, from cellphones,
to laptops, to desktops, and so on. 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 10Gbps,
it is obvious that 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 first-class feature of the sockets API
because devices with multiple active
interfaces are now becoming the norm
for networked systems.
Related articles
on queue.acm.org
Code Spelunking: Exploring
Cavernous Code Bases
George Neville-Neil
http://queue.acm.org/detail.cfm?id=945136
API Design Matters
Michi Henning
http://queue.acm.org/detail.cfm?id=1255422
You Don’t Know Jack
about Network Performance
Kevin Fall and Steve McCanne
http://queue.acm.org/detail.cfm?id=1066069
References
1. balaji, P., bhagvat, s., Jin, h.-W., and Panda, D.k.
asynchronous zero-copy communication for
synchronous sockets in the sockets direct protocol
(sdp) over infiniband journal. in Proceedings of the
20th IEEE International Parallel and Distributed
Processing Symposium.
2. gilligan, r., thomson, s., bound, J., mccann, J., and
stevens, W. basic socket interface extensions for
iPv6. rfc 3493 (feb. 2003); http://www.rfc-editor.
org/rfc/rfc3493.txt.
3. romanow, a., mogul, J., talpey, t., and bailey, s.
remote Direct memory access (rDma) over iP
Problem statement. rfc 4297 (Dec. 2005); http://
www.rfc-editor.org/rfc/rfc4297.txt.
44. stewart, r., et al. stream control transmission
Protocol. rfc 2960 (oct. 2000); http://www.ietf.org/
rfc/rfc2960.txt.
George V. Neville-Neil ( kv@acm.org) is the proprietor
of neville-neil consulting. he works on networking and
operating systems code and teaches courses on program-related topics.
© 2009 acm 0001-0782/09/0600 $10.00