國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
with delivery tag should place into a synchronize block as the critical section to prevent the duplicated data issue. This mechanism increase the successful probability of message delivery and gives the potential for verifying data correctness.
The minimum requirement of queue implementation should follow the competing con-sumers pattern and guarantees that a message is delivered at least once. It’s nice to have other properties like high availability and fault tolerance. Our implementation adapts RabbitMQ [30] as the data provider since it follows AMQP model and features with non-blocking operations.
5.3 Fault Correction
The mechanism of spreading duplication to different devices increases the successful prob-ability of message delivery and give the potential for fault correction especially on checking the corrupt data and crowdsourcing correction. Condorcet’s jury theorem provide a simple solution that the majority group performs better than any selection of superior individual under the assumption that the probability of making the right judgment is greater than 0.5 for every member in jury.
Instead of dropping out the redundant result with the same delivery tag, task manager could collect them into a small group and check by the result of each other. This alter-native approach could apply to task rely on human judgment or sniff out the malicious computing node by sampling.
6 Computing Node
In order to take leverage of computation power on mobile phone among the world, Gnafuy framework offers an app for users to install. As soon as the app starts running, it enters the initial state and communicates with specific control center to ask for the next instruction.
Once the control center receives the request from computing node, it would start to diagnose the condition of computing node and assign tasks to the app accordingly. This approach makes smartphones to contribute its computing power as a cloud service provider
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
while running the Gnafuy app. The Gnafuy app would maintain a state machine to imply the computing node what to do next. There are 4 states inside the state machine:
• Library Required
• Task Required
• Data Required
• Stop
Specifically speaking, when the state machine turns to a new state, computing node would check the current condition, send a HTTP request to control center after it finishes preparing the prerequisite of the next state, and then wait for the instruction of the next step. The name of the state implies which resource computing nodes desire for, and the flow reveals in algorithm 3 and figure 2. Algorithm 3 states the mechanism we sealed in the computing node is composed by a global dictionary and an infinite loop. For every iteration, the computing node takes an activity from the dictionary according to current state then sends a request via the retrieved activity. To be brief, the term dictionary here is a key/value hash table structure. The key is the activity status code and the value is the activity instance. These activities basically abide by the same interface which has the ability to send a request and create the activity for next state according to the response. The exact flow of each activity would be: 1. Collect required information. 2.
Send request to control center. 3. Create an activity then put into global dictionary. The iteration continues until control center changes the state to stop which is the only way to stop this infinite loop. Another thing that needs to be mentioned here is that algorithm 3 must be placed into AsyncTask or Service provided by Android sdk since Android would raise NetworkOnMainThreadException if main thread program tries to send request or performs network communication. Android apps run by default on the main thread, also called the UI thread which handles all the user input as well as the output so it designs to avoid time-consuming operations on the main thread to prevent UI freeze and to have a better user experience. Gnafuy itself relies on lots of network communication to retrieve
‧
Figure 2: A brief view of state machine in the computing node
task or data to accomplish distributed computing so we create an AsyncTask then launch Ganfuy’s state machine inside. Listing 1 demonstrates activity which requires library Algorithm 3 State Machine of Ganfuy Computing Node
1: activityT able ← anEmptyDictionary
2: currentState ← libraryRequired
3: activityT able[currentState] ← libraryRequiredActivity
4: while currentState 6= stop do
5: nextActivity ← activityT able[currentState]
6: currentState ← nextActivity.execute()
7: end while
information from control center. Each activity follows the contract of GnafuyStateActivity interface which implies the execute method must return an instance of the same interface for the next round.
Listing 3: class LibraryRequiredActivity
public class LibraryRequiredActivity implements GnafuyStateActivity {
@Override
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
6.1 Job Loading
The goal we want to achieve here is to encapsulate developers’ predefined library as a response and send back to mobile phone when the computing node required. With the library and reflection mechanism provided by the programming language of the platform, each computing node could invoke corresponding instances and execute methods accord-ingly. Though we could invoke arbitrary methods with proper hints, Gnafuy forces users to follow some programming pattern such as map and flatMap which is mentioned at the previous chapter in order to limit the domain of input/output types and keep the code structure clear.
As the computing node of Gnafuy framework, we aim to perform the implementation on mobile phones on the Android Platform. By narrowing down the target platform, the task deployment could be simplified as "How to load/reload classes at runtime in Java."
since the Android SDK is written in Java-like language. Meanwhile, Java Reflection provides the following feature:
• Classes inspecting at runtime
• Instance invoking at runtime
• Dynamic Class Loading / Reloading
With the ability of dynamic class loading and instance invoking at runtime, we could load classes outside the JVM and invoke an instance without knowing its type at runtime.
The following Java sample code reveals the idea of dynamic loading in Android.
Another issue we have to mention here is that Android runs on Dalvik VM or Android Runtime instead of JVM because the bytecode generated by Java is not compatible with Dalvik VM at all. Therefore, we have to convert developers’ predefined Java bytecode to dex file before performing the runtime loading technique. Fortunately, Android-sdk provides some tools for converting Java bytecode to Dalvik bytecode that meets our re-quirement. Finally, for the purpose of loading some third party libraries from the bytecode
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
imported by the developers, the developers have to make sure all the dependencies of pre-defined Java bytecode have been packaged into the .jar file correctly, which could be done by some project management tools like maven.
Though Gnafuy computing node’s current implementation is based on Android, it’s possible to take the same approach on other platforms which support reflection mechanism such as Swift, Objective-C and C#. Either it could be easier for task deployment if all the platforms run the same environment such as Node.js [31], and we could thus focusing on task deployment with only one programming language.