Re: RMI & connection refused
Matt Humphrey wrote:
"EJP" <esmond.not.pitt@not.bigpond.com> wrote in message
news:dEdem.9579$ze1.7020@news-server.bigpond.net.au...
Matt Humphrey wrote:
I think what you're saying is that the stub includes the dynamic port
number.
The stub includes the dynamic port number.
Would you think
that because the stub and instance are produced automatically (I don't
use rmic and there are no stub / skeleton classfiles), it seems that if
the client should be able to produce the stub itself and fill-in the
externally declared host and port number?
No. The client has no way to learn the dynamic port number, and even if it
did it still doesn't know the other stuff in the stub such as the UUID of
the remote object.
The RMI Registry and the Activation system provide the only practical
bootstraps.
(i) basically means using a shared directory + serialization instead of
the Registry. It's not all that practical, and given that the RMI Registry
exists why would you use anything else?
The question I was answering was how to manage the port numbers so one need
open only those on the firewall, which is complicated with dynamic ports.
I am pretty sure that the design of RMI and the way it uses dynamic ports dates
back to the use of dynamic ports in ONC/RPC (which was also developed by Sun
for NFS).
The idea behind using dynamic ports is that it gets over some limitations
associated with static ports. The first problem is whether to use a low
numbered port (<1024) or a high port. Low ports carry with them some additional
security because they can normally only be opened by applications with elevated
permissions, e.g. root on UNIX/Linux or administrator rights on Windows. This
means the the client can be more trusting of the server, but the server must be
started by a superuser account. There are also a very limited number of low
ports, and unless you get your port number accepted by IANA as a reserved port
there's a good chance you'll find some other service camped on your port.
Alternatively, if you try to use a fixed high numbered port you are into the
realms of hope - hope that the port you want to use hasn't already been
assigned as a random port to some other process. Generally there is no way to
reserve high numbered ports for your application, you just have to try to open
the port and hope for the best.
The second problem with static ports is that if the server crashes there's a
good chance that the port will end up in the TIMED_WAIT state and the server
won't be able to restart because the port is still in use. You may be able to
get around this if you can set the SO_REUSEADDR socket option, but that will
just open another can of worms.
So, ideally what you want is to be able use dynamic, high-numbered ports. But
how does your client know where your server is? This is where
portmapper/rmiregistry come in. When the server starts, and is assigned its
random port, it registers itself with portmapper/rmiregistry saying what
service it offers and on what port that service is available. When the client
wants to avail itself of a service it contacts portmapper/rmiregistry and
discovers where that service is located.
This setup allows you to run servers which don't need to be run by an account
with elevated privilege (hence reducing the security implications), listening
on any available port, and all for the cost of one single fixed low port
number. It's your proverbial win-win situation.
And then along came firewalls...
However, the stub's port number does not have to be dynamic (RMI FAQ C.11).
The server can assign the remote object's port number to a pre-defined
value.
Unfortunately this does re-introduces one of the problems with fixed ports.
Namely the server crashing and the port still being in use so the server is
unable to restart.
The registry is still needed--I was mistaken about being able to
export the stub easily without it. Two ports would need to be opened--one
for the registry and one for the server. Just as with dynamic ports, the
client would not need to be aware of the server's port number--it needs only
the registry number. I'm testing a sample project that shows how to do
this. It's pretty easy, but if there are additional issues I havn't
considered, please let me know.
Just that one point above. If the server crashes it may not be able to restart
on the same port. Most of the time you'll be fine, but occasionally the server
will refuse to restart and you'll wonder what's gone wrong.
--
Nigel Wade