Future Plans
Lime is very much an ongoing project. In addition to the research goals, we have several enhancements planned. Some are in the immediate future while others involve more long-term commitments. Some of these possibilities include the following. If you want to know more about the progress which has been made on any of these projects, please contact us.
Reacting to events
The current implementation allows a user to react to the current state of
the system. In many cases, it may be useful to react to an operation being
performed on the system. For example, a user may want to watch for the
removal of a specific tuple with the in operation. One of the
nice things about this extension is that the ability to react to an event
can be implemented using the same model as reacting to state. In other
words, an event (e.g., the execution of the in operation) can
be represented as a tuple in a system-maintained tuple space. Once this is
present, the current state-based reactions can be used to provide the
semantics of reacting to an event.
Application level routing
Lime currently provides the ability to place a tuple at a specific destination. A tuple migrates to this destination when connectivity is available. In some cases, it may be useful to provide application-enhanced routing in order to get a tuple to its destination without a direct connection existing between the source and the destination. For example, Agent A writes a tuple destined for Agent C. Agent B is connected to Agent A and has some application knowledge that it will be connected with Agent C at a time before agent A. In this case, it would be useful for Agent B to take the tuple from Agent A, put it in Agent B's tuple space, and transfer it to Agent C when connectivity exists. This type of routing must be enhanced by application knowledge of connectivity patterns and should be written entirely outside of, or on top of Lime. We have begun investigating these ideas and all publications will be available online.
Security
The current version of Lime assumes that every agent which knows the name
of a tuple space can access any content in that tuple space. While the
knowledge of the name must be know, this alone does not provide any security
because of the existence and accessibility of the LimeSystem
tuple space and the ability to retrieve a tuple space name from that space.
Lime also provides a private tuple space whose contents are not visible to
any but the creating agent; however, as this does not allow any kind of
sharing, it is limited in its usefulness. We would like to add some notion
of security to Lime, either by requiring authentication prior to enabling
an agent's access to shared date, or by requiring authentication to perform
any operation such as tuple removal from a tuple space. This also
encompasses the notion of read-only tuples or tuple spaces. Accomplishing
this goal may require research into authentication in ad hoc networks where
there is no way to contact a trusted server, and trust will have to
be built incrementally as the ad hoc network grows. Some initial work was
done on this as a class project at Washington University. Details are
available upon request.
Scoping
In the current version of Lime, all hosts and agents within connectivity range will share their tuple spaces of the same name. While this is acceptable for small, ad hoc networks, as the networks grow, this may no longer be acceptable. We may want to limit the scope of sharing for security reasons, to limit the number of hosts, or to limit the distance among the connected hosts. Some work has been done in this direction by Bryan Payne. If you are interested in his results, contact the Lime authors.
Tuple Multicast and Anycast
In the current model of Lime, a tuple can specify exactly one destination. In some cases, it may be useful to specify that a copy of a tuple is to be placed with each new agent which is connected (tuple multicast). Alternately, a tuple may be moved to the first agent that matches a given criteria (tuple anycast).
Replication
Many times replication can be useful to decrease the access latency to data. In a mobile environment, replication of data can also increase access in the presence of disconnection. However, where there is replication, there is also the possibility of a replica becoming stale, and other issues of disconnected operation including the need to reconcile data opportunistically when connectivity is available.
Unannounced disconnection
One of the characteristics of many mobile environments where connectivity is through wireless mediums is the possibility of losing the connection between a pair of nodes rather suddenly. This can occur either by simply moving out of range of the devices or by moving into a, so called, dead zone (e.g., a tunnel) where connectivity is not possible. With the Group Manager, Lime has the ability to anticipate disconnection when moving out of range, but more work must be done to handle disconnections which are not able to be predicted. The main issue to address is the consistency of data that is in transit at the moment a disconnection occurs. Some initial work has been done in this area by Brian Mesh. For more details on this, please contact the Lime authors.
Ad hoc routing
One of the current assumptions in Lime is that all hosts in an ad hoc network are directly connected to one another. In other words, there is only one hop in the network between any pair of hosts. If an ad hoc networking layer that supports multicast is added to the infrastructure, this assumption can be removed from Lime. While it is not our intent to devise our own ad hoc routing protocol, as work continues in this area in the IETF Manet working group and other places, we expect it to positively affect Lime.
Weaker engagement/disengagement semantics
We would like to remove the assumption that engagement
and disengagement occur as atomic actions. In many ways this makes Lime more
amenable to the unpredictable mobile environment and more applicable to
larger networks where the serialization of each engagement and
disengagement may cripple meaningful work. The key difficulty here is in
precisely defining the new semantics and keeping the result meaningful.
This also affects the semantics of the consistency of the
LimeSystem tuple space across connected hosts.
Enhanced engagement protocols
In addition to working in the ad
hoc mobile environment, Lime also has potential in a large wide area
network. To accommodate this new environment, the weaker engagement and
disengagement protocols can also be extended with a server-based engagement
protocol. The server can either be centralized or distributed, but will
essentially allow us to remove the multicast to identify a Lime community.
By eliminating multicast as the primary mechanism to identify Lime
communities, we also allow Lime to spread beyond a single local area
network. Once these protocols are developed, they can be easily integrated
into Lime by adding a new MemberDetector to the Group
Manager.
Another direction for enhancing the engagement protocol is to implement
an algorithm to atomically engage two independent Lime communities. This
contrasts the current model in which an individual is able to join an existing
group and engagements between two groups are serialized to engage one host at
a time.