Java Reference
In-Depth Information
18.7 How to run on two machines
Everything so far in this chapter has used
localhost
as the host name. Doing
so has been a convenience to avoid specific host names. Additionally, the reader
can download the code from the Web Course and run it on any machine without
any manual editing required. To run the client and server as RMI was intended -
on two different hosts - requires only a few changes which we detail now.
Let's suppose that we have a host named
myserver.somewhere.com
on
which to run the server, and host
client.somewhere.com
for the client. The
RMI registry must be running on the server machine because applications are
permitted to bind only to a registry running on the same host as the applica-
tion. Since the server is running on
myserver
, the client must look up the
server on that machine instead of
localhost
. Therefore the string passed to
Naming.lookup()
must refer to
myserver.somewhere.com
rather than
localhost
.Ofcourse, the server application must be sure to bind using that
address as well - i.e. the server application should bind to its actual machine name
instead of
localhost
. The use of
localhost
works fine when the client is on
the same machine, but for a remote client, the correct server hostname is required.
The only source code change needed on the server side is to replace the
binding to
localhost
in
RMIExampleServer.java
with a binding to
myserver.somewhere.com
. The rebind line must become
Naming.rebind (
"
//
myserver.somewhere.com
:3001/rmi-example-server
"
, impl);
where we still assume that port 3001 is free. Similarly, the lookup line in
RMIExampleClient.java
must be changed to
rmi
-
example
-
server
=
(RMIExampleInterface) Naming.lookup (
"
//
myserver.somewhere.com
:3001/rmi-example-server
"
)
The server's policy file must permit outgoing network connections from the
server itself as well as incoming network connections from the anticipated client
machine. Thus the
server.policy
file must be modified to read
grant
{
permission java.net.SocketPermission
"
myserver.somewhere.com
",
"
accept, connect, resolve
"
;
permission java.net.SocketPermission
"
client.somewhere.com
",
"
accept, connect, resolve
"
;
}
;
If being so explicit in one's policy file seems too restrictive, there are ways to
write more general policies. Wild card usage is permitted in the host name, for
example. And a policy file can include a codebase to which it applies. Using
a codebase in the policy file means that only codes from that codebase will be
Search WWH ::
Custom Search