So I guess that by putting my local IP address in the server, in the place of myhost would be alright, correct?
(well then I have to start the server and its registry I guess)
After that I think I've got to run the client, from a different DOS console, with different CLASSPATH, so that it would download the remote class and not get it from the variable.
You can have the server program start up the registry itself ... it is one extra line in your program, and it makes everything so much easier. Look at the class.
The alternative is to run a stand alone registry, in which case you need to start it in a separate window before you start your server.
If you start the registry in the same directory as your server code, it will look for the stub classes it needs in the directory it starts from, which will make your life a bit easier.
If you start the registry in a different directory (one with no classes), then it will not know where to get the stub classes from, and it will complain when you try and bind your server. To get around this you will have to specify a codebase to tell the rmiregistry where your stubs are.
But you do not need to download the stubs ... if the stubs are in the client's class path (or jar file) then it will not attempt to download them from the server.
Most people here recommend providing the stubs in the client jar file, rather than downloading the stubs.
Downloading stubs is fine and can be desirable (and is essential when downloading a serialized class).
But think about the command line you have to enter if you want to have downloadable stubs. It will end up with a definition like the one you showed earlier:
Not very user friendly, and just typing that out can be error prone.
You can set this programmatically, which saves the user from trying to type it out, but it means more coding for you, especially trying to code it so that it works no matter where your code is moved to.
The other aspect is that if you don't need it, then you can save bandwidth by not downloading the stubs, which in turn can mean a faster start up time (although neither issue should concern us with this assignment). I am not sure if worrying about bandwidth savings is even an issue in real life ... if bandwidth was likely to be an issue, I would pull out RMI altogether and use sockets.
For testing the "Unreferenced" code (used for handling client crashes) I programmatically change the lease value to around 15 seconds rather than waiting the normal 20 minutes for Java to tell me that my code is unreferenced.
I noticed in the code example from Habibi's book: It actually starts the RMI registry from the client. I thought the RMI registry would always be on the server side.
What do you mean by "unreferenced code"?
Bad timing - Max is away this week, otherwise I would have liked to hear his comments.
But personally I cannot see how this would work. You need the RMI Registry running in order for the server to register with it. Starting it from the client makes no sense to me.
Ooops - jumped ahead of myself. java.rmi.server.Unreferenced is part of one solution to the following problem:
What happens if your client locks a record, then crashes sometiime before unlocking the record? If only the client that locked the record can unlock it then you are in trouble - no one else can unlock it.
I shouldnt have raised this issue before you started thinking about it, because now I have indicated my solution before you started thinking about it yourself. Sorry about that.
I would probably try something like a locking timeout.
I'm a inexperienced programmer already having some trouble to understand all of that. Thus I'll try to keep it as simple as possible