Back to index
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.
- 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
- 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
- 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.
- What percentage of the "useful computers" are behind firewalls?
- Cite that would have helped: on fault tolerance, the Calypso
- 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?
Back to index