Tiamat: Generative Communication in a Changing World

Transcription

1 Tiamat: Generative Communication in a Changing World Gareth P. McSorley and Huw Evans Department of Computing Science, University of Glasgow gareth@dcs.gla.ac.uk Abstract Providing infrastructural support for pervasive computing environments is difficult due to their ever changing, resource-limited nature. In such environments, generative communications would be of benefit due to the decoupling the paradigm offers. This paper introduces Tiamat, a system which provides a coordination infrastructure for applications in pervasive environments based on generative communications. The Tiamat model maps naturally onto the key characteristics of a pervasive environment and provides a flexible infrastructure, through the use of opportunistic logical tuple spaces, as well as a fine-grained resource management mechanism, via its leasing model. The Tiamat model is presented along with an overview of the current implementation. A set of challenges which must be faced when developing infrastructure for pervasive environments is presented. Future extensions to Tiamat to meet some of these challenges are also described. 1 Introduction Pervasive computing environments typically contain heterogeneous collections of devices, from highly mobile, resource limited PDAs to the largely static, resource-rich modern workstation. One of the challenges for pervasive computing is the coordination of all the disparate, mobile devices in order to allow useful applications to be constructed. One potentially fruitful approach is to use generative communications, which provide decoupling in terms of space, time and identity, to provide a distributed coordination infrastructure for the devices in the pervasive environment. Generative communications, as exemplified by Linda [1], involve the communication of messages through a shared data space, called a tuple space. The units of communication are ordered collections of typed data, called tuples. s are placed into the space by one participant and kept there until they are removed by another, the system typically providing a pattern matching service to find the desired tuple. Generative communications were originally devised to support the coordination of parallel processes. The paradigm has since been applied to other environments including a variety of distributed systems. Generative communications provide three forms of decoupling which are particularly suited to managing devices in a pervasive, mobile environment. Generative communications are decoupled in terms of identity. When tuples are placed in the tuple space they are available to any entity interacting with that space. The consumer of a tuple does not have to be concerned with the identity of the process that made the tuple available, all that is of concern is that the correct tuple can be retrieved. This is useful in a pervasive environment where entities may come and go frequently. In this environment it is not desirable to direct communications toward a particular entity. Rather, it would be better to continue communicating as long as there is another available entity that is willing to coordinate. Generative communications are also decoupled in time. The tuple space is an asynchronous communication mechanism, that is, the producer and the consumer of the data do not need to simultaneously connect to the same space, indeed, they do not even need to exist at the same time because the tuple space ensures the data is independent of the creating entity. This is useful in a pervasive environment as a device may not exist long enough to communicate with another device directly (it may run out of battery power, for example). Finally, generative communications are decoupled in location. The asynchronous nature of the space means that the two coordinating entities do not need to be co-located. This is useful in a system where the entities are frequently mobile and, as a result, coordinating entities may not be co-located long enough to coordinate effectively. This paper introduces Tiamat, a system that has been designed and implemented with the goal of bringing the generative communication paradigm to a pervasive environment. This work is motivated by the need to address the engineering problems which have arisen in previous attempts to provide this kind of infrastructure in a mobile environment. Tiamat achieves this by providing a model and infrastructure which are designed around the environment rather than being imposed upon it. Tiamat provides generative communications through the use of opportunistic logical tuple spaces formed from multiple remote tuple spaces. Opportunistic spaces provide

