YODA is a very simple system conceptually and hence may require quite a bit of programmer intuition to make optimal use of it. However, in essence, this is how YODA is expected to work.
YODA's server-side is all made up of JSP pages. EVERYTHING in YODA on the server will be a JSP page. In fact, even the problem files, binary workunits, etc. will all be sent to clients as responses to URL GET requests on our JSP pages. This is very crucial to understand how YODA will work. There wont be any active components on the server side and all processing will be client-driven passive processing. This means that we will have to allow a lot of state-maintainence functions to the server-side javabeans in order for them to process properly. We plan to use a very strong SQL backend to provide this state maintainence. All objects in YODA will be required to provide customzed serialisation methods.
The server will provide a very comprehensive user-management and problem querying interface for its UI. It will allow problems to be dynamically uploaded as jar files with specific conventions into the system. These jar files will be required to follow certain conventions (inclusion of certain xml files describing the structure, etc.). The system will then parse the jar file's contents to verify if the problem is a valid one and can be accepted by the system. If so, it will be queued into the system.
YODA clients will be daemons or services running on the background through the Java Service Wrapper. These processes will require the user to obtain a private key for himself/herself when they register to donate their computing power to YODA. This private key will be known only to that user and the server will have his/her public key. This will be used by the service for authentication whenever it will be required to communicate with the server.
The client will request the server for a new problem. The server will send it a jar file containing the classes required to solve the problem currently on top of the queue. After this, the client will request a work unit and execute the code contained in the jar file (in very high-security managed contexts) and send the output back to the server. The client may be interrupted during this processing due to machine restarts, high system load, etc. The client will be able to serialize and deserialise the state of the process under certain events to be able to keep processing.
Once the output is sent to the server, a new work unit is requested. If no work unit is remaining for this problem, the server may choose to send a new jar file to the client containing the code to solve the next problem in the queue. However, this will be done only when all clients have submitted their solutions to the previous problem and it is entirely purged from the queue. In the meantime, the client is asked to wait and attempts to reconnect to the server at regular intervals to see if it has anything worthwhile to do.
Please view the Plugin Description to see our current specifications on how a plugin for the YODA system would be writted. It also includes a sample plugin that finds approximate values of PI using Monte-Carlo techniques.
The triggering criteria, i.e., the criteria that decide when the service should solve a problem are based on the current system load. Each client will use a system-dependent native core to interact with the OS and regularly determine the current load on the CPU. Our problem solving process will then be moved up or down in its thread priority to complement this load. So if you're using a word processor, we may do more work while we may pause for a while if you suddenly begin media player. This allows a very effective utilization of the computing of the machine.
You may certainly mail us anytime about any questions regarding YODA at any time. You may visit our sarovar page to get more detailed technical information.