Benoît Garbinato

System support for object groups

This paper draws several observations from our experiences in building support for object groups. These observations actually go beyond our experiences and may apply to many other developments of object based distributed systems.Our first experience aimed at building support for Smalltalk object replication using the Isis process group toolkit. It was quite easy to achieve group transparency but we were confronted with a strong mismatch between the rigidity of the process group model and the flexible nature of object interactions. Consequently, we decided to build our own object oriented protocol framework, specifically dedicated to support object groups (instead of using a process group toolkit). We built our framework in such a way that basic distributed protocols, such as failure detection and multicasts, are considered as first class entities, directly accessible to the programmers. To achieve flexible and dynamic protocol composition, we had to go beyond inheritance and objectify distributed algorithms.Our second experience consisted in building a CORBA service aimed at managing group of objects written on different languages and running on different platforms. This experience revealed a mismatch between the asynchrony of group protocols and the synchrony of standard CORBA interaction mechanisms, which limited the portability of our CORBA object group service. We restricted the impact of this mismatch by encapsulating asynchrony issues inside a specific messaging sub-service.We dissect the cost of object group transparency in our various implementations, and we point out the recurrent sources of overheads, namely message indirection, marshaling/unmarshaling and strong consistency.

Encapsulating Failure Detection: From Crash to Byzantine Failures

Separating different aspects of a program, and encapsulating them inside well defined modules, is considered a good engineering discipline. This discipline is particularly desirable in the development of distributed agreement algorithms which are known to be difficult and error prone. For such algorithms, one aspect that is important to encapsulate is failure detection. In fact, a complete encapsulation was proven to be feasible in the context of distributed systems with process crash failures, by using black-box failure detectors. This paper discusses the feasibility of a similar encapsulation in the context of Byzantine (also called arbitrary or malicious) failures. We argue that, in the Byzantine context, it is just impossible to achieve the level of encapsulation of the original crash failure detector model. However, we also argue that there is some room for an intermediate approach where algorithms that solve agreement problems, such as consensus and atomic broadcast, can still benefit from grey-box failure detectors that partially encapsulate Byzantine failure detection.

Implementation of the GARF replicated objects platform

This paper presents the design and implementation of the GARF system, an object-oriented platform that helps programming fault-tolerant distributed applications in a modular way. The originality of GARF is to separate a distributed object into several objects, the complexity of distribution and fault-tolerance being encapsulated in reusable classes. The use of those classes by the GARF system is based on a run-time mechanism of invocation redirection, where most other systems use inheritance, a compile-time mechanism. Our runtime, which supports the GARF object model, is written in Smalltalk. It is presented in detail, as well as the reusable classes that support fault-tolerance. Fault-tolerant objects are implemented using groups of replicated objects. Our Dependable Object Toolkit provides group management facilities at the object level. Object groups are built on top of the Isis toolkit, which provides group management facilities at the Unix process level. Our mapping of object groups on process groups and our interfacing of Smalltalk and Isis are detailed. Performance analysis and a first evaluation of our prototype are also presented.

Middleware for Network Eccentric and Mobile Applications

Middleware is a critical foundation needed to leverage the development of a wide range of mobile and ubiquitous applications. Intrinsic challenges when building such middleware require the combination of expertise from areas like distributed systems, networking, software engineering, and application development. This textbook provides a comprehensive introduction to the main fundamental problems, technologies, paradigms, and solutions of concern to developers of middleware for mobile environments. The contributions are grouped into four parts, on networking and programming issues, communication models, middleware issues, and application issues. Each chapter is structured as a self-contained tutorial, presenting an overview of a specific topic and the state-of-the-art solutions for the related problems. In addition, the book also includes an authoritative reference list. The material has been successfully used in several thematic training schools organized by the ESF MiNEMA (Middleware for Network Eccentric and Mobile Applications) program, and the books organization and presentation is ideal for an advanced course on middleware.

Flexible protocol composition in BAST

The paper presents BAST, an object-oriented library of reliable distributed protocols. The authors show how BAST can be used to build fault-tolerant distributed applications, and how new protocols can be added to it. They discuss some distributed protocol design issues and the way these issues are circumvented in BAST. They briefly describe their Smalltalk and Java implementations of BAST, together with some performance results.

Garf: a tool for programming reliable distributed applications

The authors discuss Garf object-oriented tool that supports the design and programming of reliable distributed applications. Garf lets developers program an application and then replicate its critical components over several machines. Using a built-in library of distributed abstractions, developers can choose a replication strategy for each component of the application.

Six-Shot Broadcast: A Context-Aware Algorithm for Efficient Message Diffusion in MANETs