2 a simple abstraction over the underlying changes in the environment, allowing application programmers to focus on achieving their goals without having to manage the coordination. The remainder of this paper is organised as follows. The Tiamat model is described in Section 2 and is followed by a discussion of the current implementation in Section 3. Section 4 outlines related work in distributed generative communications. Key challenges for the construction of infrastructure for pervasive environments are described in Section 5. Future work is detailed in Section 6 and the paper is concluded in Section 7. 2 The Tiamat Model This section presents the core concepts in the Tiamat model, which has been designed around the constraints and demands of the underlying pervasive environment. Tiamat provides the abstraction of opportunistic logical spaces allowing Linda-like semantics to be provided in the face of environmental change. Tiamat also provides leases as a means of fine grained resource management. 2.1 Linda Semantics Tiamat aims to provide the well understood semantics of traditional generative communication systems. The goal of Tiamat was to retain the semantics of Linda as far as possible and so keep the API simple. Linda provides six operations over the space. The out and eval operators are used to put a tuple into the space. s placed into the space become available to any process performing other operations. In the case of eval the tuple is considered active and contains some computation which must be carried out before the resultant tuple becomes available. The rdp operator searches the tuple space for a tuple matching a given pattern, traditionally called an antituple. If a matching tuple is found, a copy is returned to the caller. If there are multiple matches, one is selected in a non-deterministic manner. The rd operation performs the same function as rdp with the exception that, if there is no matching tuple in the space, the operation will block awaiting a match. When a matching tuple becomes available, the operation will then return. The operations inp and in behave in the same manner as rdp and rd respectively, except that, if a match is found, it is removed from the space before being returned to the caller. 2.2 Opportunistic Logical The nature of a pervasive environment means that the presence of other devices cannot be relied upon. For this reason, each node in Tiamat contains a local tuple space to allow applications to perform tuple space operations through Tiamat even if working in isolation. As well as providing access to the local space, instances of Tiamat also establish connections with other instances for the purpose of forming logical tuple spaces. A logical tuple space is formed from the local tuple space and the tuple spaces of any other currently visible instances of Tiamat. Another instance of Tiamat is considered visible if it can be communicated with in some way. The exact means of this communication may be implemented in different ways, e.g., through direct communication only, or routed through other instances. The Tiamat model does not depend on any particular implementation of visibility, only the concept of visibility. This concept is depicted in figure 1. In part (a) we see two isolated Tiamat instances. In this case the logical tuple space for each instance consists solely of their local space. If these instances become visible to one another, then the logical tuple space will now be a combination of the two local spaces, as shown in (b). This allows each instance to utilise each others tuple spaces. Tiamat defines no global consistency guarantees; that is, it is possible for Tiamat instances to see different logical spaces. This scenario is depicted in part (c) where a third instance, C, becomes visible to instance B, but not to instance A. Instance B now has a logical tuple space consisting of all three tuple spaces. The logical tuple spaces for instances A and C, however, only consist of their own local space along with the space from instance B. (a) (c) Instance A Instance A Instance B Instance B Instance C (b) Key Instance A Network Connection Instance B Logical for instance A Logical for instance B Logical for instance C Figure 1: Logical Operation By default, applications do not interact with the individual local spaces. Rather they interact with the logical space presented by Tiamat. The operations out and eval by default, operate only on the local space. In the case of the operations in, inp, rd and rdp, Tiamat will not only perform the operation on the local space, but will propagate the operation to other currently visible instances, and instances which become visible during the lifetime of the operation (defined by the associated lease as described in Section 2.5). These instances will then attempt to satisfy the operation on their local spaces. If multiple instances locate matching tuples, some appropriate decision should be made as to which one to accept,

