Javelin

One-line summary: Coarse-grained Linda/CILK-like programming over a wide-area network of Java compute servers, with the corresponding mechanisms implemented as Java class library and the applet being the unit of work.

Overview/Main Points

• Clients submit compute requests to brokers, who in turn locate servers to run them.
• Security/privacy problems:
  • Use an intranet as target env., blah blah. (so much for global computing.)
  • Signed applets, blah blah.
  • Denial of service (or: how many server resources a particular user's task(s) should be alloewd to consume): an interesting open question, blah blah.
• Load balancing:
  • servers have asynchronous I_WANT_WORK/HERE_IS_WORK mechanism for work stealing. No policy or details are described.
  • Java class implements distributed double-ended queue: when new work arrives, push it onto your work queue; when you have cycles, dequeue from your work queue; others can steal from your work qeue.
• Fault tolerance is left to the client "in this version".
• Inter-node communication: JDatagramSocket class multiplexes inter-applet data onto a single underlying channel (UDP port, TCP conn, etc.). Does this imply that applets that explicitly communicate with other applets have to know how JDatagramSocket is implemented (so they know whether they have to do their own flow control, end-to-end acks, etc.)?
• Programming model is Linda-like.

Relevance

Flaws

• What percentage of the "useful computers" are behind firewalls?
• Cite that would have helped: on fault tolerance, the Calypso auto-resubmit stuff
• similarly, on scheduling that accounts for both server/client workload split and comm latency, the Sweb++ papers from UCSB on dynamic task chain splitting. Comm latency is likely to be a major issue in scheduling, no?