Abdulkader Benchi

Frédéric Guidec

Pascale Launay

A Message Service for Opportunistic Computing in Disconnected MANETs

Keywords: Java Message Service, JMS provider, Message Oriented Middleware, disconnected MANET, JNDI

Disconnected mobile ad hoc networks (or D-MANETs) are partially or intermittently connected wireless networks in which instant end-to-end connectivity between any pair of mobile hosts is never guaranteed. Recent advances in delay/disruption-tolerant networking make it possible to support communication in such conditions, but designing and implementing distributed applications for D-MANETs is still a challenging task. Middleware systems such as the Java Message Service (JMS) have made application development easy and cost-eective in traditional wired networks. In this paper, we introduce JOMS (Java Opportunistic Message Service), a JMS provider specically designed for D-MANETs, and with which pre-existing or new JMS-based applications can be easily deployed in such networks.

Introduction

Mobile ad hoc networks (MANETs) have justied a fair amount of research activity during the last two decades. A MANET is a wireless network that requires no xed infrastructure. Each mobile host can communicate with its neighbors using direct pair-wise wireless links. Because the range of wireless transmissions is often quite short, many protocols (such as OLSR, AODV, DYMO, DSR...) have been designed over the years in order to support multi-hop forwarding in MANETs.

Yet most of these protocols rely on the assumption that the whole network remains continuously connected, so that whenever one mobile host must send a message to another host, there actually exists at least one end-to-end path between these hosts in the network. Unfortunately this assumption does not hold in many real MANETs that are, at best, only partially or intermittently connected. A MANET can for example become disconnected when the mobile hosts that compose this network are sparsely or irregularly distributed, as shown in Fig. 1. The whole network then appears as a collection of distinct, continuously changing islands or connected components rather than as a single, connected network. Communication between hosts that belong to the same island is possible using multi-hop forwarding if needed but no instant communication is possible between hosts that reside on dierent islands. In such conditions, a method must be devised in order to bridge the gap between non-connected parts of the network. The mobility of hosts can here be considered as an advantage, as it makes it possible for messages to propagate network-wide, using mobile hosts as carriers or data mules that can move between non-connected parts of the network. A message can thus be stored temporarily on a host while this host is moving in the network, and be forwarded later to another host when circumstances permit. In Fig. 1, a smartphone or laptop carried by a user moving (deliberately or by chance) from island 1 to island 2 can serve as a data mule for messages addressed to hosts located in island 2. This store, carry, and forward approach ts in the general category of disruption-tolerant or delaytolerant networking (DTN [START_REF] Fall | A Delay-Tolerant Network Architecture for Challenged Internets[END_REF]): connectivity disruptions are indeed tolerated thanks to the mobility of hosts, but this approach generally yields long transmission delays because transporting a message from source to destination can take a long time when one or several data mules are involved during the transport. The term opportunistic networking is often used in the literature to denote delay/disruption-tolerant networking when radio contacts between mobile hosts are not planned in advance and must thus be exploited opportunistically. This is typically the case in many kinds of disconnected MANETs (or D-MANETs), where the mobility pattern of each host is actually that of its physical carrier. If the physical carriers in a D-MANET are vehicles or robots with pre-dened travel plans, then radio contacts between the hosts they carry can be predicted accurately, and routing strategies can be devised based on contact predictions. But if the physical carriers are for example human beings carrying laptops or smartphones, or animals carrying sensors, then radio contacts cannot always be predicted, although each contact is still an opportunity for two hosts to exchange messages.

Many papers published in the last few years address the problem of supporting communication in D-MANETs (good surveys can notably be found in [START_REF] Pelusi | Opportunistic Networking: Data Forwarding in Disconnected Mobile Ad Hoc Networks[END_REF] and [START_REF] Zhang | Routing in Intermittently Connected Mobile Ad Hoc Networks and Delay Tolerant Networks: Overview and Challenges[END_REF]). In any case, it should be noticed that communication protocols for D-MANETs usually provide no more than best-eort delivery: they cannot guarantee that a message will be delivered. This is a consequence of the disconnected nature of the networks considered. Consider again the example shown in Fig. 1, and assume a message is addressed by a host in island 1 to a host in island 5 (or to all hosts in the network, including those in island 5). If no human carrier ever visits island 5, then there is no chance that the message ever gets delivered in this island. A communication protocol running in a D-MANET can do no magic if mobile hosts do not move in such a way that messages can be transported between non-connected fragments of the network.

A D-MANET is therefore a network in which transmission delays can be very long, and transmissions can even fail altogether. Designing and implementing distributed applications capable of running in such conditions is quite a challenge. The peer-to-peer model should generally be preferred over the clientserver model, because in many real D-MANETs no host can be considered as stable and accessible enough to play the role of a server for all other hosts. Additionally, any distributed application running in a D-MANET must obviously be able to tolerate long transmission delays, and occasional transmission failures as well.

The concept of middleware has long proved ecient in easing the development of distributed applications for traditional wired networks. It can be expected that carefully designed middleware systems might bring similar benets for D-MANETs. According to Hurwitz there are four types of middleware, which are transactional, procedural, message-oriented and object-oriented middleware [START_REF] Hurwitz | Sorting Out Middleware[END_REF].

Message-oriented middleware appears to be the most appropriate model for D-MANETs because it generally relies on asynchronous message-passing, which ts perfectly with the long transmission delays that can be observed in such networks.

In the remainder of this paper we present JOMS (Java Opportunistic Message Service), a message-oriented middleware system we designed and implemented specically for D-MANETs. JOMS is actually a provider for the standard Java Message Service (JMS), so any pre-existing distributed application using the JMS API can be executed in a D-MANET with little or no further development.

New applications can also be developed easily, taking benet from the server-less directory service along with the administration tools provided with JOMS. This paper is structured in the following way. An overview of the JMS specication is provided in Section 2. Section 3 presents the general architecture and principles of our system JOMS, whose implementation is then evaluated in Section 4. Related work is later discussed in Section 5. Section 6 concludes this paper, and describes our plans for future work.

Java Message Service (JMS)

The Java Message Service (JMS) is a Message-oriented Middleware (MoM) standard that allows application components based on the Java 2 Platform Enterprise Edition (J2EE) to create, send, receive, and read messages. As a MoM standard, it supports distributed communication in a loosely-coupled, reliable, and asynchronous manner [START_REF] Hapner | Java Message Service[END_REF]. A client sends (produce s) a message to another client, which can then try to retrieve (consume ) it asynchronously. The producer and the con-sumer do not have to be available at the same time in order to communicate. In fact, the producer does not need to know anything about the consumer, nor does the consumer need to know anything about the producer. This brings a major benet to MoM, where the producer and the consumer need to know only what message format and what channel to use in order to communicate.

JMS API overview