3 and the others should remain in their spaces. By providing this default behaviour, an application can use the Tiamat system to coordinate transparently with another application which may be located on a remote host. 2.3 Flexible, Adaptive Model Constructing the logical tuples space opportunistically, as operations are performed, removes the need for explicit connection/disconnection operations. Tiamat instances can enter or leave the scope of visibility without affecting the semantics of any ongoing operations (although their departure may affect the result of the operation). Explicit connection/disconnection requirements were avoided as they are unsuitable for a pervasive environment where mobile hosts may come and go frequently. Although no explicit connection/disconnection operations are required, they may still be provided in the implementation to allow application developers to choose whether instances passively or actively perceive change in the set of visible instances. An opportunistic model allows Tiamat to adapt to changes in the mobile environment. 2.4 Direct Remote Communications The abstraction over underlying changes provided by the logical tuple space allows applications to function without direct knowledge of remote Tiamat instances. However, it is important that Tiamat does not prevent an application from obtaining this knowledge if it so desires. As such, Tiamat offers applications the means to interact with specific instances when required. This functionality is particularly useful in the case of out and eval where the local space may be refusing to accept the tuple due to resource shortages (see Section 2.5), or in the case where the application wants to make tuples available to other Tiamat instances even after it leaves. In order to support this, each tuple space in Tiamat contains a special tuple. This tuple contains a handle on the space as well some information about that space e.g., whether the local space provides a persistence mechanism or not. Applications can read these tuples and use the handles to perform operations on specific remote spaces. All of the provided operations have special versions which take these handles and perform the operation requested on the remote space specified. Another means of supporting this is provided in the case of out and eval through a third version of each command. These take in a tuple which was returned as a result of a prior in, inp, rd or rdp operation. Tiamat will then attempt to satisfy the operation at the remote instance where the given tuple was obtained. If the destination is not available, then a policy, either at the application or system level, must be established as to whether there are attempts to route the tuple, whether it is placed in the local space, or whether the operation is abandoned altogether. 2.5 Resource Management Tiamat defines a leasing model in which every operation is leased. Whenever an application performs an operation, it must first negotiate a lease with Tiamat. These leases represent the effort a Tiamat instance is willing to dedicate to carrying out the operation. These leases may be based on time or on other measures such as the number of remote instances contacted. Each lease incorporates the concept of expiration, after which the leased resource (e.g., storage space or network resources) may be reclaimed. The final decision as to what lease is actually granted, or if a lease is granted at all, is made by the Tiamat instance. Leases are only valid for the instance which grants them and are not transferable across instances. Any Tiamat instance which, during the course of performing an operation, places demands on another, is responsible for negotiating any further leases. Due to the unpredictable nature of a pervasive system, the leases offered do not represent absolute guarantees. Rather they represent a best-effort on the part of the system to satisfy the application s request. If circumstances change substantially, a Tiamat instance may revoke the lease; although this behaviour should only be employed as a last resort to avoid undermining the leasing system altogether. For the out operation, once the lease expires, the tuple may be removed from the space at anytime. For the eval operation, when the lease expires the resultant computation (if it has not already finished) may be halted and the tuple may be removed. In the case of of in, inp, rd and rdp once the lease expires, the Tiamat instance may stop trying to satisfy the request and, assuming no match has already been found, return nothing. In the case of the blocking operations, in and rd, this represents a slight semantic alteration which is necessary in order to avoid indefinite consumption of resources. Leasing has been included into the Tiamat model in order to provide the facility for fine-grained resource management within Tiamat instances. Due to the asynchronous, identity-separated nature of generative communications, it is not normally possible to identify tuples as being garbage. In Tiamat, the leasing model allows tighter controls to be placed on how long tuples may reside in the space before being removed. By also extending the leasing mechanism to all operations, and by allowing lease expiration to be defined in terms of resources used, as well as just time, a Tiamat instance can control access to its resources on a resource by resource basis. This is crucial in a pervasive environment due to the wide variety of hardware capabilities and resource capacities that are typically found on pervasive

4 devices. The leasing mechanism also allows application programmers to specify upper boundaries on availability of their tuples. 3 Current Tiamat Implementation An initial prototype implementation of the Tiamat model has been produced and is now in use. The Tiamat implementation has been tested by providing a number of simple applications. This section highlights the most pertinent parts of the current implementation. 3.1 Overview The prototype implementation has been constructed entirely in Java. Java was selected due to its portable nature and availability on a wide variety of devices including PDAs and phones. In the current implementation, the only deviation from the model is that operations are only propagated to instances which are visible at the beginning of the operation. Instances which become visible after the operation starts are not included. This is an area for future work. Application Lease Manager Application Comms. Manager Figure 2: A Tiamat Instance Network Communication An overview of a Tiamat instance as presently implemented is shown in figure 2. The lease manager deals with all of the resource management within the system and is the first point of contact for any operation. If a lease is refused, no further work is carried out on the operation. The local tuple space is where all of the tuples in the Tiamat instance are stored. The communications manger is responsible for contacting remote instances of Tiamat, propagating any operations to remote nodes, receiving the results of those operations and receiving requests for operations from other instances Lease Manager All resources that an instance wishes to manage (e.g., threads, sockets) are allocated through factory objects controlled by the lease manager. This allows the lease manager to maintain control over the amount of resources being consumed and allocate leases accordingly. The leasing of operations is performed by applications passing lease requester objects to the system along with their tuples. These lease requester objects have the task of negotiating with the lease manager inside Tiamat. Firstly, a lease requester makes a request to the lease manager. The lease manager then informs the lease requester of what lease it is willing to offer. If the lease requester refuses this lease, then the operation fails The tuple space currently used within the Tiamat system is a basic, custom built tuple space system. The tuple space could be replaced with any system which implements the six standard Linda operations Communications Manager The communications manager is responsible for defining the scope of visibility for the Tiamat model. In the current implementation the visibility of Tiamat instances is defined by a multicast. Normally, when an operation is performed the Tiamat instance involved sends out a multicast packet. Other instances which receive this packet respond, informing the sender of the address and port number on which they should be contacted. The Tiamat instance may then choose to propagate the operation to the instances which respond. If, once the operation is propagated, multiple instances respond with a match, then the first instance to contact the communications manager is accepted and the remaining instances place the tuples back into their respective spaces. While the opportunistic construction of the logical spaces provides adaptability it would be expensive to gather a list of visible hosts for each and every operation via a multicast, particularly if the set of visible hosts happens to change infrequently. The current implementation retains a list of instances which respond to the multicast packets when an operation takes place. When the instance performs subsequent operations, it begins by contacting the instances already on the list, removing any which do not respond. If the end of the list is reached, and the request is not satisfied, then another multicast may be used to try and find more instances. Responding instances are added to the bottom of the list and operation propagation always starts from the top. This improves performance because consistently visible instances work their way to the top of the list and, therefore, will be the first to be contacted when an operation is performed. 3.2 Applications Two sample applications have been built by porting third party code into the Tiamat infrastructure. The first application was the adaptation of a web client and proxy server to use Tiamat for coordination. The second, the adaptation of a fractal generator that was originally based around the provision of a load balancing server. The adaptation of the web client and proxy server, required no modification to the code of either. Around two hundred lines of supplemental code was required in

