river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Firewall traversal
Date Tue, 19 Jul 2011 00:35:40 GMT
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.



View raw message