The JMS API denes a common set of interfaces including the associated semantics that allows programs written in Java to communicate. The JMS specication does not dene how messages are transported within a particular implementation, known as a JMS provider. Because of the lack of unied implementation, each major vendor proposes its own JMS provider along with the associated management tools. Each JMS provider supplies the user with an appropriate transport technology for a particular deployment environment.

The JMS API denes two communication models: point-to-point and publishsubscribe. The point-to-point model is built around the concept of queues. A queue sender sends a message to a specic queue, from which a queue receiver can receive it asynchronously. This model provides a one-to-one communication model. In other words, a given queue may have multiple senders and multiple receivers, but each message sent by a sender to this queue is consumed by one receiver. This means that some mechanism is required to decide which receiver candidate will be the actual receiver of a given message.

The publish-subscribe model is based on the use of topics that can be subscribed to by topic subscribers. Messages are published to a topic by topic publishers and are then received in an asynchronous mode by all the corresponding topic subscribers. Each message may thus be consumed by multiple subscribers. This model complements the point-to-point model in that it provides a one-tomany communication model.

JMS supports two delivery semantics, through the so-called persistent and non-persistent delivery modes. A non-persistent message should be delivered in a best-eort mode. Conversely, a persistent message must be delivered in a guaranteed mode.

Java Naming and Directory Interface (JNDI)

According to the JMS specication, applications learn about the available topics and queues or so-called destination objects through the Java Naming and Directory Interface (JNDI). JNDI is a Java API that provides a common interface to access various naming and directory services [START_REF] Lee | JNDI API Tutorial and Reference: Building Directory-Enabled Java Applications[END_REF]. It is independent from the underlying directory services, which could be implemented using a server, a plain le, or a database. According to the JNDI specication, any directory service must provide a hierarchical structure, referred to as a namespace. JNDI uses this namespace in order to map any name to the corresponding object. Applications can thus discover names and lookup any data or object via its name. In traditional server-based JNDI implementations, a client creates a destination object via some administration tool and binds it to a central JNDI server. This object then resides there until it is unbound. From then on, applications typically use JNDI to lookup the destination objects they require.

3 Java Opportunistic Message Service (JOMS) JMS was primarily designed for systems where clients connect to central servers via traditional networks and this has remained its typical usage scenario. In most implementations of JMS, message producers send messages to a server that stores these messages and forwards (delivers) them later to the consumers. Furthermore, a server is responsible to provide a directory service that allows JMS clients to discover queues and topics. As explained in Section 1 a server-based model is hardly compatible with the characteristics of D-MANETs. No host can act as a reliable server for all other hosts. A server-less JMS implementation must thus be developed in order to provide JMS services in D-MANETs.

JOMS, or Java Opportunistic Message Service, is a JMS provider that was designed along that line. Its architecture is composed of three basic modules: a communication middleware system, a directory service, and the JMS provider per se.

Communication layer

Building any application for D-MANETs requires some communication middleware system with which mobile hosts can collaborate in a peer-to-peer manner to ensure message transportation. JOMS relies on a communication middleware system called DoDWAN (Document Dissemination in mobile Wireless Ad hoc Networks). This system was designed in our laboratory in order to support content-based information dissemination in D-MANETs [START_REF] Haillot | A Protocol for Content-Based Communication in Disconnected Mobile Ad Hoc Networks[END_REF].

Messages in DoDWAN are composed of two parts: a descriptor and a payload. The payload is simply perceived as a byte array. The descriptor is a collection of attributes expressed as (name, value) tuples, as illustrated in Fig. 2a. These attributes can be dened freely by the developers of application services built on top on DoDWAN. The only exceptions to this rule are a message identier and a deadline, that must systematically appear in any descriptor. The identier must be unique, for it allows DoDWAN to dierentiate messages while detecting duplicate copies of the same message. The deadline is meant to specify how long a message should be allowed to disseminate in the network, and therefore how long copies of this message should be stored by mobile hosts in their local cache.

DoDWAN provides application services with a publish/subscribe API. When a message is published by a local application service, it is simply put in the local cache maintained by DoDWAN. Afterwards each radio contact with another host will be an opportunity for DoDWAN to transfer a copy of the message to that host. In order to receive messages an application service must subscribe with DoDWAN and provide a selection pattern that characterizes the kind of messages it would like to receive. A selection pattern is expressed just like a The selection patterns specied by all local application services running on the same host dene this host's interest prole. DoDWAN uses this prole to determine which messages should be exchanged whenever a radio contact is established between two hosts. The interaction scheme implemented in DoDWAN denes a selective version of the epidemic routing model proposed in [START_REF] Vahdat | Epidemic Routing for Partially Connected Ad Hoc Networks[END_REF]. Details about this interaction schema and about how it performs in real conditions can be found in [START_REF] Haillot | A Protocol for Content-Based Communication in Disconnected Mobile Ad Hoc Networks[END_REF].

As a general rule, a host that subscribes to receive a particular kind of message is expected to serve as a mobile carrier for this kind of message. Yet a host can also be congured so as to serve as an altruistic carrier for messages that present no interest to the application services it runs locally. This behavior is optional, though, and it must be enabled explicitly by an administrator of the DoDWAN platform.

Mobile hosts running DoDWAN only interact by exchanging control and data messages encapsulated in UDP datagrams, which can themselves be transported either in IPv4 or IPv6 packets. Large messages are additionally segmented so that each fragment can t in a single UDP datagram. Fragments of a large message can propagate independently in the network and be reassembled only on destination hosts.

Directory service (JNDI)

JOMS supports a distributed directory service, which implements a subset of the API of the standard JNDI, while preserving the semantics [START_REF] Lee | JNDI API Tutorial and Reference: Building Directory-Enabled Java Applications[END_REF].

In JOMS, each host maintains a local directory that acts as a local namespace from which application services can lookup/retrieve destination objects. When a destination object is created, an entry for this destination object is added to the local namespace. Each entry in this namespace is characterized by a name, a type and a deadline.

Ensuring name unicity in a server-based conguration over traditionnal (connected) networking environments does not raise any major issue. In D-MANETs, no consensus between hosts can be reached [START_REF] Fischer | Impossibility of Distributed Consensus with One Faulty Process[END_REF], and ensuring name unicity in such conditions is not a trivial task. In JOMS, when topics with the same name are added to dierent local namespaces, they are considered as referring to the same topic. It is up to the applications to manage topic creations while avoiding name ambiguities. For queues, it is important to make each name unique. A queue's name in JOMS therefore has the form queue_name@host_name. Thus, since DoDWAN ensures that each host is assigned a unique name, then using this form helps to dierentiate queues that have been created on dierent hosts.

The destination object's type can be topic or queue. This property has been added since the two modes of communication are managed by JOMS quite differently. Finally, the deadline represents the expiration date of the entry. An example of a destination object's entry is shown in Fig. 2d. This destination object describes a topic with name ChatRoom1 and deadline Sat Feb 11 19:27:32 CET 2012.