5 order to integrate the web communication with the logical tuple space. In the system clients place their identified requests into the space as tuples. The client then performs a blocking operation attempting to retrieve a response tuple with the same identifying information. Proxy servers perform blocking operations awaiting requests. When a request is placed into the space it is removed and given to a proxy server, which obtains the relevant pages, wraps them up in a tuple along with the original identifying information. The proxy server then places this tuple back into the space allowing it to be retrieved by the client. For the low cost of two hundred lines of code, the power of the web client and proxy server are greatly increased. Firstly, due to the anonymity afforded by generative communications, proxy servers can be dynamically added without the clients knowledge. This allows proxy servers to be added both for the purposes of load balancing, adding more servers to handle increases in demand, and in the case of failure, to replace the failed server. Neither of these actions is visible to, nor perturbs, the clients. Another useful feature presents itself when the client becomes disconnected. The client can still make requests even in the absence of any servers (e.g., while in between networks). Once a server becomes visible it will see the tuple (assuming the lease has not expired) and perform the necessary operation. The fractal generator gleaned much the same benefits from its adaption to the Tiamat system. The load balancing server was removed and the data producers communicated with the entities performing the calculations through the space, resulting in a decrease in the amount of code necessary. Communications were handled in a similar fashion to the web system, with masters placing identified tuples defining the calculation to be performed, and the workers attaching the same identity to the result. Once again, the number of entities performing calculations could be increased and decreased without perturbing the clients. In both sample applications, the code base was provided by an external source and adapted to use Tiamat. This required very little knowledge of the operation of the applications beyond the communication paths. In the case of the web client/proxy example, no modification was made to either the client or the proxy being used. 4 Related Work This section summarises other research into providing generative communications in distributed environments. 4.1 Linda The original Linda system [1] was designed to allow parallel processes to coordinate through the shared tuple space. While interesting from a semantic perspective the system does not consider distribution. 4.2 Commercial Systems Ts [2] and Javas [3] are two powerful, commercial, distributed generative communication platforms. Both systems offer the tuple space abstraction to devices on a client/server basis. Although the centralised nature of these two systems may not impact their usefulness in a distributed setting, it does reduce it in a pervasive environment. Due to the changeable nature of a pervasive environment, the presence of other devices for the provision of services cannot be relied upon. This means that centralised architectures, where one machine must be visible to all others, are not appropriate in a mobile environment. 4.3 L imbo imbo [4] is a distributed tuple space system designed to operate in a mobile environment. L imbo uses a Distributed (DTS) protocol to replicate tuple spaces across participating hosts. Each tuple space has its own multicast group, and clients attempt to maintain a consistent replica of the space by multicasting a copy of every operation to the group. The DTS protocol provides facilities for disconnected operation. Each tuple has a single owner associated with it. Ownership can be transferred to another client, and only to owner of a tuple may remove it from the space. While disconnected clients can perform out and rd operations as normal, but can only perform in operations on tuples it owns. The client must retain information as to which tuples were removed during its disconnection so that it can inform others to update their spaces once it reconnects. After reconnection, the client begins watching other multicast messages to determine if any tuples were placed in the space in its absence. It subsequently requests copies of any new tuples. The replication mechanism places some heavy resource constraints on the participants. In order to make use of a tuple space each client must be willing to keep its own replica of the tuple space which could place a burden on the resources available. It also modifies the semantics of the operations. In a traditional generative communication system, once a particular tuple has been removed from the space, it should not be available to any subsequent operation. This is not the case in L imbo as the tuple may still be accessible to a disconnected host or one that did not receive a particular multicast message. The concept of ownership breaks the traditional generative communications model and breaks the decouplings which give it many of its advantages. This model is no longer decoupled in identity as a client must have knowledge of the intended recipient of a tuple in order to pass on ownership. The client must also be able L

