Apart from `normal' hosts, many customers appear to have hosts with dynamic IP
addresses, or private IP addresses, or peculiar firewall-traversal procedures,
or incomplete/incorrect host name assignment, or any combination.
RMI and other network applications have a requirement to create "a token which can
be understood worldwide and which will, when invoked, cause a stream-type
connection to be attempted to this listening socket I have just created". This
token is then typically stringified and sent out into the blue yonder. The
complementary requirement is "here is a token I have received from Elsewhere;
create a connection to it from whereever I am".
Currently, the approaches are getsockname and connect respectively. But when
firewalls, DHCP, and bad nameservices come into play, this is insufficient, and
workarounds, while strictly the task of the network administrators in question,
are not supported by Java.
I ask that thought be given to the creation of public methods/functions which
allow a network application to ask these questions:
1. If I were to advertise the address of socket S to host A, what address would I
use?
2. If I were to advertise the address of socket S to the world, what would I use?
Also, the important flip side of this is to allow the installing sysadmin/user to
specify how these decisions are made. Configurations may reflect:
1. Use my standard hostname, always.
2. Use my IP address, always [dynamically-allocated address]
3. Use my standard hostname, but tack on an explicit domain suffix
4. Use this explicit hostname, always.
5. Reverse-lookup my IP address and use the resultant name.
6. Use my hostname when connecting to hosts matching this provided pattern,
and use something else when connecting to anywhere else. [used on gateways
which have RFC1918 nets internally and a few routeable IP addresses externally]
addresses, or private IP addresses, or peculiar firewall-traversal procedures,
or incomplete/incorrect host name assignment, or any combination.
RMI and other network applications have a requirement to create "a token which can
be understood worldwide and which will, when invoked, cause a stream-type
connection to be attempted to this listening socket I have just created". This
token is then typically stringified and sent out into the blue yonder. The
complementary requirement is "here is a token I have received from Elsewhere;
create a connection to it from whereever I am".
Currently, the approaches are getsockname and connect respectively. But when
firewalls, DHCP, and bad nameservices come into play, this is insufficient, and
workarounds, while strictly the task of the network administrators in question,
are not supported by Java.
I ask that thought be given to the creation of public methods/functions which
allow a network application to ask these questions:
1. If I were to advertise the address of socket S to host A, what address would I
use?
2. If I were to advertise the address of socket S to the world, what would I use?
Also, the important flip side of this is to allow the installing sysadmin/user to
specify how these decisions are made. Configurations may reflect:
1. Use my standard hostname, always.
2. Use my IP address, always [dynamically-allocated address]
3. Use my standard hostname, but tack on an explicit domain suffix
4. Use this explicit hostname, always.
5. Reverse-lookup my IP address and use the resultant name.
6. Use my hostname when connecting to hosts matching this provided pattern,
and use something else when connecting to anywhere else. [used on gateways
which have RFC1918 nets internally and a few routeable IP addresses externally]
- relates to
-
JDK-4115683 Remote obj may be unreachable if ref doesnt use ip or fully qualified domainName
- Resolved
-
JDK-4090972 rmi Connections fail to a Win95-computer
- Closed
-
JDK-4097947 Functionality of InetAddress.java changed in 1.1.1; hostname not fully qualified
- Closed