Once an object has been added in a host's local namespace, JNDI advertises this object using the underlying communication middleware. The hosts that receive an advertisement message that pertain to new destination objects (that is, destination objects that are not already available in their own namespaces) add these objects to their local namespace.

It is worth mentioning that in D-MANETs a strong consistency between several host's namespaces cannot be guaranteed since there is no central server.

In practice, there is no way to unbind a destination object network-wide. For this reason, JOMS uses the deadline property introduced in each JNDI entry in order to delete obsolete destination objects. In addition, JOMS implements a refreshing mechanism: whenever a message is sent/received to/from a specied destination object, the lifetime of this destination object is automatically extended in the local namespace. Thus, if an entry is not refreshed for a long time, this entry is considered as obsolete and is automatically deleted from the local namespace. This mechanism prevents a host from advertising an out-of-date destination object and ensures that each host holds an up-to-date namespace.

JMS provider

A JMS provider supports the publish-subscribe and the point-to-point styles of messaging. This Section describes the message model of JOMS and the way it supports the two models of communication.

Message model according to the JMS specication [START_REF] Hapner | Java Message Service[END_REF], a JMS message has three parts: a header, properties, and a body. The JMS message header contains elds used by both clients and providers to control messages. The properties are extra header elds that act as a set of rules describing the message content. They are used by clients to lter messages via message selectors. It is worth noting that selection criteria cannot reference the message body, that carries the message content.

A DoDWAN message has two parts: a descriptor and a payload. Since JOMS is based on DoDWAN, it adopts this message model by mapping the JMS message's elds to the DoDWAN message. An example of a JOMS message is shown in Fig. 2a. The JMS message's body is carried in a DoDWAN message as its payload, and considered as a simple byte array. The message descriptor is used by DoDWAN to manage the message dissemination and delivery. The JMS message's header and properties are mapped to the DoDWAN message's descriptor, as their content is needed by JOMS to process the messages delivery. MessageID and Destination are standard JMS header elds; they are used by JOMS to route the message to its recipients having these criteria in their interest prole. We will explain later how these proles are dened in JOMS to allow publishsubscribe and point-to-point communications. As those communication styles are quite dierent and implemented in JOMS using distinct models, an extra property, the destination type, is added to the JMS initial message. The JMS Expiration eld is mapped to the DoDWAN message and called deadline. This eld, optional according to the JMS specication, is mandatory while using DoD-WAN, as it is used to avoid the overloading of radio channels and hosts caches with out-of-date messages. According to the JMS specication, the DeliveryMode and Priority properties express the expected degree of reliability and priority for transmitting messages. Given the disconnected nature of the environments targeted by JOMS, it is not possible to ensure reliability as dened by JMS. JOMS uses these properties to increase the delivery probability for the most important messages by modifying the DoDWAN's cache management policy in order to give them more chances to be opportunistically disseminated.

Publish-subscribe model this model is very close to the publish-subscribe API provided by DoDWAN. Usually, JMS providers implement this communication pattern using a server-based model: the publications and subscriptions to a given topic are managed by a central entity. However, the implementation of publish-subscribe communications using a server-less model is quite obvious and well suited: messages published to a given topic are disseminated over the network; thus, any application service interested in this topic is given the opportunity to receive its messages. DoDWAN supports content-based dissemination, rather than destination-based routing of messages. Therefore, JOMS tags a message published to a given topic with the topic name, and then publishes it using DoDWAN; DoDWAN manages the message dissemination and the message delivery to all interested hosts. JOMS expresses applications' interest in receiving messages published to a given topic (topic subscribers) by adding the topic's name in their interest prole. Moreover, JMS selectors, allowing topic subscribers to lter the messages they receive, are added to the applications' interest prole; thus, the message ltering is processed at the communication middleware level.

The JOMS message shown in Fig. 2a, for example, is published to the topic ChatRoom1. This read-only text message, labeled 789, has the priority 4 and is to be delivered in persistent mode. It has been published at Mon Feb In D-MANETs, disconnections are the norm rather than the exception. As a result, the implementation of the JMS non-durable subscriptions concept, where messages are delivered only to active subscribers, is unsuitable and has no meaning for this environment. We deal with this problem by introducing a way to congure JOMS behaviour for non-durable subscriptions. By setting or unsetting some property, JOMS considers all non-durable subscriptions as durable ones, or refuses non-durable subscriptions and reports attempts to use them by throwing an exception.

Point-to-point model this model is built around the concept of queue which has a central role in transmitting the messages from a queue sender to one and only one queue receiver. In xed platforms, queues are maintained on a server which plays this central role in selecting the receiver of a message if there are multiple recipients associated with it. The main problem now is how to achieve this semantic of JMS queues in a D-MANET environment, where a server-based implementation is inappropriate, and where the consensus problem has not been however solved [START_REF] Fischer | Impossibility of Distributed Consensus with One Faulty Process[END_REF]. The approach to solve this problem is the so-called quasicentral queue approach: when an application creates a queue, its host will act as a queue manager (QM ) for this queue. Thus, JOMS forwards to this QM all applications' requests to be receivers for this queue and all the messages sent to this queue. Then, it is up to the QM to decide to which receiver is to be handed the message, and to forward it using DoDWAN. Even if this QM is turned o or becomes unreachable, DoDWAN gives it a chance to receive later all the missing requests and messages by caching them on many other hosts. Thus, this queue acts as a central decision-making but not as a central store. This approach has the benet that no consensus algorithm is required, thus making it more suitable for D-MANETs. For the sake of illustration, a QM's prole is shown in Fig. 2e.

This prole matches all messages sent to the queue MailBox1@00b0d086bbf7, whose descriptors contain this property in the same way as the message shown in Fig. 2a. Now, when an application wants to be a receiver for this queue, JOMS sends a request to the QM as shown in Fig. 2b. The QM will use the reply_id property in order to address messages to that application, that has this property in its interest prole.

It is worth noting that each queue manager applies a selection policy in order to choose one receiver for each message that matches the message properties in a fair way. The JOMS's administrator can override this policy in order to have a more appropriate one regarding his requirements.

Evaluating the performance of a middleware system capable of running in a D-MANET is obviously a tricky task. In the literature protocols and systems designed for D-MANETs are usually evaluated using network simulators, and little eort is devoted to investigate how they can perform when deployed in a real setting.

In contrast a major outcome of our work is the fact that JOMS 1 and DoD-WAN 2 have both been fully implemented in Java, and are now distributed under the terms of the GNU General Public License. They can thus be tested in real conditions. Indeed DoDWAN has already been deployed in dierent kinds of environments, including military tactical networks, and proved robust and reliable in such harsh conditions [START_REF] Haillot | Disruption-Tolerant Content-Driven Information Dissemination in Partially Connected Military Tactical Radio Networks[END_REF].

