river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sim IJskes - QCG <...@qcg.nl>
Subject Re: Firewall traversal
Date Wed, 20 Jul 2011 08:09:49 GMT
On 19-07-11 02:35, Peter Firmstone wrote:

>> 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

My point is, if you want to be compatible with the original TcpEndpoint 
i've seen no opportunity to create a TcpServerEndpoint and have it 
proxied on a server with a public internet address. A TcpServerEndpoint 
needs to know the public hostname in advance, before the 
ServerSocketFactory is called. Even dynamic DNS lookup will fail IMHO 
because of the caching that the JavaVM does.

You need to contact the ServerEndpoint proxy before the 
ServerSocketFactory is called. One could create a factory for creating 
ServerEndpoints on a proxy, and have it delegate endpoint creation to 
the proxy (maybe not needed). IMHO The work involved in creating a 
SocketImpl is expensive, if you have to give up transparancy, better 
create a new Endpoint twin.

> 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.

It all revolves around the identity of the endpoint, and how much 
information is contained in it. In case of a TURN based solution the 
proxy server hostname should be contained in it.

I would have expected a URL based endpoint description mechanism in 
JERI. I'm not sure why not. Planned for V3 maybe?

Gr. Sim


-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397

Mime
View raw message