NAUSEA - Tasks: task #4868, Make the server parallel
You are not allowed to post comments on this tracker with your current authentication level.
task #4868: Make the server parallel
Submitter: | Luca Saiu <positrone> | ||
Submitted: | Wed 26 Oct 2005 09:46:42 PM UTC | ||
Should Start On: | Tue 25 Oct 2005 10:00:00 PM UTC | Should be Finished on: | Tue 25 Oct 2005 10:00:00 PM UTC |
Category: | World Server | Priority: | 1 - Later |
Status: | None | Assigned to: | None |
Percent Complete: | 0% | Open/Closed: | Open |
Difficulty: | Very hard |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
CC list is empty
No changes have been made to this item
Powered by Savane 3.13-f8d8.
Corresponding source code
We have not seen this happening yet, but I think that for complex worlds the server workload can become too high. It would be nice to automatically distribute the workload among several machines, (maybe, but not necessarily, assuming a very fast connection among them).
I, personally, am definitely against explicit user-expressed communications among server hosts. NAUSEA is an high-level system and I think it should remain so. Inter-server-hosts communication must happen automatically when needed.
This is an extremely complex task. It requires the ability of freezing (part of) the status of the Scheme interpreter, transfering it into another machine, and then resuming; all of this without stopping the simulation.
Clients should not be able to tell that a load-balancing happened, and just continue communicating with their interface to the server. This part will be easy to implement when we have proxies.
Our worlds have a structure which lends itself to data-parallel parallelization, but until now we have only exploited this structure to optimize collisions. We can also use it for parallel computation.
I think it's acceptable to make some assumptions about timing. Of course making the server computation model synchronous would allow us to perfectly preserve the semantics of the sequential case, but at the cost of totally killing performance. I think we can afford to make the parallel semantics just approximate the sequential semantics.