As explained in Section 1 a middleware system designed for D-MANETs can do no magic: unless otherwise specied its does not control how mobile hosts move in the network, so it cannot guarantee that a message will ever reach (or reach in time) any particular destination. The behavior JOMS can show in a D-MANET is therefore highly dependent on how this network evolves over time.

Based on this observation we conducted two series of experiments, rst within a single connected island, and then in a real disconnected network involving several user-carried mobile hosts.

Eciency of JOMS's messaging in a single connected island. We rst used two netbooks A and B, running JOMS over a Linux operating system. These netbooks were installed next to each other in the same room, and their built-in Wi-Fi 802.11bg chipsets were congured to operate in ad hoc mode. We measured the time required to transmit messages of dierent sizes from one netbook to the other. These messages were produced by host A and received by host B, using either a topic-based model or a queue-based model. In the rst case the messages were published to a topic by host A, and B was a subscriber to this topic. In the second case A hosted a local message queue, and B was a subscriber for messages deposited in this queue.

In order to get reference values regarding the capacity of the wireless link at application-level, we used the basic Netcat (nc) networking utility, that can read and write chunks of data across network connections.

Averaged over 150 rounds, the results of these tests are shown in Fig. 3-a, in terms of application-level data rates. Topic-based and queue-based messaging with JOMS obviously show similar performances. For large messages JOMS shows between 15% and 20% overhead over Netcat. Moreover the latency we measured when producing a message was around 10 ms with Netcat, and 25 ms with JOMS.

To complement these results we also investigated the behavior of JOMS when messages can propagate over multiple hops within a single connected island. The Considering that DoDWAN implements a sophisticated opportunistic protocol in order to orchestrate communications between neighbor hosts, we consider that the above-mentioned results are quite reasonable. Yet JOMS's most salient feature is of course that it can ensure the delivery of messages in a disconnected network, where traditional JMS providers (designed for connected environments) are totally useless.

Eciency of JOMS's messaging in a real D-MANET. In order to observe how JOMS can perform in such conditions we implemented a simple chat application based on JOMS. This application oers two services: public chat and private chat. The public chat service relies on the concept of topic: each message published on a topic can be received by all subscribers. With the private chat service, each message is addressed to a single message queue, which is hosted on the destination netbook.

A dozen of volunteers in our laboratory were equipped with netbooks running this application, and they were asked to carry their netbook whenever possible and use both chat services of course during a few days while roaming the laboratory building or its surroundings. Several one-day trials were conducted during this test, and an average of 250 chat messages were produced by volunteers during each trial. Fig. 4a illustrates how one particular message disseminated during one of the trials. This message was rst published in the public topic by netbook n1. After only a few minutes n1 established radio contact with n2, which thus got a copy of the message and became a new carrier for this message. n1 later managed to forward the message to n7 and n10 successively, while n2 forwarded it to n4, and later to n8. The message thus kept disseminating, until it reached the last subscriber n3, about 90 minutes after it was initially published. This example shows how a message can disseminate in a D-MANET, using unpredicted radio contacts as opportunities to reach new mobile hosts in the network.

In Fig. 4b we present the cumulative delivery rates of topic-based and queuebased messages, as observed during these trials. It can be noticed that nearly 60% of topic-based messages got delivered in less than 2 hours, whereas most queuebased messages took between 4 and 6 hours to be delivered. This dierence is due to the fact that reaching the holder of a given message-queue is more dicult than reaching any subscriber to a given topic. In any case the table shows that during the experiment most of the messages got delivered to their destination(s) in less than 10 hours. Yet, about 6% of the messages could not be delivered. This is the consequence of the unpredictable yet perfectly legitimate behavior of the users, which sometimes moved away from the laboratory or switched their netbook o unexpectedly. By doing so they prevented any further radio contact between their netbook and those of other users, and this of course lead to message loss.

Related work

A number of JMS providers have been developed in the last few years in order to support JMS in MANETs.

EMMA (Epidemic Messaging Middleware for Ad hoc networks [START_REF] Musolesi | EMMA: Epidemic Messaging Middleware for Ad Hoc Networks[END_REF]) is an adaptation of JMS that targets MANETs presenting connectivity disruptions.

EMMA assumes the availability of a so-called synchronous protocol, which can be used to reach mobile hosts that belong to the same cloud or island as the sender. An asynchronous epidemic routing protocol is used to disseminate messages towards remote clouds. EMMA manages queues in a manner that is quite similar to that of JOMS: each queue is maintained by a single holder, which advertises this object periodically with a set lifetime, and which can accept subscriptions from other hosts. EMMA and JOMS however dier in the way they deal with topics. In EMMA topics are managed just like queues, with a single holder per topic. In JOMS topic subscriptions can be set locally on any host. Messages published in a topic propagate in the network by being stored, carried and forwarded by all hosts that have subscribed to this topic. Other hosts can additionally contribute to the dissemination of such messages, provided they have been congured so as to behave as altruistic carriers. Another dierence between EMMA and JOMS is that in EMMA the gossiping mechanism between neighbor hosts is done in such a way that all messages are considered, so very large lists of message identiers can be exchanged between neighbor hosts. In JOMS this gossiping is content-based and thus more frugal since neighbor hosts only exchange messages based on their respective interest proles.

Extended JMS or E-JMS is another JMS provider, that uses an applicationlevel multicast routing protocol that provides publish/subscribe semantics by mapping JMS topics to multicast addresses [START_REF] Vollset | JMS on Mobile Ad Hoc Networks[END_REF]. Since this protocol cannot disseminate messages beyond a single connected fragment of the network, E-JMS is hardly usable in D-MANETs. It could probably be adapted, though, using a disruption-tolerant version of the multicast routing protocol. Another problem is that E-JMS requires that all JMS clients have a local copy of an identical conguration le, which contains information about queues and topics. No directory service (such as JNDI) is provided, so queues and topics cannot be created or destroyed dynamically during the execution of a distributed application. This is clearly a serious constraint, which limits the usability of E-JMS for developers.

EMMA and E-JMS both dene their own communication protocols. In contrast JOMS presents a two-layer architecture: the upper layer is concerned with queue and topic management and utilization, while the lower layer supports opportunistic communication. For the lower layer JOMS currently relies on DoD-WAN, a middleware system we designed to support content-based information dissemination in D-MANETs [START_REF] Haillot | A Protocol for Content-Based Communication in Disconnected Mobile Ad Hoc Networks[END_REF]. Yet JOMS could theoretically be implemented above any other communication system. Some protocols have been actually implemented in middleware systems and are openly distributed : DTN2, a reference implementation of protocols designed by the Delay-Tolerant Networking Research Group (DTNRG) [START_REF] Cerf | Delay-Tolerant Networking Architecture[END_REF], and Haggle, a content-centric architecture for opportunistic communication among mobile users (or devices) [START_REF] Nordström | A search-based network architecture for mobile devices[END_REF].

