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 Fri, 22 Jul 2011 04:23:22 GMT
Sim IJskes - QCG wrote:
> On 20-07-11 14:04, Peter Firmstone wrote:
>> The Endpoint implementations I'm interested in are the SSLEndpoint's.
> The socket in the SslConnection class is connected with a 
> SocketAddress (in SslConnection.connectToSocketAddress) 
> So if you have created your own Socket with your own SocketFactory, 
> you need to do your translation in the Socket.connect(). I think you 
> need to create a SslEndpoint with a symbolic address, that does not go 
> through DNS lookup (because this is cached). The only space that has 
> enough room is the IPv6 number space. This IPv6 number could be from a 
> private net, and you could use the subaddress within this net to do a 
> lookup of some kind. But this sounds like a terrible hack to me. This 
> could solve the problem that you have to know in advance what your 
> external address will be before you start to serialize a SslEndpoint 
> from your SslServerEndpoint.
>> Because UDP is connectionless, it makes it easier for UDT to traverse
>> NAT's, but it's worth noting that UDT uses connections, congestion
>> control and retransmissions at the application level, to a NAT, it's
>> just UDP.
> Once we have solved the 'know your external address before listening' 
> problem we can tie any solution to it. (I think!)
> And if we allow for TURN based proxies, we should think about the 
> connection path for local (on the same intranet) connections.
> I still think url/uri based endpoint specification is better though. 
> Just because the specification space is bigger.

If that's your gut feel, then we should try it.

The interesting part about UDT is it binds many UDTSocket's to a single 
UDP port (DatagramSocket), so we can set up the UDP port to listen long 
before any services have been established, I still haven't got a 
complete understanding, I'm playing around with the java implementation 
at present.  A draft of the protocol is available at 

I'm thinking of creating UDTSocketAddress extending InetSocketAddress, 
which adds the udt socket id.   Multiple services, can be listening on 
the same UDP port, using different UDT sockets.

This means one computer only requires one port on a NAT for all services.

You're right about allowing for local connection paths for TURN, I 
wonder how we can tell we've got the right local subnet.



View raw message