6 to communicate directly with the recipient in order to hand over ownership, breaking the time and space decoupling. In addition, in a mobile environment, ownership causes a resource management issue. If a client deposits a sizeable number of tuples in the space and then leaves, no other client can remove those tuples until that same client returns, something which may never happen. If the client does not return then the tuples will simply continue to consume resources on all of the clients participating in that space. 4.4 Lime The LIME system [5] is another attempt to provide Linda-like semantics in a mobile environment. LIME uses the concept of transiently shared tuple spaces, which are similar to the opportunistic logical spaces in Tiamat. LIME provides support for both logical mobility, in the form of mobile agents, and physical mobility of hosts. Each agent possesses its own tuple space called an Interface (ITS) which moves along with the agent. Agents located on the same host engage their tuple spaces to form a host-level space. Communicating hosts engage their tuple spaces into larger federated tuple spaces. Unlike Tiamat, LIME does not do this on an opportunistic basis, rather it tries to ensure global consistency across hosts, attempting to ensure that all hosts have identical views of the shared tuple space. While this may be feasible within a single host, or perhaps even across a small number of hosts, it is likely to prove unworkable in large networks due to large latencies. LIME also requires the space engagement and disengagement operations to be atomic across all hosts in the federated space. This means that other operations cannot proceed while hosts are engaging/disengaging which could be a problem in an environment where hosts may be coming and going rapidly, potentially causing delays in normal tuple space operation processing as the engagements/disengagements are dealt with. LIME s constrained model is not well suited to the dynamic nature of a mobile environment. This disparity between model and environment has also resulted in some implementation difficulties. Indeed, it has been reported in [6] that the prototype implementation of LIME cannot function with more than six hosts forming a single federated space. 4.5 CoreLime CoreLime is a restricted LIME variant developed in an attempt to address many of the scalability issues which LIME presents [7]. It attempts to simplify the LIME model whilst trying to maintain the semantics of the various primitives. CoreLime does not make use of federated tuple spaces. Agents still have an ITS and they can still form host-level spaces, but these are no longer permitted to form federated tuple spaces. This removes many of the global synchronisation problems which arise from trying to maintain a consistent view of the world. Operations are only allowed on local spaces, no remote communications are permitted at all. Instead, clients are expected to take advantage of mobile agents to access other hostlevel tuple spaces. If a client wants to perform an operation on a remote, host-level tuple space, it must create a new mobile agent and migrate it the desired host. Once there, the agent would engage with the host-level space, perform the operation and finally migrate back to the originating host. CoreLime removes many of the inefficiencies present in the LIME model, and still retains much of the functionality in the form of host-level tuple spaces. However, since CoreLime does not attempt to federate the tuple spaces, the burden of doing so is placed on the application developer. The application developer has to discover which tuple spaces are available, connect to them and begin making use of them. 4.6 Peers Peers [8] is a tuple space system based on JXTA, Sun Microsystems open-source peer-to-peer infrastructure. Each JXTA node contains a tuple space and reading operations are sent out in a flooding broadcast to other nodes in the network in order to find matches. While Peers does include the concept of leasing while searching the network, it is included only to ensure fault-tolerance. Apart from this and the mention of potentially adding the concept of expiration to data in the space, Peers makes no other attempts to provide any resource management features. 4.7 Comparison and Categorisation The original Linda model is designed around a single shared data space for the coordination of parallel processes. Ts and Javas provide a heavyweight server/client model in a distributed environment. Other than Tiamat, there are four approaches to supporting decentralised generative communication. L imbo replicates tuple spaces across mobile hosts resulting in the problems with inconsistency and ownership. LIME uses federated tuple spaces in order to provide global consistency which results in a system which does not scale well as the number of hosts increases and also requires explicit connection and disconnection of devices which does not suit a mobile environment. CoreLime provides host level tuple spaces but leaves the location and utilisation of remote spaces to the application developer through the provision of mobile agents. Peers provides a peer-to-peer like flooding mechanism for locating tuples in remote spaces. Tiamat provides opportunistic logical tuple spaces. Neither

