| 1 | ---------------------------------------------------------------------- |
|---|
| 2 | P2P job management infrastructure |
|---|
| 3 | Michael McLennan (mmclennan@purdue.edu) |
|---|
| 4 | ====================================================================== |
|---|
| 5 | Copyright (c) 2004-2012 HUBzero Foundation, LLC |
|---|
| 6 | ====================================================================== |
|---|
| 7 | |
|---|
| 8 | The files in this directory form the basis for a peer-to-peer |
|---|
| 9 | job management infrastructure. The basic idea is that a client |
|---|
| 10 | connects to a network of workers, asks for bids on a series of |
|---|
| 11 | jobs it wants to execute, and then farms the jobs out to the |
|---|
| 12 | workers and collects the results. In addition to the client |
|---|
| 13 | and the workers, there are "authority" servers that act like |
|---|
| 14 | superpeers, helping clients/workers find each other and manage |
|---|
| 15 | the transfer of points for completed jobs. |
|---|
| 16 | |
|---|
| 17 | TO RUN THE DEMO: |
|---|
| 18 | |
|---|
| 19 | $ wish test.tcl |
|---|
| 20 | |
|---|
| 21 | Press the "Start" button to launch an authority server and a |
|---|
| 22 | series of workers. Press the "Reload" button after that to |
|---|
| 23 | load log information from the workers as they run. Press |
|---|
| 24 | "Stop" to kill all processes and load the final log information |
|---|
| 25 | for visualization. |
|---|
| 26 | |
|---|
| 27 | Use the "<" and ">" buttons at the bottom to move forward/backward |
|---|
| 28 | through time, visualizing the communication traffic and the P2P |
|---|
| 29 | network formation. Use the slider to jump quickly to a specific |
|---|
| 30 | point in time. |
|---|
| 31 | |
|---|
| 32 | |
|---|
| 33 | CLASSES: |
|---|
| 34 | Handler ... Basis of all servers and clients. Knows how to |
|---|
| 35 | receive and interpret Tcl-based commands. Has a |
|---|
| 36 | notion of various "protocols" which are collections |
|---|
| 37 | of messages that can be received and understood. |
|---|
| 38 | Protocols can be versioned, so each handler should |
|---|
| 39 | be able to support new and old clients if the protocol |
|---|
| 40 | changes over time. |
|---|
| 41 | |
|---|
| 42 | Server .... Derived class based on Handler. Sits at a particular |
|---|
| 43 | port and listens for client connections. The first |
|---|
| 44 | message any client should send defines the protocol, |
|---|
| 45 | and then the client sends Tcl-based commands after |
|---|
| 46 | that. |
|---|
| 47 | |
|---|
| 48 | Client .... Derived class based on Handler. Opens a socket to a |
|---|
| 49 | particular host:port and begins sending/receiving |
|---|
| 50 | messages. The first message that it sends should |
|---|
| 51 | define the protocol for outgoing messages, and the |
|---|
| 52 | first message it receives should define the protocol |
|---|
| 53 | for incoming messages. |
|---|
