Overview

The continual shrinking of devices has led to the expectation that users should be able to carry their handheld devices between two, possibly disconnected spaces and have the system provide personalized ubiquitous access to system resources in the context of the user. A key problem in such environments is adaptively finding and connecting to available resources in changing environments. Traditional systems burden the each application with the chore of re-discovering and re-connecting services while content-based routing systems burden the underlying network.

Instead, we propose Service-Oriented Network Sockets (SoNS) interposed at the session binding layer at each end host. Service-oriented network sockets take a high-level description of a service and opportunistically connect to the best provider of that service in the context of the device. An application states its high-level service requirements as a set of constraints on the properties required in a suitable resource. In turn, the system continuously monitors, evaluates, and compares the available resources. It connects and potentially (re-)connects to the resource that best satisfies the specified constraints.

Unlike content-based routing systems, service-oriented network sockets offer connection-oriented semantics. Additionally, the Service-oriented network interface allows an application to tailor the planning policy used to establish and rebind a network session. In summary, service-oriented network sockets integrate a service-oriented abstraction with the traditional operating system interface for accessing network services, making it simpler to develop pervasive, mobile applications.

Approach

SoNS is designed as an extension of the operating system socket interface. As such, it implements all the methods and options of a traditional AF_INET Unix socket, with additional options for establishing service-oriented network connections. A service-oriented network socket extends a traditional network socket in the following ways:

1. The call to create an operating system socket accepts an additional domain, AF_SONS, for creating a service-oriented network socket. AF_SONS extends an AF_INET socket and allows an application to choose between (SOCK_STREAM) and UDP (SOCK_DGRAM) as the transport protocol for a service-oriented session, including support for the various socket options associated with these transport protocols, e.g. TCP_NO_DELAY for TCP.
2. The connect method of a service-oriented network socket takes a high-level service description, instead of a network address, to establish a service-oriented network session. The service description is expressed as a set of constraints on the properties of an acceptable resource. In contrast to resource discovery systems that find a resource by performing an exact pattern-match on its attribute-value pairs, SoNS's constraint language offers the flexibility to evaluate and compare the alternatives available in a given context in order to find the closest match to the requirements of an application.
3. A service-oriented network socket can be configured with four additional options as arguments to setsockopt—context, agility, hysteresis and application callback—to tailor the session rebinding semantics according to application requirements.

By handling the dynamism of the system at an end-node, SoNS does not require any changes to the network routing infrastructure. Therefore, as opposed to systems that employ application-level content-based routing to address the dynamism of the system, SoNS's architecture does not introduce extra routing complexity in the participating nodes, achieves better performance, and leverages the underlying network support for quality-of-service.

Extending SoNS: LANS

The end-to-end nature of SoNS has two disadvantages. The first of these is that each end host must host all of SoNS and its overhead. SoNS's continual network probing strains batteries on mobile hosts while parsing returned results often slows computationally weak handhelds. The second is that SoNS acts greedily in its resource management; in the presence of many SoNS clients resources get allocated sub-optimally.

To mediate both of these problems, we extend SoNS to create Lightweight Adaptive Network Sockets (LANS). LANS improves on SoNS in several ways:

1. LANS introduces a replicated server framework to which clients can offload adaptive discovery while at the same time maintaining the SoNS's session-oriented semantics and robustness.
2. LANS offers more resource selection options.
3. Finally, LANS provides greater application control over the opportunism of the system.

To summarize, LANS offers the same interface as SoNS, but with increased efficiency and application control. For example, the figure below shows the power savings of a video application using LANS and SoNS in two different configurations on an iPAQ—using the iPAQ's local screen and adaptively offloading the video to a nearby network screen. LANS cuts power consumption drastically.