A New Network Abstraction for Mobile and Ubiquitous Computing Environments in the Plan B Operating System Francisco J. Ballesteros Eva M. Castro Gorka Guardiola Muzquiz Katia Leal Algara Pedro de las Heras Quir´ os Laboratorio de Sistemas — Universidad Rey Juan Carlos Madrid — Spain nemo,eva,paurea,kleal,pheras @lsub.org Abstract Today, there are several different communication inter- faces available and we plug/unplug them at will. How- ever, our network programming interfaces remain similar to those used when there was at most one network inter- face. As a result, applications must struggle with the problem of adapting to changes in network facilities: they must se- lect the appropriate network, switch to another when the current one fails, re-establish failed connections, and so on. Although there are systems and middleware that solve part of these problems, there is no integrated approach that ad- dresses the underlying problem: a new network program- ming interface is needed for applications that must run in mobile and ubiquitous computing environments. This paper presents the design, implementation, and experience with a novel network programming interface introduced in the Plan B’s Operating System and called /net. It also shows how this addresses the problems mentioned and simplifies network programming, including some example applica- tions. 1. Introduction Usually, we expect the operating system (or the middle- ware) to do both resource management and resource ab- straction on behalf of the application. However, in mobile and ubiquitous environments, the system underlying the ap- plication (be it an OS or middleware) does not has much support for network programming. Mobile devices usually have multiple communication means available (networks using TCP/IP over ethernet or 802.11, as well as serial, in- frared, and/or bluetooth connections). When an application wants to communicate with a remote program that is only reachable through some of the networks available, it must still know which network to use. Although we might eventually expect the system to take over that task, nowadays, the application has to do the sys- tem’s job. For example, the network used may be replaced by another, which might be using a different protocol fam- ily (note that it could be just an SMS facility!). In this case, it is the application that has to detect the communication problem, discover that a different network is available, and reroute its data messages through the new network. Once more, it is doing the work that the underlying system should be doing. The problem is that the network APIs we use were designed when it was not common to have multiple net- works available, and it was even less common to consider that they might become enabled and disabled during the ap- plication’s execution. For example, a program sending a print request cares about the destination printer service used, not about which network is used to reach the printer. Similarly, a remote ex- ecution facility wants just to send commands to the appro- priate machine, an editor cares about reaching a file service to save or load a file, a web navigator cares about reaching a server, and the list goes on. This does not mean that a pro- gram should not be able to specify which network to use; it means just that the program should not have to. The ap- plication might require the network to have certain proper- ties like a reliable transport, high bandwidth, or the like. But note that needing a network with a particular property is not the same as needing a particular network. In this paper we introduce a novel network abstraction, called /net, that allows applications to specify endpoints in the network(s), without specifying which network should be used each time communication happens. Our API also al- lows networks to be selected based on their properties, mak- ing it easier for applications that care about which trans- port is used. Our system relies heavily on the traditional file abstraction, per-application name spaces, and the use of (volatile) late binding. By doing so, we permit the sys- tem to switch from one network to another depending on their availability, without placing the burden on the appli-