RMI is convenient to use when working with complex data types.

If the work done for each call is significant, then the overhead
would be small.

And if you always let the clients initiate the connection and
your server are not behind a firewall or behind a firewall that
you control, then you should not get any problems.

Arne

RMI is good at some things.

* Sending a graph of (serializable) objects to another client for  
processing - quite easy.
* Getting a progress bar to show you how far along your universe is as it  
is uploading - remarkably frustrating.

Tracking down errors in a client side app is a bit tricky too. You might  
keep in mind that each "block" has 3 states:

* new
* pending
* complete

If a client takes a new block, it moves into the pending queue. If  
something is still in the pending state, you may need to periodically poll  
those clients to make sure they are really still working, and haven't  
crashed.

Also note with a remote queue, you may also need to implement an ACK when  
a block is received. Consider:

public interface BlockQueue extends java.rmi.Remote {
  public Block poll() throws RemoteException;
}

In this case, your local BlockQueue might complete the poll(), but  
transmission of the Block can still throw an exception. Thus, the server  
has removed a block, but the client never receives it.

On the plus side, with RMI you can use a RMIClassLoader. If developers can  
contribute new classes to your Universe, then (in theory), rendering  
clients could dynamically discover & load the new classes from the server.

RMI is really tricky with firewalls, though. Every exported object has  
it's endpoint set by the host, instead of inheriting the route the client  
used to reach the object. If the host of a remote object is behind a NAT,  
you must tack on a
-Djava.rmi.server.hostname=(NAT address)
onto the JVM's startup command line.

As for UPnP, some Java APIs exist, but I don't know what their maturity is.

HTH,

-Zig