JDK-4880793 : Registry bind address flexibility
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.rmi
  • Affected Version: 1.4.1
  • Priority: P5
  • Status: Open
  • Resolution: Unresolved
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2003-06-19
  • Updated: 2013-04-12
Related Reports
Relates :  
JDK-7076394 - Update RMI documentation to clarify that remote objects are exported to the wildcard address
Relates :  
JDK-5100117 - Allow several TCPEndpoints in sun.rmi.transport.LiveRef
Relates :  
JDK-6425769 - Allow specifying an address to bind JMX remote connector
Description
Name: rl43681			Date: 06/18/2003


A DESCRIPTION OF THE REQUEST :
Using java.rmi.registry.LocateRegistry.createRegistry(), one can only specify port, not which address to bind the registry to if multiple IP addresses/NICs are present on the system.

JUSTIFICATION :
A host has very often multiple IP addresses and it's desired to run a service like e.g. the Registry on a specified IP. In many cases one interface is for management/network internal purposes and the other interface is visible from the outside world and/or the corporate firewall.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Bind-address flexibility when creating/exporting the RIM registry (actually should ALL services ending up making network connection be flexible with regards to IP, when the calling entity is not making the socket itself).
ACTUAL -
My RMI server and RMI client runs on different hosts. The client can reach the registry, but the host the registry indicates the the looked up object is running on, is not visible from the client (it's the "wrong" IP/NIC. Seems like the Registry just picks the first in the list (same order as ipconfig /all on a win 2000 system).

(Review ID: 186935) 
======================================================================
Comments
EVALUATION There seems to be a confusion of issues in this report. By default, an RMI registry (such as one created with the LocateRegistry.createRegistry API), or any other exported remote object, receives calls on a server socket that is bound to all local network interfaces-- in IPv4 notation, for example, it is bound to the wildcard address 0.0.0.0. (This is why the client described in the report can reach the registry in order to perform a lookup.) [ It is possible to create a registry that receives calls on a server socket bound to a specific local network interface, if binding to all of them is not desired: this can be achieved by passing a custom RMIServerSocketFactory to the LocateRegistry.createRegistry method. This technique is described in the following RMI-USERS thread: http://archives.java.sun.com/cgi-bin/wa?A2=ind0306&L=rmi-users&P=1805 ] But what it seems that the customer is really seeking is a way to control the host name or IP address that gets placed in the remote stub for an exported remote object (this has nothing to do with the registry): By default, the host value placed in the remote stub for an exported remote object is the IP address of the InetAddress returned from an invocation of the InetAddress.getLocalHost method. This default can be overridden by setting the system property "java.rmi.server.hostname"-- if that system property is set, then its value is used as the host value placed in the remote stub for any exported remote objects. Its value can be either a host name (to be resolved by any calling client's name services) or a specific numeric IP address. If, for example, there is a single host name that resolves to the correct IP address for all clients (on both sides of the multi-homed machine), then the "java.rmi.server.hostname" system property should be set to that host name. (In J2SE 1.4 and beyond, the value of the "java.rmi.server.hostname" system property is resampled at every remote object export, so it is possible to export multiple remote objects in the same VM with different host values in their corresponding remote stubs.) [ For a list of system properties supported by Sun's RMI implementation, see the following pages from the J2SE RMI documentation bundle: http://java.sun.com/j2se/1.4.1/docs/guide/rmi/javarmiproperties.html http://java.sun.com/j2se/1.4.1/docs/guide/rmi/sunrmiproperties.html ] The disadvantage of using the "java.rmi.server.hostname" system property is that it is a VM-global value, and thus it is not safe for independent, concurrent use by multiple parties in the same VM. If the VM-global nature of the "java.rmi.server.hostname" system property is a problem, then the most flexible approach is to export remote objects with a custom RMIClientSocketFactory that ignores the supplied host value in the remote stub and contains its own state for determining the appropriate host to connect to. This approach is described in the following RMI-USERS post: http://archives.java.sun.com/cgi-bin/wa?A2=ind0210&L=rmi-users&P=3115 It is conceivable that support for explicitly specifying a host value could be added to the various J2SE RMI APIs for exporting remote objects (UnicastRemoteObject.exportObject, Activatable.exportObject, etc.) at some point, but basically equivalent functionality can be achieved by exporting with a custom RMIClientSocketFactory already, as described in the above-mentioned post. ###@###.### 2003-06-18 Note that a possible caveat to the flexible approach described above is that until bug 5052870 is fixed, the client-side permission requirements could be somewhat confusing, because the checkConnect performed for reused connections will be based on the standard host value in the remote stub. ###@###.### 2004-09-13
13-09-2004