Sim IJskes - QCG wrote:
On 18-07-11 14:07, Peter Firmstone wrote:
Sim IJskes - QCG wrote:
On 10-07-11 06:37, Peter wrote:
Any suggestions, ideas or assistance is welcome.
A ServerEndpoint needs to know its external contact identity. In case
of the TcpServerEndpoint the hostname where the client needs to
connect to.
Correct, that would be the publicly visible address and port.
A ServerEndpoint behind a NAT probably has a private net address/
hostname.
Correct, clients on the net need a public address.
Where do you connect to the proxy server to fetch the external address?
It would require a custom ServerSocketFactory, so that when a Service is
exported using a ServerEndpoint, during the export process, a port is
If you take a look at TcpServerEndpoint.enumerateListenEndpoints where
the TcpEndpoint is created (or fetched) for export, where it is
serialized. You will see there that the endpoint description consists
of host, port and socketFactory.
In the TcpEndpoint this will be used to create the socket. The socket
will be created with the sf.createSocket() call, and after creation
the socket.connect(socketAddress, timeout); will be called.
This socketAddress will always be a InetSocketAddress. Do you see
opportunities to do some translation or lookup in there?
Now that is interesting, because dynamic ip addresses can change, or a
NAS can change the external port, but I'm not sure how suitable Dynamic
DNS is, there are companies on the net like www.dyndns.com who provide
such a service, but this requires setting up an account, or human
intervention. Sun's Neuromancer project had a remote reference service
which used distributed hash tables, a proxy could rediscover the
ServerEndpoint after it moved by looking up an Xuid, (similar to a
Uuid). The problem they ran into; the service and proxy needed to be
trust verified again after the connection was reestablished, but
permissions had already been granted. To make matters worse it was the
proxy itself that had to locate the ServerEndpoint.
But the question remains, could trust be established with SSLEndpoints,
the protocol, authenticates the server. In that case we might be able
to change the ip address when it moves as you're suggesting, in the
underlying sockets.
In this case the unique identity would be in a new SocketAddress
implementation, which uses an identity hash for look up, to return the
current ip and host address, which could be mutably cached but not part
of the SocketAddress's identity (equals or hashcode).
In this case if a connection times out, the Socket could lookup the
SocketAddress again, obtaining new details.
To be able to discover the network location of this id hash, the Socket
needs another reliable service to discover it. Xuid might be a suitable
candidate format.
Most network devices already have a MAC address, but that creates
privacy and machine migration issues.
Neuromancer used the Celeste Project
http://labs.oracle.com/projects/dashboard.php?id=106 to provide
distributed hash tables.
Cheers,
Peter.