7 Peers nor Tiamat attempt to provide global consistency and, as a result, are more likely to scale to allow a greater number of devices simultaneous access to resources. Tiamat also provides fine-grained resource management which is important at the implementation level in a pervasive environment as described in Section Challenges Six key challenges have been identified which must be tackled in the development of infrastructure for a pervasive environment. This section details these six challenges, explaining what each challenge is, why it is important to attempt to understand and, hopefully, overcome it and how these challenges should be approached. 5.1 Environment Driven Design The overall challenge in developing infrastructure to support pervasive computing is to ensure that the infrastructure which is designed and implemented is driven by the environment it finds itself in. Pervasive environments have potentially limitless permutations and combinations of devices, each one placing a different set of demands on the infrastructure. It is not feasible to specifically program for each and every one of these situations, rather the infrastructure which is put in place must be able to adapt itself to suit the present circumstances. Infrastructures for pervasive environments are primarily influenced by two factors. Firstly, there are the constraints imposed by the underlying Run-Time Support (RTS). The RTS encompasses any systems or services upon which the infrastructure relies for operation as well as the context in which it sits (i.e., the set of other entities in the system, their current state and accessibility). The RTS may restrict the set of resources or services which are available to a given infrastructure or the set of other devices may change as devices enter and leave the system. Secondly, there are the demands placed on the infrastructure by the applications built on top of it. These demands will vary as the behaviour of the applications change. These two driving influences, the applications from above and the RTS from below, form the operational environment for the infrastructure. In order to adapt to the environment an infrastructure must obtain information about these two influences and also know how to react appropriately as they change. This results in five further sub-challenges: obtaining information about the RTS; adapting in accordance with that information; obtaining information about the application behaviour; adapting to take account of application behaviour; and dealing with conflicts in adaptation. 5.2 Monitoring the Run-Time Support It is important to design and implement infrastructure which can obtain information regarding the nature and state of the current RTS. An infrastructure cannot adapt to changes in its environment if it does not know about them and, therefore, it is important that the infrastructure be capable of gathering information about the current environment. Before an infrastructure can gather information about the RTS, such information must be made available. It is important to identify the set of information which is pertinent to the infrastructure and to establish whether the cost of obtaining such information can be offset through subsequent use. The underlying RTS must then provide a mechanism that allows the infrastructure to obtain the information required, for example, an event based system could be utilised to inform interested infrastructures of significant changes in the environment. The infrastructure must then decide how this information should be stored or processed. For example should it be stored to allow for the identification of trends or is the current state the only point of interest? Can future behaviour be estimated through an examination of the past? The computational and storage costs of these analyses must be compared to the potential benefits when trying to determine their value. 5.3 Adapting to Change Once an infrastructure has access to information regarding the underlying RTS, it must use that information to adapt to the current situation. This should be done to ensure that the infrastructure makes better use of the limited resources that are available. The infrastructure should attempt to exploit characteristics of the underlying RTS and the set of resources it provides. For example, nodes which move around frequently could be exploited for the dissemination of information, while those that are relatively fixed could be used as temporary data stores. 5.4 Modelling Application Behaviour The developed infrastructure must also be capable of obtaining information about, and constructing models of, different behaviours exhibited by the applications. Again, this challenge is driven by the fact that adaptation cannot occur without information. This modelling of application behaviour may come at run time, through monitoring of such things as: what operations the application performs; when and in what order these operations are performed; and whether the previous operations succeeded or failed. Alternatively, the information may be provided through either automatic or manual static analysis. The former situation is similar to the understanding of the RTS and the same set of questions arise: what should