Conclusion

In this paper we have presented JOMS (Java Opportunistic Message Service), a JMS provider we designed and implemented specically for disconnected mobile ad hoc networks (D-MANETs). With JOMS distributed applications using message queues and topics as dened in the JMS specication can be deployed and executed in partially or intermittently connected ad hoc networks. An opportunistic, content-driven communication model is used to enable message forwarding in such networks, using mobile hosts as carriers that allow messages to propagate network-wide.

JOMS is distributed under the terms of the GNU General Public License. It is currently compliant with version 1.1 of the JMS specication, which dates back to 2002. The next version of the JMS specication, namely JMS 2.0, should be issued at the end of 2012. JOMS shall be modied or extended so as to comply with this new specication. In future work we also plan to leverage on JOMS in order to implement other distributed programming abstractions for D-MANETs, such as tuple spaces and future objects.

Fig. 1 :

 1 Fig. 1: Example of a D-MANET (disconnected mobile ad hoc network)

Fig. 2 :

 2 Fig. 2: Examples of message descriptors and message selectors

  13 20:54:03 CET 2012 and will die at Fri Mar 16 20:54:03 CET 2012 . The message selector language= English is a set of keywords characterizing this message.

Fig. 3 :

 3 Fig. 3: Data throughputs observed within a single island

Fig. 4 :

 4 Fig. 4: Message delivery in a real D-MANET


Abdulkader Benchi
email: abdulkader.benchi@univ-ubs.fr

Pascale Launay
email: pascale.launay@univ-ubs.fr

Frédéric Guidec
email: frederic.guidec@univ-ubs.fr

JION: A JavaSpaces Implementation for Opportunistic Networks

Keywords: peer-to-peer computing, opportunistic networking, DTN, coordination middleware, JavaSpaces

Disconnected mobile ad hoc networks (or D-MANETs) are partially or intermittently connected wireless networks in which mobile nodes are enabled to communicate with each other even if there is no end-to-end path connecting them. The special features of D-MANETs bring this technology great opportunities together with severe challenges. Coping with D-MANETs' issues while developing any distributed application remains a major challenge that must be met by the developers. A middleware system is thus needed between D-MANETs and applications levels in order to ease application development and help developers to take advantage of all D-MANETs' features. In this paper, we introduce JION (JavaSpaces Implementation For Opportunistic Networks), a standard coordination middleware specifically designed for D-MANETs, and with which pre-existing or new JavaSpaces-based applications can be easily deployed in such networks.

I. INTRODUCTION

A mobile ad hoc network (or MANET) is a dynamic wireless network that requires no fixed infrastructure. It is generally formed on-the-fly by a collection of wireless nodes without the aid of any centralized administration. Each mobile host can communicate with its neighbors using direct pair-wise wireless links. Communications in MANETs have been enhanced over the years thanks to multi-hop forwarding protocols, such as OLSR, AODV, DYMO, DSR... [START_REF] Liu | A Survey of Mobile Ad Hoc network Routing Protocols[END_REF].

Yet most of these protocols rely on the assumption that the whole MANET remains continuously connected: between any pair of hosts in the MANET, there actually exists at least one temporaneous end-to-end path. Unfortunately, this assumption does not hold in real conditions: many real MANETs are, under the most favorable conditions, only partially or intermittently connected.

The sparsely or irregularly distribution of MANET's hosts can, for example, induce link disruptions in the whole MANET. These disruptions in turn may split the whole MANET into a collection of distinct, continuously changing, disconnected "islands" (connected components) as shown in Figure 1. This kind of MANETs are called Disconnected MANETs (D-MANETs). The "store, carry and forward" approach, which fits in the general category of the Delay/Disruption Tolerant Networking (DTN) [START_REF] Fall | A Delay-Tolerant Network Architecture for Challenged Internets[END_REF], can be used here to bridge the gap between the non-connected parts of networks: the mobility of hosts makes it possible for messages to propagate network-wide by using mobile hosts as carriers (or data mules) that can move between non-connected parts of the network. As shown in Figure 1, the connectivity disruptions are indeed tolerated thanks to the user moving (deliberately or by chance) from island 1 to island 2. This user's device acts as a data mule for messages addressed to hosts located in island 2. Considering that many carriers may be involved during the transmission of a message, this approach generally provides message delivery at the price of additional transmission delays. Taking for example the message transmission from island 1 to island 4 shown in the Figure 1, two message carriers are needed to be involved in this transmission: one from island 1 to island 2 and another one from island 2 to island 4.

In the DTN community, some approaches make the assumption that communications between the hosts can be predicted accurately, and routing strategies can be thus devised based on contact predictions. But in most real D-MANETs, communications are not planned in advance and cannot be predicted, especially if the physical carriers are for example human beings carrying laptops or smartphones. The term opportunistic networking [START_REF] Pelusi | Opportunistic Networking: Data Forwarding in Disconnected Mobile Ad Hoc Networks[END_REF] is often used to denote these disruption tolerant networks where the contacts must be exploited opportunistically. In such wise, each contact represents an opportunity for two hosts to exchange messages. Consequently, communication protocols for D-MANETs usually provide no more than best-effort delivery. Consider again the example shown in Figure 1, and assume a message is addressed by a host in island 2 to a host in island 3. If no human carrier ever visits the island 3, then there is no chance that the message ever gets delivered in this island.

The dynamic nature of D-MANETs creates many challenges for application developers. Due to the inherent stochastic nature of D-MANETs, no host can be considered as stable and accessible enough to play the role of a server for all the other hosts. Consequently, applications developers should generally use a peer-to-peer model rather than a client-server one. Developers, while writing their applications, should additionally take into consideration occasional transmission failures and long transmission delays.

All these reasons result in an increasing need for a middleware system that, while coping with D-MANETs issues, provides the developers with a set of APIs that eases the development of distributed applications over D-MANETs. However, any middleware for D-MANETs must have an asynchronous nature in order to fit with the long transmission delays observed in such networks.

In the remainder of this paper we present JION (JavaSpaces Implementation for Opportunistic Networks), a coordination middleware system we designed and implemented specifically for D-MANETs. JION is actually an implementation of the JavaSpaces specification, so any pre-existing distributed application basing on the JavaSpaces API can be executed in a D-MANET with no further development using JION.

This paper is structured in the following way: the JavaSpaces specification is described briefly in Section II. Section III presents the JION's architecture along with details about its implementation. Evaluation results are shown in Section IV. Section V discusses related work. Section VI concludes this paper and describes our plans for future work.

II. JAVASPACES BACKGROUND

The JavaSpaces technology, implemented by JION, is a Java specification of the concept of tuple space which was originally introduced in the Linda programming language [START_REF] Carriero | Linda in context[END_REF]. In this section we provide a brief introduction to the tuple space as introduced in Linda. The JavaSpaces technology will be presented as well.

