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
http://udt.sourceforge.net/doc/draft-gg-udt-03.txt
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.
Cheers,
Peter.