8 be monitored; how should it be monitored; and should the information be retained or discarded? It is important to identify the correct set of information and determine which information should be used for each individual infrastructure. The latter source of information is a more general computing science problem. Application developers often do not have a clear picture of how their application will behave once it is deployed. This is particularly true in the case of decentralised architectures where complicated global behaviours can develop out of simple local behaviours, making it difficult for the application developer to accurately communicate such information. 5.5 Adapting to Application Behaviour Once an infrastructure is capable of modelling the behaviour of the applications, through whatever mechanism, it must begin to make use of that information to adapt, in order to attempt to make better use of the resources available to the infrastructure. Behavioural information can be used to establish resource allocation strategies, for example, caching behaviour, which better suit the application. Policy decisions within the infrastructure could also be made on a more informed basis. The infrastructure may also be able to preempt certain operations or problems through prediction of future application behaviour. This would allow the infrastructure to reduce the impact such problems might have by preparing for them in advance. 5.6 Resolving Conflict in Adaptation The final challenge is learning how to identify and deal with conflict arising from the separate sets of demands being placed on the infrastructure. This is important as there will be times when the demands of the applications are in discord with each other or with the constraints imposed by the RTS. In these situations, the infrastructure must attempt to resolve the conflict in an appropriate manner. The identification of the conflict will vary from the obvious, such as lack of a required resource, to the subtle, such as aggressive applications causing data starvation to others. For the various possible conflicts, the infrastructure must be able to notice their occurrence. This may be possible through direct means, such as trapping refused requests for a resource, or through indirect means, such as noticing a large number of failed operations or some degradation in the performance of the system. As well as the mechanisms for identification, the infrastructure should also be provided with the appropriate mechanisms for resolving such conflicts. Due to the large number of conflicts which may arise, it may be desirable to have an infrastructure make a best guess as to what the appropriate resolution might be, and then allow it to monitor the situation so that the decision can be reversed if things get worse. 6 Future Work Future work on the Tiamat system will focus on the monitoring and adaptation as a result of changes to the run-time support as described in Sections 5.2 and 5.3. The Tiamat system will be extended to examine each instance s position in the network as well as the set of other instances which are visible. The social characteristics of the instances may be exploited to provide a routing mechanism in Tiamat. Tiamat will also attempt to exploit the relatively fixed and well connected portions of the network as a backbone for more efficient communications. 7 Summary In this paper we have introduced Tiamat, a flexible infrastructure for supporting coordination in a pervasive environment. The Tiamat system has been designed around the environment rather than imposed upon the environment. This has resulted in a model and system more suited to a mobile, pervasive environment. This in turn provides application developers with a flexible, yet powerful infrastructure which provides them with a simple abstraction over the network and underlying changes in the system. A working implementation of the Tiamat model has been constructed along with applications to demonstrate its functionality. Six critical challenges have also been identified, which must be addressed in the construction of infrastructure for pervasive environments. We have described how we will extend the Tiamat system in order to examine approaches to two of these challenges. References [1] David Gelernter. Generative Communication in Linda. ACM ToPLaS, 7(1):80 112, January [2] P. Wyckoff, S. McLaughry, T. Lehman, and D. Ford. T spaces. IBM Systems Journal, 37(3): [3] J. Waldo et al. Java Specification Technical report, Sun Microsystems, March [4] Nigel Davies, Adrian Friday, Stephen Wade, and Gordon Blair. L imbo: A Distributed Systems Platform for Mobile Computing. MONET, 3(2): , August [5] Gian Pietro Picco, Amy L. Murphy, and Gruia-Catalin Roman. LIME: Linda Meets Mobility. In Proceedings of ICSE 99, pages ACM Press, May [6] Bogdan Carbunar, Marco Tulio Valente, and Jan Vitek. Lime revisited. In Mobile Agents 2001, LNCS [7] Bogdan Carbunar, Marco Tulio Valente, and Jan Vitek. CoreLime: A Coordination Model for Mobile Agents. In ConCoord 2001, Lipari, Italy, July [8] N. Busi, C. Manfredini, A. Montresor, and G. Zavattaro. Peers: Datadriven Coordination in Peer-to-Peer Networks. In SAC 03. ACM Press, 2003.