A. Tuple space

The tuple space concept has its root in the Linda parallel programming language [START_REF] Carriero | Linda in context[END_REF] developed at Yale University. A tuple space is a shared data space acting as an associative memory used by several processes for communication and/or coordination requirements. A Linda application is viewed as a collection of processes cooperating via the flow of data structures, called "tuples", into and out of a tuple space. Each tuple is a record of typed fields containing the information to be communicated. The coordination primitives provided by Linda allow processes to insert a tuple into the tuple space (out) or retrieve tuples from the tuple space, either removing those tuples (in) or preserving the tuples in the space (read). For retrieving operations, the tuples are selected using a simple pattern matching from a given set of parameters.

B. JavaSpaces

The JavaSpaces technology is a Java specification of the tuple space concept, implemented inside the JINI architecture.

It defines a set of application programming interfaces (APIs) which extends the simple core of the Linda primitives. The JavaSpaces version of Linda tuples, called "entries", are Java objects which contains public fields that act as the Linda's typed fields. JavaSpaces provides read, take and write operations in order to fulfill Linda's read, in, out operations respectively. Moreover, it provides a notify operation which allows processes to do a lookup operation in an asynchronous manner. This operation notifies the processes by sending a special object called event containing information to which the processes react. The matching in read, take and notify operations are performed using a special kind of entry, called a template, that characterizes the kind of entries the process wants to look for. The selected entries are those whose types and fields match the template. Furthermore, JavaSpaces provides lite versions of read and take operations where processes do not need to wait for the answer. These operations, called readIfExist and takeIfExist, can be useful when a process wants an answer immediately with out waiting. As JavaSpaces' entries are passive data, processes cannot perform operations on tuples directly. In order to modify an entry, a process must explicitly remove, update and reinsert it into the space.

III. JAVASPACES IMPLEMENTATION FOR OPPORTUNISTIC NETWORKS (JION)

The JavaSpaces technology was primarily designed to provide persistent object exchange areas (spaces) through which processes coordinate actions and exchange data. Most of the JavaSpaces implementations are server-based systems where centralized servers are used to manage these spaces. As explained in Section I, a server-based system is hardly compatible with the characteristics of D-MANETs as no host can act as a reliable server for all the other hosts. A server-less JavaSpaces implementation must then be developed in order to provide JavaSpaces services for D-MANETs.

JION, or JavaSpaces Implementation for Opportunistic Networks, is a JavaSpaces implementation that was designed along that line. Its architecture is composed of two basic modules: the communication middleware system and the JavaSpaces services system.

A. Communication Middleware

Building any application for D-MANETs requires some communication middleware system with which hosts can collaborate in a peer-to-peer manner to ensure message transportation. JION relies on a communication middleware system called DoDWAN (Document Dissemination in mobile Wireless Ad hoc Networks) [START_REF] Haillot | A Protocol for Content-Based Communication in Disconnected Mobile Ad Hoc Networks[END_REF]. DoDWAN has been designed in our laboratory, and it is now distributed under the terms of the GNU General Public License1 .

DoDWAN supports content-based information dissemination in D-MANETs. In content-based networking, information flows towards interested receivers rather than towards specifically set destinations. This approach notably fits the needs of applications and services dedicated to information sharing or Board= "Sports" Topic= "football" Language= "English" (a)

Board= "Sports" Topic= ".*ball" Language= "English | French | German" (b)
Figure 2: A message descriptor and a message selector event distribution. It can also be used for destination-driven message forwarding, though, considering that destinationdriven forwarding is simply a particular case of content-driven forwarding where the only significant parameter for message processing is the identifier of the destination host (or user).

Messages in DoDWAN are composed of two parts: a descriptor and a payload. The payload is simply perceived as a byte array. The descriptor is a collection of attributes expressed as (name, value) tuples, as illustrated in Figure 2a. These attributes can be defined freely by the developers of application services built on top of DoDWAN.

DoDWAN implements a selective version of the epidemic routing model proposed in [START_REF] Vahdat | Epidemic Routing for Partially Connected Ad Hoc Networks[END_REF]. It provides application services with a publish/subscribe API. When a message is published on a host, it is simply put in the local cache maintained on this host. Afterwards each radio contact with another host is an opportunity for the DoDWAN system to transfer a copy of the message to that host whenever it is interested.

In order to receive messages, an application service must subscribe with DoDWAN and provide a selection pattern that characterizes the kind of messages it would like to receive. A selection pattern is expressed just like a message descriptor, except that the value field of each attribute contains a regular expression, as shown in Figure 2b. The selection patterns specified by all local application services running on the same host define this host's interest profile. DoDWAN uses this profile to determine which messages should be exchanged whenever a radio contact is established between two hosts. Details about this interaction scheme and about how it performs in real conditions can be found in [START_REF] Haillot | A Protocol for Content-Based Communication in Disconnected Mobile Ad Hoc Networks[END_REF].

As a general rule, a mobile host that defines a specific interest profile is expected to serve as a mobile carrier for all messages that match this profile. Yet a host can also be configured so as to serve as an altruistic carrier for messages that present no interest to the application services it runs locally. This behavior is optional, though, and it must be enabled explicitly by setting DoDWAN's configuration parameters accordingly.

Mobile hosts running DoDWAN only interact by exchanging control and data messages encapsulated in UDP datagrams, which can themselves be transported either in IPv4 or IPv6 packets. Large messages are segmented so that each fragment can fit in a single UDP datagram. Fragments of a large message can propagate independently in the network and be reassembled only on destination hosts.

B. JION Implementation

According to the JavaSpaces specification, processes coordinate by exchanging entries through the space using a simple set of operations. Entries and operations represent the basic JavaSpaces' elements. This section describes the JION's architecture and its entry module along with the supported operations.

1) JION's architecture: As mentioned in Section III, JION is a server-less JavaSpaces implementation, as it is intended to be used in D-MANETs where no host can act as a server. Each host maintains a local space in which JION stores the entries produced locally (that is, entries produced by write operations which have been invoked by local processes). If entries were propagated all over the D-MANET and managed in a collaborative manner, this could result in orphan entries: as stated in [START_REF] Fischer | Impossibility of Distributed Consensus with One Faulty Process[END_REF], it is impossible to obtain a consensus between hosts in a distributed disconnected environment. Consequently, D-MANET's hosts could not agree to remove any entry from the space, for example when a process wants to take it. Imagine that an entry has been propagated over the hosts in the islands shown in Figure 1, and a process in island 1 takes this entry. If no user ever visits the island 5 for example, the copies of this entry in this island will become orphan entries. In JION, the write operations are only processed locally, while matching and fetching operations (read, take and notify) are processed by querying hosts over the network for the entries they own.

