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