JDK-4257730 : Client initiated multiplex RMI socket connectivity disabled in JDK 1.2.2
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.rmi
  • Affected Version: 1.2.2
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: solaris_2.6
  • CPU: sparc
  • Submitted: 1999-07-28
  • Updated: 2015-06-11
  • Resolved: 2000-03-14
Related Reports
Relates :  
JDK-4183204 - client-side multiplexing should be disabled
Relates :  
JDK-8087189 - RMI server-side multiplex protocol support should be removed
Description
The use of client-initiated multiplexed RMI sockets in JDK 1.2.2 using the
"simulateApplet" property appears to have been disabled in JDK 1.2.2.

This severely impacts the Sun Remote Services project as we have a requirement
to perform RMI through NAT firewalls.

This worked fine in all releases up to 1.2.2.

We need to use JDK 1.2.2 for performance (and bugfix) reasons, so dropping
back to 1.2.1 is not an option.
Comments
PUBLIC COMMENTS Client initiated multiplex RMI socket connectivity disabled in JDK 1.2.2. This severely impacts the ability of clients to perform RMI to servers behind a firewall. HTTP/CGI tunnelling is not an option because the performance is poor and there is an inherent security risk in opening up an HTTP port through the firewall.
10-06-2004
EVALUATION The behavior described in this bug report is not technically a bug. The observed behavior is a result of the fix for 4180324 in 1.2.2, which removed the ability to artifically trigger-- through unspecified means-- RMI's deprecated "multiplexing protocol", which was only intended (and feasible) for solving problems associated with using RMI on JDK 1.0.2. "sun.rmi.transport.tcp.simulateApplet" is a highly internal RMI implementation property that the implementors added only for our own debugging purposes; it has never been specified formally or otherwise, nor is it even one of the implementation-specific (sun.rmi.*) properties that we have told users how to use when they know that they are using a particular version of our implementation. In short, it is certainly not a property that any application should ever depend on using. Furthermore, RMI's existing "multiplexing protocol" was solely designed to solve a very narrow and now obselete problem: how to allow RMI applets to export remote objects in JDK 1.0.2. In particular, it was never intended to be used as a tool to help with the more general problem of RMI communication through firewalls. There are quite a few problems with using this multiplexing protocol in any situation more general than it was intended for, which would result in a rather fragile system if used in such a way. The 1.2.2 RMI implementation still supports talking this multiplexing protocol with older 1.0.2 clients. The multiplexing protocol should never need to be initiated when using the 1.1 or later implementation of RMI, but it was possible to trigger it artifically by using the "sun.rmi.transport.tcp.simulateApplet" internal debugging property until the fix for 4180324 in 1.2.2. The RMI specification does not specify the means for which use of the multiplexing protocol will be triggered beyond the 1.0.2 applet scenario for which it was designed. We urge the bug submitter to consider alternate solutions to their firewall communication mechanism that depend on publicly-specified APIs. peter.jones@East 1999-07-29 Mail from the submitter now confirms: >I did actually manage to come up with a solution in the end, >which I think is pretty much what I described to you in a >past email. > >What happens is that the RMI "server" end opens up a server socket >on a known port which acts as a control socket. When an instance >of a remote object is passed to the server, also passed are special >socket factories which know to use the control connection to pass >details back to the RMI "client" when a callback is required (the client >opens a connection to the control socket when it is initialized). adrian.colley@east 2000-03-14
14-03-2000