The coordination framework proposed by this paper is comprised of two parts:
• A coordination model that aims to support fast searching of data and low performance impact when dealing with engagement and disengagement. Moreover, it should be fault tolerant.
• A development framework that provides support for high-performance P2P network communication and a friendly programming interface.
The ideas of tuple and tuple space are retained. Data is still organized as tuples and stored in tuple spaces. However, after carefully analyzed two mobile projects I have participated in, I realized that tuples do not need to be anonymous in most cases. On the other hand, giving each tuple a name allows us to use the name as an index. Therefore, instead of pattern matching, we can apply plenty of sophisticated algorithms to optimize the performance for locating tuples.
As explained above, the heavy design of LimeSystemITS might drastically impact the system’s perfor- mance. As such, this type of design was abandoned and a light weight global object called SystemRuntime is presented instead. The SystemRuntime will only store the topology of the current system, and a list containing the names of misplaced tuples and reactive events. Observation on the projects in which I have participated shows that for a system containing 100 nodes and over 2.3 million tuples, the size of its Sys- temRuntime is only around 0.6 MB. The whole content of SystemRuntime only needs to be transferred on the network once during the initialization procedure. The SystemRuntime object will be synchronized via operation logs after that. A single operation log only costs several bytes. Synchronizing such a small amount of data is definitely a lot easier. Furthermore, instead of using complex algorithms such as PaxOS to solve the consensus problem while synchronizing the SystemRuntime, this paper invents a mechanism which is much more simple. In the design within this paper, when a node wants to synchronize the SystemRuntime, it will first retrieve 3 copies of the SystemRuntime from 3 different nodes. If the system contains less than 3 nodes,
the latest SystemRuntime will be accepted. If all of the 3 copies are exactly the same, the system will accept any of the copies instantly; otherwise if 2 copies are the same, it will accept the majority of the copies and notify the node that holds the out-of-date SystemRuntime. If they are all different than each other, it will try to retrieve more copies from more nodes until one copy is found the same as one of the retrieved copies. At this time all the relevant nodes will be notified to accept the copy. If no other node is available, then the SytemRuntime with the latest timestamp will be selected as the copy being synchronized by other nodes.
Same as LIME, tuple space is divided into 3 levels as well: Interface Tuple Space, Host Level Tuple Space, and Federated Tuple Space. Unlike LIME, once a node executes a out[λ](t) operation, tuple t will be instantly stored in the tuple spaces and its actual location will no longer be changed no matter whether its desired destination is ready or not. Once its desired destination is ready, the destination ITS will be notified to retrieve the tuple t, otherwise tuple t ’s name will be stored in SystemRuntime until its destination becomes available.
The major improvement for coordination is done by introducing the idea of consistent hashing and replica mechanism to manage the tuple and tuple spaces. Consistent hashing can significantly reduce the time cost for finding tuples and lower the impact when participating hosts connect to/disconnect from the coordination network, while the replica mechanism can greatly help with ensuring the data integrity. Moreover, consistent hashing will also help prevent hot spots in the system. Nonetheless, this paper has customized consistent hashing to make it more suitable to the mobile environment, which will be described in detail later on.
Figure 4.2: Requests and Responses Size
Besides the coordination model, this paper presents a development framework to help programmers de- velop distributed mobile applications more efficiently. Figure 4.2 shows the statistic result regarding the payload size of requests and responses. Sample data were collected from five different projects that all fo- cused on developing distributed solutions running on mobile devices. Observation of the samples reveals
that over 80 percent of the requests payload are less than 100 bytes and 90 percent of the responses are less than 300 bytes. Therefore, we need a lightweight protocol to facilitate highly efficient communication between nodes. CoAP seems to be a perfect choice, however, in that we assume the applications driven by the proposed coordination framework might run on unstable networks and should be able to support multiple P2P technologies such as Wi-Fi Direct and BLE, the UDP environment which traditional CoAP is relying on cannot be guaranteed. Thus this paper altered the CoAP protocol to make it compliant with different networking technologies. The UDP requirement is removed and a unified abstract network streaming model is designed to support communication in both Wi-Fi Direct and BLE network.