2) Entries and Templates: According to the JavaSpaces specification, an entry is an object reference characterized by its "fields". In the JavaSpaces terminology, entry fields refer only to the public fields of the entry objects. In fact, entry fields are meant to act as a set of attributes characterizing an entry, and are used to perform matching operations while retrieving entries from the space.

As mentioned above, a DoDWAN message has two parts: a descriptor and a payload. Since DoDWAN's descriptor is also meant to characterize the content of the message, JION maps the entry's fields to the DoDWAN's descriptor, as their content is needed by JION to do match operations. The rest of the entry (that is, non-public fields) is simply carried in the message as its payload, and considered as a simple byte array.

Templates are special entry objects whose fields' values are used in match operation. This notion of a template in JavaSpaces is mapped to the DoDWAN's selection pattern which will be used by JION for the pattern matching operation.

3) Operations: According to the JavaSpaces specification, entries' access must be done through a set of basic operations, which are: write, read, take and notify. This section describes in detail the way JION supports these operations.

write: this operation stores a new entry into the host's local space for a specific period of time, called a lease. A lease represents the lifetime of its associated entry. As mentioned above, each entry is only stored on the local host and is not replicated over the D-MANET. Therefore, it is up to each host to monitor its local space and manage its own entries, and especially ensure that out-of-date entries are not used anymore.

read: this operation requests the JION service for an entry that matches the template provided as a parameter. When a process on a host performs a read operation, the host's local space is queried first in order to find a matching entry. If no matching entry is found, JION disseminates the specified template over the D-MANET. Each host, when it receives this template, will then query its local space to find a matching entry and forward a copy of it back to the requesting process. It is then up to the requesting process to choose one entry as an answer to its read request. Furthermore, readIfExists is also supported by JION. This version queries only the local space to find an entry that matches the specified template. In any case, the request will not be disseminated over the D-MANET.

take: this operation basically performs the same function as read, except that it removes the matching entry from the space. So, for a take operation, JION searches first the local space. If no match is found, JION queries all the hosts over the D-MANET in order to discover which hosts (if any) have a matching entry. Upon receiving the proposals, JION selects one host from which the entry should be taken. JION then asks the chosen host to permanently remove the matching entry from its local space and hand it back to the requesting process. The entire operation may take more time than the read operation since it needs four exchanges to be achieved while two exchanges are required in the read operation. JION supports also a takeIfExists operation which performs exactly like the corresponding readIfExists, except that a matching entry is only requested from the local space.

notify: this operation notifies a process when entries that match a given template are written into a space. So when a notify operation is performed by a process, JION disseminates the given template all over the hosts in the D-MANET. The hosts, in their turn, register the notify request in the hope that a matching entry will be written before the request's lifetime expires. Consequently, when a matching entry is written in a host, the host forwards an event object containing information about this entry and its location to the requesting process.

4) Transactions: According to the JavaSpaces specification, it is possible to group multiple operations (participants) into a bundle that acts as a single atomic operation. This is done using the optional concept of transaction. Either all operations within the transaction will be performed or none will. In fullyconnected stable networks, a transaction is controlled by a specific manager (server) which should always be reachable by all the participants. If a participant is momentarily disconnected, the whole transaction is aborted. Given that hosts in D-MANETs can neither have a reliable server nor agree between themselves, it is not possible to ensure transactions as defined by JavaSpaces. For this reason, JION does not support the concept of transaction and each operation is considered as a singleton operation.

IV. EVALUATION

A D-MANET is a wireless network whose topology is continuously changing, and where radio contacts between mobile hosts do not necessarily follow any predictable pattern. Therefore, protocols and systems designed for D-MANETs are usually evaluated using network simulators. The originality of our work lies in the fact that JION has been fully implemented in Java and is now distributed under the terms of the GNU JION has seen extensive testing to examine how well it performs in D-MANETs. While conducting these tests we strived to evaluate how easy it is for an application developer to implement a distributed application using JION. Furthermore, we have evaluated the efficiency of JION in a real D-MANET.

Read operation Take operation Netcat

A. Developing distributed applications with JION

JION implements the Sun Microsystems' JavaSpaces Technology specification provided as a part of the Java Jini Technology [START_REF] Freeman | JavaSpaces(TM) Principles, Patterns, and Practice[END_REF]. Since JION implements a well-known middleware specification, developers do not need to learn a new programming language, or get familiar with an exotic programming model or API. A developer can simply focus on writing a standard JavaSpaces application, and JION will take care of its execution in a D-MANET. Indeed, any pre-existing JavaSpaces application can be deployed using JION, without any change in its source code.

Developers should however be aware of the specific constraints posed by D-MANETs, where message delivery, message ordering, and transmission delays are usually not guaranteed. Such constraints are not due to limitations in JION; they are due to the very nature of D-MANETs. As explained in Section I, opportunistic protocols and middleware systems designed for D-MANETs can do no magic: they can support network-wide communication in a D-MANET, using mobile hosts as carriers that help to bridge the gap between nonconnected parts of the network. Yet, unless otherwise specified they do not control how mobile hosts move in the network, so they cannot guarantee that a message will ever reach (or reach in time) any particular host in the network. A developer working on an application for D-MANETs should therefore assume that delivery failures and late deliveries may be more common than in-time deliveries, and design the application or organize its deployment accordingly.

For testing and evaluation purposes, we have developed a distributed bulletin board system (D-BBS) inspired from the classical bulletin board system (BBS). A BBS typically consists of a number of bulletin boards which serve as discussion areas relating to general themes. Each bulletin board is generally labeled by an expressive name describing its contents (e.g., Sports). On each board, users can post, read and delete messages under different topics. Since BBS typical implementations are usually server-based, they are not well adapted to D-MANETs, so we developed this application using the JION middleware. In D-BBS, posting a message on a board under a topic is implemented by creating a tuple having the board's and the topic's names as fields and writing it into the JION's space. Similarly, reading/deleting a message from a specific board under a specific topic is performed by creating a template having the board's and topic's name as fields. This template is then to be passed as a parameter to the JION's read/take function. Furthermore, the developer can get benefit from JION's notify function in order to keep users up to date with changes on a specific board under a specific topic using an appropriate template.

Developing and deploying this application for a D-MANET was a straightforward task. Using JION, the programmer focuses on the application features without boring about the specific issues of this kind of very challenging environment.

B. JION efficiency over D-MANETs

Before trying to observe how entries can propagate between several islands in a disconnected network, one can first try to measure how fast they can propagate within a single island. Since JION is implemented on top of the DoDWAN communication system, which itself relies on UDP transmissions, our first objective was to evaluate how our multi-layer middleware architecture performs over the underlying wireless transmission medium.

