Re: RMI & connection refused
Matt Humphrey wrote:
"Nigel Wade" <nmw@ion.le.ac.uk> wrote in message
news:h56vi7$kmn$1@south.jnrs.ja.net...
Matt Humphrey wrote:
If your server
happens to create additional remote objects, each will get its own port.
You
don't have to know or handle the port number, but a firewall will block
access. Similarly, remote objects instantiated on the client (RMI
callbacks) will open a server socket on the client and the server's
remote
proxy will attempt to connect to that port. Again, you don't have to
know
any of the port numbers for this to work, I'd rather not open ports on
the
client.
If you don't use the rmiregistry, and you don't know or handle the port
numbers,
how does the client determine the port number on which the server is
listening?
Sorry, I was unclear. Clients need the port number to find the top-level
server object. Remote objects instantiated within the server get dynamic
port numbers, but the client doesn't need to know them (see below). For
other instantiated remote objects and RMI callback objects, the port numbers
are managed automatically. The code below shows the basic structure (but is
otherwise uncompiled, untested, unstructured, etc.) In using Eclipse w/ Java
1.6 I don't need to invoke rmic--stubs and skeletons are handled
automatically. Just make sure all the class referenced by the client are
actually available to it. In the example below, that would be Server and
Session. ServerImpl and SessionImpl are not needed by the client.
[snip]
public static final void main (String [] args) {
LocateRegistry.createRegistry(5005 /* your port number */);
ServerImpl actualServer = new ServerImpl ();
Naming.rebind("YourServerName", actualServer );
// Wait until directed to exit
}
}
public class ClientApp {
public static final void main (String [] args) {
Server remoteServer = Naming.lookup ("//<host>:5005/YourServerName");
Session newSession = remoteServer.createSession ("my", "pw");
}
}
But surely the above code is using an RMI registry (albeit, an internal one).
Rather than register with an external rmiregistry process it creates its own
with LocateRegistry.createRegistry. The client still needs to know the port
number on which the server started this registry. The registry port and the
dynamic ports used by the registered services still need to be open in the
firewall to the client, and given service ports are dynamic in nature that
still most likely requires opening up all ports >= 1024.
From the client perspective surely this is identical to using rmiregisty, and
isn't that the entire point? All the client knows or cares is that some
registry is running on the host/port which it has been given.
--
Nigel Wade