In this paper, we introduce six-shot broadcast (6SB) , a new context-aware message diffusion algorithm that uses location information to fine-tune its broadcasting process. Message diffusion is indeed one of the core challenges brought up by distributed systems and has therefore largely been studied in the context of traditional network structures such as the Internet. With the emergence of mobile ad hoc networks (MANETs) , new broadcasting algorithm especially geared at these networks have been introduced. These algorithms must reach two conflicting objectives when broadcasting a message, namely reliability vs. efficiency. That is, they must maximize the number of nodes that deliver the message (reliability), while minimizing the number of nodes that forward the message (efficiency). In recent years as more and more mobile devices have become context-aware, several broadcasting algorithms have been introduced using contextual information, such as location, in order to increase reliability and efficiency. Along that line, we provide a in-depth performance evaluation of our 6SB algorithm, by comparing it to similar broadcasting algorithms also targeted at MANETs . Our results show that 6SB competes with the most efficient algorithms in high densities of nodes and offers increased reliability in low densities at a reasonable overhead.

From ad hoc networks to ad hoc applications

This paper presents the first result of an ongoing research on mobile peer-to-peer communication paradigm and on ad hoc networks. This result is threefold: (1) we propose a definition of ad hoc applications that is independent of the notion of ad hoc networks, (2) we advocate for the need of an adequate development framework for building ad hoc applications, (3) we introduce such a framework, which is independent of the underlying network technology but which relies on existing standards. To illustrate our approach, we also sketch how our framework can be used to build a real ad hoc application. Ad hoc network; Ad hoc application; Framework; Abstraction; Peer-to-Peer; Mobile; Collocation; Location-based; Java Phone. I. AD HOC NETWORKS AS BACKGROUND Several recent research projects aim at studying new generation mobile communication and information services, based on self-organisation (AODV [2], Terminodes [8], CarNet [15]). Such systems have become very topical lately, with the advent of the peer-to-peer communication paradigm and the emergence of ad hoc network technologies. Yet, many fundamental technical questions remain open, while real business applications still need to be rolled out. One specific domain where the peer-to-peer phenomenon had a major impact is the data and media interchange on the internet. It had especially an immense influence on the music industry, to the point to question its foundations and existence [6]. However, this wave does not seem to be limited to desktop computers connected on the internet. Mobile devices will presumably be the next target, as storage and computing capacities raise, power consumption diminishes, and mobile communication tends to generalize, altogether guaranteeing the minimal requirements for multimedia applications (Apeera’s [17] example shows this trend). In the context of mobile peer-to-peer communication, ad hoc networks are expected to play a key role in the future, although nobody knows which emerging technology will win and when it will be ready for prime time. It seems nevertheless reasonable to forecast that when this will happen, we will need adequate development frameworks to leverage such ad hoc networks and turn them into mobile peer-to-peer applications. A. A definition of ad hoc network According to Murphy & al. [16], an ad hoc network is “a transitory association of mobile nodes which do not depend upon any fixed support infrastructure. [...] Connection and disconnection is controlled by the distance among nodes and by willingness to collaborate in the formation of cohesive, albeit transitory community”. Distance among nodes. With ad hoc networks, no additional infrastructure is required besides the network nodes themselves. It is the distance among nodes, or rather their proximity, that defines the boundaries of the network. That is, the mere collocation of two or more mobile nodes within a certain perimeter defines a new network in an ad hoc manner. Now, if the nodes were not mobile, an ad hoc network would not be different from LAN (Local Area Network). So, it is also the mobility of nodes, causing variations in their distance, that gives such networks their ad hoc nature. The actual perimeter defining an ad hoc network really depends on the technology being used. Some ad hoc network solutions are limited to so-called PAN (Personal Area Network). The Bluetooth technology, for instance, allows only for the definition of a PAN (up to about 10 meters [12]). This is also the case of some proprietary solutions like Spotme by Shockfish [18] which is limited to approximately 30 meters. Willingness to collaborate. The collocation of several nodes within a certain distance is a necessary but not sufficient condition to form an ad hoc network. In addition, collocated nodes need to be willing to collaborate. By definition of ad hoc networks, this willingness is expressed at the network level: roughly speaking, the decision to collaborate or not is expressed by going online or offline.1 Transitory peer-to-peer communities. Intuitively, the above features of ad hoc networks characterize their some1. The way a node goes on-line or off-line then depends on the actual ad hoc network technology being used. how “here and now” nature. That is, at any point in time (now), the network is defined by all nodes that are both within a certain distance and online (here). As consequence, nodes tend to appear and disappear in an ad hoc network much more often than in other types of networks, leading to so-called transitory community. Interestingly, transitory community is also a common aspect of peer-to-peer applications. People can join and withdraw from the community at any time, making it an ever changing map. The absence of a network infrastructure besides the nodes themselves accentuates the peer-to-peer nature of ad hoc networks even more. Because of this absence, indeed, nodes must interact via network-level peerto-peer communication. B. What applications for ad hoc networks? As a first approximation, we could simply define ad hoc applications as pieces of software that run on ad hoc networks. We do not believe however that this definition adequately characterizes the essence of ad hoc applications. Defining a class of applications (ad hoc applications) by coupling it to one (but only one) possible implementation technology (ad hoc networks) reduces the generality and effectiveness of the definition. This is particularly true in such a changing arena as mobile network technology. Indeed, no widely adopted ad hoc network exists nowadays. However, many researchers [2, 8, 15] work on the subject in order to build what will probably be the next generation networks. As no general consensus about future ad hoc network technology seems to emerge, a wise approach is to abstract ourself from the network level as will be seen later in this paper. In the remainder of the paper, we thus propose a more general definition of ad hoc applications and we describe an application-level framework for building such applications. More precisely, we start by providing the business background that we consider in our research, following a typical top-down approach. Then, we define ad hoc applications without mentioning the underlying network technology, and we illustrate our definition with some examples. Finally, we provide an architecture overview of our framework solution and we compare it with some existing related work. II. TOWARDS AD HOC APPLICATIONS For this research, we are following a fairly classical topdown approach, starting with an analysis of the business aspects of ad hoc applications.2 The aim is to identify existing ad hoc applications in order to see the evolution of this sector in the actual mobile commerce (m-commerce, for short) world. This important part of the research is still ongoing and helps to draw a possible scenario in the case of a wide adoption of ad hoc networks [3]. At the same time, it provides useful and viable examples that will help to validate our working process. Some of those examples are discussed later in this paper, but as it is not the main goal of this paper, they are not further developed. They nevertheless constitute the business basis for the definition of ad hoc applications that follows. A. A definition of ad hoc application We define an ad hoc application as a self-organizing application composed of mobile and autonomous devices, interacting as peers and which relationships are made possible because of relative physical distance (collocation). In addition, this dynamic community defined by a geographical proximity needs to have a common (application-level) interest. More formally, three features must be present in an application for it to deserve the ad hoc label. Mobility. In order to be able to use the application everywhere, the user should not be limited by the range available. Thus, a PAN is not enough. The range limit is set by the business logic of the application. Peer-to-Peer. Direct communication between peers is mandatory. This means that the pieces of software forming an ad hoc application have to interact directly, without using a central server. As said earlier, the underlying physical infrastructure has no impact on the fulfillment of this aspect. Collocation. All logical interactions between applications have to result in a physical interaction between users. This is called collocation. It means that in order to be called an ad hoc application, the service has to be location-based. B. Abstracting the network level The above definition allows us to abstract the network completely, and focus on the application aspects. This way, there is a clear decoupling between the application and the network, and any type of network GSM, WLAN or ad hoc can be used. This decoupling is fundamental in understanding the key issues underlying ad hoc applications and in providing reusable solutions to solve these issues (in order to ease the development of ad hoc applications). By abstracting the network level, we are able to build ad hoc applications in absence of any ad hoc network, as long as the underlying infrastructure can provide support for the three basic aspects that we described earlier. C. Existing ad hoc applications Some possible applications have already been cited in the literature. For example, Kortuem discusses an ad hoc task trading system [13]. The idea is that two individuals use their 2. More precisely, we are following an iterative top-down approach, as proposed by the Unified Process [9]. mobile devices to negotiate about and to exchange real-world tasks: dropping off someone’s dry cleaning, buying a book of stamps at the post office, or returning a book to the local library. The idea is that you do a favor for others because you know that one day they will do it for you. Some mobile operators, like Swisscom with their FriendZone service [7], are also active in this domain. The FriendZone service for instance lets

Middleware Support for Context-Aware Applications

With computing devices becoming more mobile and pervasive, a stronger interaction between an application and its changing environment opens new horizons in terms of application functionalities. Location-based applications, such as GPS navigation systems, are good examples of how information provided to an application on its surroundings offers new kinds of functionalities. Location is one of many environmental variables that might influence the behavior of an application. The notion of context encompasses these variables in the broad sense.

Protocol Classes for Designing Reliable Distributed Environments

In this paper, we present Bast, an extensible library of protocol classes. The latter is aimed at helping system programmers to build distributed programming environments. Protocol classes constitute the basic structuring components for higher-level programming models, such as the transactional model, and add flexibility to distributed environments. We focus on classes that implement a generic agreement protocol named DTM (Dynamic-Terminating-Multicast). To the programmer, the DTM generic protocol appears as a set of classes that can be specialized to solve agreement problems in distributed systems. In particular, we show how those classes can be derived to build atomic commitment and reliable total order protocols. An overview of the Smalltalk design and implementation of the Bast library is also presented.