We first used two netbooks A and B, running JION over a Linux operating system. These netbooks were installed next to each other in the same room, and their built-in Wi-Fi 802.11bg chipsets were configured to operate in ad hoc mode. We actually focused on the response time, which is here defined as the time interval between the time the netbook A writes entries of different sizes and the time when the netbook B receives them using the read/take operations. In order to get reference values regarding the capacity of the wireless link at application-level, we used the basic Netcat (nc) networking utility, that can read and write chunks of data across network connections. 200 series of tests were conducted in this scenario. The results of these tests are presented in Figure 3. Read and take operations show similar performances. However, JION shows about 20% overhead over Netcat. Considering that JION's communication middleware (DoDWAN) implements a sophisticated opportunistic protocol in order to orchestrate communications between neighbor hosts, we consider that these results are quite reasonable.

To increase realism, another real world test was conducted to investigate the behavior of JION when messages can propagate over multiple hops. The tests was carried out by four netbooks (A, B, C and D) distributed in our laboratory. Because of the effect of concrete walls on signal attenuation, the connectivity between these netbooks was such that netbook B could only communicate with A and C, while netbook D could only communicate with C. This test relied on the write/read operations: a total amount of 225 entries were written on B, C, D, and the host A was configured to read these entries. We measured the average time required for these entries to reach the netbook A. The results of this test are shown in Figure 4. We can observe that the time by which the host A gets an entry changes according to the size of entry and the number of hops over which the entry has to be transmitted. As increasing the size of the entry and the number of hops, the response time generally increases. This is because when host B serves as a relay between its neighbors A and C, the radio channel around B is twice as busy as when B interacts only with host A. The same observation applies for host C when it must serve as a relay between hosts B and D. It must also be considered that DoDWAN uses many mechanisms to ensure a high delivery ratio, so entries are retransmitted again and again if they are not received in first place. In the last test, the host A has received all of the 225 sent entries.

Furthermore, we used our D-BBS application to observe how JION can perform in a real D-MANET. A dozen of volunteers in our laboratory were equipped with netbooks running D-BBS. Several one-day tests were conducted by asking the volunteers to carry their netbook whenever possible -and use D-BBS services of course-during a few days while roaming the laboratory building or its surroundings. To analyze the results special attention was paid to the cumulative delivery rates of read/take operations as shown in Figure 5. The cumulative delivery rates were measured in term of time slices where a measure of 2 hours means that the average delivery time observed was between 0 and 2 hours; a measure of 4 hours means it was between 0 and 4 hours, etc. Using the read operation, It can be noticed that nearly 59% of the entries got delivered in less than 2 hours. However, the majority of hosts had to wait between 4 and 6 hours in order to get the required entries using the take operation. This difference is expected since the take operation requires more rounds than the read one. In general, the results show that most of the entries got delivered to their destination(s) in less than 10 hours. Yet, about 6% of the entries could not be delivered. This is the consequence of the unpredictable behavior of the users, which sometimes moved away from the laboratory or switched their netbook off unexpectedly.

V. RELATED WORK

In the last few years, several projects focused their attention on the rebirth of Linda [START_REF] Carriero | Linda in context[END_REF], especially in the context of mobile ad hoc environments.

Both Ara [START_REF] Peine | The Architecture of the Ara Platform for Mobile Agents[END_REF] and LIME [START_REF] Murphy | LIME: A Coordination Model and Middleware Supporting Mobility of Hosts and Agents[END_REF] are coordination middleware implementing tuple spaces stored on hosts acting as servers. These middleware target mobile ad hoc networks. They provide JavaSpaces services to mobile hosts that are in the servers' communication range. Since they rely on a server-based model, they are hardly usable in real D-MANETs. Limone [START_REF] Fok | A Lightweight Coordination Middleware for Mobile Computing[END_REF] is a lightweight alternative to LIME requiring far less overhead than it. Limone starts with the premise that a single round trip message exchange is always possible, making it impractical over D-MANETs, if not impossible, where unpredictable disconnections are always considered as the norm rather than the exception. In contrast, CAST [START_REF] Roman | Tuple Space Coordination Across Space and Time[END_REF] is a server-less coordination middleware for MANETs. By not relying on any centralized service, this middleware suits well the dynamics of wireless open networks. CAST makes it possible to process operations even when no end-to-end route exists between the involved hosts, by implementing a source routing algorithm. This routing strategy relies on the assumption that each host's motion profile is known. This is clearly a serious constraint which limits the usability of CAST over the kind of real D-MANETs JION targets, where hosts' motions are not planned and cannot be predicted. Tuple board (TB) [START_REF] Kaminsky | Tuple Board: A New Distributed Computing Paradigm for Mobile Ad hoc Networks[END_REF] is another server-less coordination middleware for developing collaborative applications running on ad hoc networks of mobile computing devices. Like JION, this middleware has been fully implemented and also distributed. It can thus be used and tested in real conditions. However, the proposal lacks flexibility, in that it is limited to a group of nearby connected devices: when a device leaves the network or turns off, all the tuples posted from this device are withdrawn. The importance that we attribute to disconnections make the disconnection tolerance a vital requirement for any middleware that is meant to support D-MANETs.

Furthermore, all of the middleware mentioned above define their own communication protocol for route discovery and maintenance. Our work is different as JION presents a twolayer architecture: the upper layer is concerned with tuple space services, while the lower layer supports opportunistic communication. As mentioned above, DoDWAN has been chosen from among a few other opportunistic communication protocols that are openly distributed to support opportunistic communications on D-MANETs. Yet JION could theoretically be implemented above any other communication system: DTN2, a reference implementation of protocols designed by the Delay-Tolerant Networking Research Group (DTNRG) [START_REF] Cerf | Delay-Tolerant Networking Architecture[END_REF], or Haggle, a content-centric architecture for opportunistic communication among mobile devices [START_REF] Nordström | A Search-based Network Architecture for Mobile Devices[END_REF].

VI. CONCLUSION AND FUTURE WORK

In this paper we have introduced JION (JavaSpaces Implementation for Opportunistic Networks), a JavaSpaces implementation we designed and implemented specifically for disconnected mobile ad hoc networks (D-MANETs). Using JION, distributed applications which are based on the concept of tuple spaces as defined in the JavaSpaces specification can be deployed and executed in D-MANETs. JION provides an effective base which eases the development of D-MANETs' applications. It is tested in real conditions and now distributed under the terms of the GNU General Public License.

Currently, we are performing several more tests in rural areas to verify how stable JION is in such very challenging environments. For the short-term future work, we plan to implement JION over another communication middleware in order to stand on the portability of JION over communication systems other than DoDWAN.

Figure 1 :

 1 Figure 1: Example of a disconnected mobile ad hoc network

Figure 3 :

 3 Figure 3: Response time observed between two netbooks

Figure 4 :

 4 Figure 4: Response time between multi-hop neighbors

Figure 5 :

 5 Figure 5: Entry delivery in a real D-MANET

http://www-irisa.univ-ubs.fr/CASA/DoDWAN/

http://www-irisa.univ-ubs.fr/CASA/JION/