NAT, RMI, -Djava.rmi.server.hostname, is there a client solution instead?
843793Oct 25 2006 — edited Feb 18 2007NAT=Network Address Translation.
Problem: Using RMI. The java.rmi.server.hostname directive is used on the server side when NAT'ing of the ip-addresses between client and server occur. Problem is that I can have several NAT'ed clients (each with different NAT address to the server) to the single RMI server. So in principle I do not know beforehand what NAT address the server gets on the client side.
Question: Is there a client solution to the NAT problem instead of a server solution?
Details:
----------
I have a RMI server that perform the following bind:
Naming.rebind("RMI-SERVER",theServerObject);
The client perform the following lookup:
Naming.lookup("rmi://XXX.18.26.111/RMI-SERVER");
The client need to connect through a NAT router and so the ip-address is translated to YYY.4.233.101.
I get the following message:
Error in the remote invocation java.rmi.ConnectException: Connection refused to host: YYY.4.233.101; nested exception is:
java.net.ConnectException: Connection timed out: connect
To avoid the message I need, on the server side to call my server with the following directive:
-Djava.rmi.server.hostname=XXX.18.26.111
Then it works.
It appear to me that the ip-address is both used as a part of the identification of the remote object as well as to identify which server to direct my tcp/ip packages.
Problem is that IP-layer communication and the higher level protocol RMI is combined in one call.
This is why the server needs to know the NAT address used on the client side beforehand.
So if I on the client side could define the ip-address on the ip-layer and the ip-address on the RMI layer differently then a client solution to the NAT problem would exist. I could then let my server just registrate with its own local ip and let the client use the NAT address on the ip-layer and the un-NAT'ed address on the RMI layer.
Is anyone out there aware of a solution?