JDK-5100117 : Allow several TCPEndpoints in sun.rmi.transport.LiveRef
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.rmi
  • Affected Version: 1.4.2
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: linux
  • CPU: x86
  • Submitted: 2004-09-10
  • Updated: 2017-05-05
  • Resolved: 2017-05-05
Related Reports
Relates :  
JDK-4880793 - Registry bind address flexibility
Description
Name: rmT116609			Date: 09/09/2004


A DESCRIPTION OF THE REQUEST :
I have a Server called 'middle' which runs IPv4 and IPv6. I have a client called 'old' which is running only IPv4, and a client called 'new' running only IPv6. When I export a remote object on 'middle', the object gets to have one and only one TCPEndpoint in the RemoteRef. This means that the object will only work on one of the networks. It'd be really nice if the exported object would list all of addresses for 'middle' such that the clients could iterate through the TCPEndpoints until it found one that worked.

Currently, if the remote object exports the IPv4 address "10.10.10.1" and the IPv6 client gets a reference to that object, as soon as the IPv6 client  tries to execute a method on that remote object I get a "Network Unreachable" IOException thrown at me. It seems ironic that the IPv6 client can get a reference to the remote object, but then it can't actually use it.

JUSTIFICATION :
This is needed in situations where a server exports a remote object to clients that reside on multiple (and isolated) subnetworks. Two classic examples are: 1) Hybrid networks (IPv4 and IPv6),  and 2) multiple isolated segments - where 'middle' has IP addresses 10.10.10.1 and 10.10.20.1 and needs to serve up the remote objects to both/all subnets.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
When a remote object is exported, the RemoteRef would contain a list of all possible TCPEndpoints that could be used to access the server.
ACTUAL -
When a server exports a remote object, there's room for just one TCPEndpoint.

---------- BEGIN SOURCE ----------
Pick any RMI demo application. The hard part is setting up environment, which needs a server that resides on multiple (and isolated) subnetworks. The "best" example is a server that runs IPv4 and IPv6, and then using an IPv4-only client, and an IPv6-only client.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Have to manually bind an extra copy of each object within the registry with an explicit host-address. This is very cumbersome because my server has two NICs, each running IPv4 and IPv6 - 4 different addresses and thus 4 copies of the same object. This also means that my clients have to iterate through the registry, retrieve each remote object, and execute a dummy method on the remote object to bake sure it'll actually work.

I could also use the java.rmi.hostname property thing to make the exported address be the machine's name, but DNS lookup isn't guaranteed to be available.
(Incident Review ID: 302292) 
======================================================================
Comments
We won't be undertaking this level of rearchitecture of RMI. Closing as Won't Fix.
05-05-2017
EVALUATION The current specification for the serialized form of a remote stub: http://java.sun.com/j2se/1.5.0/docs/api/serialized-form.html#java.rmi.server.RemoteObject only supports a single "host string", which can be a host name or an IP address (see the descriptions for external ref types "UnicastRef" and "UnicastRef2"). Supporting multiple such host strings would require an extension to the serialized form, which would be incompatible with earlier versions. Presumably, to minimize interoperability problems in practice, its use would be restricted, at least by default, to cases when a remote object is exported with new APIs. It's not clear that we have sufficient justification for such an extension at this time. As the customer notes, perhaps the most straightforward solution to this problem currently is to use the "java.rmi.server.hostname" system property to have remote stubs contain a host name instead of an IP address, as long as the name is somehow resolvable (by DNS, local hosts file, or otherwise) to a routable address on all client machines. (Note that such a solution might benefit from RFE 5052134 or an application-level socket factory that provides equivalent behavior.) A more flexible solution would be to export the remote object with a custom RMIClientSocketFactory that ignores the supplied host value in the remotre stub and contains a list of addresses to try as part of its (serialized) state, with appropriate logic in createSocket for iterating through the addresses as necessary. Such a solution would be an extension of the approach suggested in the Evaluation of RFE 4880793 (an RFE related to this one) and in this RMI-USERS post: http://archives.java.sun.com/cgi-bin/wa?A2=ind0210&L=rmi-users&P=3115 A possible caveat to this flexible solution 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 Regarding the JDC comment of 2004-09-14: As described in the above evaluation, implementing this RFE would require a specification change, meaning that it is not possible to do for a 1.4.2_xx release, nor, given that 5.0 is final, any 5.x_xx release. ###@###.### 10/15/04 17:33 GMT
15-10-0004