Re: How to remotely construct a remote object with RMI
On 07/23/2010 03:23 PM, Michal Kleczek wrote:
How do you handle client crashes? Do you want to rely on RMI DGC? Or maybe
you want to handle it explicitly.
I'm not sure I understand what you mean by client crashes -- didn't get
to that point yet. :) I will rethrow all checked exceptions to the
client, and let client handle them. For example, I have one Game object
for each game (involving 4 clients), and it's a state machine. The state
dictates which methods are allowed to be called (for example, it's
illegal to call throwCard() if the state is "bidding", and so on)
I'm yet to discover what happens when connection breaks. It's a part of
the learning process. :) But it's a simple program and the clients are
dumb (all of the heavy lifting is done on the server), so I shouldn't be
in too much trouble and it should be fairly easy to debug.
The issues like how to notify all clients that the card is played and
such are not important right now. I have some idea on how to handle that.
Is the client going to export some listener object and hand it to the server
so that it can use it for notification?
Well, that would require the client to act as server (what I want to
avoid), but if nothing else will work then that's the way it will be. I
was actually thinking of blocking the call of one client/player until
the next makes its move, and then return that next player's move, and so
on. How would that work?
continue; // bad card
played = c; // good card
played = g.checkPlayedCard(); // blocks until card from
// some other player is played
Server will make sure to report checkPlayedCard() 3 times for each
player not on turn per turn and it will be done in correct turn order
(possibly even return an ordered list or queue of all cards played in
the current trick).
This could also check for exceptions in case of client crashes. I'm just
not sure are remote calls that could block for a long time a problem for
RMI (will some kind of timeout occur?).
I think you should look at Jini (Apache River now). It has all the basic
infrastructure to handle distributed applications like this - namely:
leasing and remote events. Even better - your game would be a good candidate
to use a JavaSpace.
Thanks for the suggestion. I will certainly take a closer look at Jini
for some real projects, but I believe it could be a slight overkill for
this particular application.