Simon IJskes - QCG wrote:
On 29-12-11 13:19, Peter wrote:
On 29-12-11 02:22, Peter Firmstone wrote:
3. UDT Socket communications, UDT has a 10x performance advantage
over TCP on wide area networks and can traverse NAT routers,
using
rendezvous connections (p2p not apple rendezvous) where TCP
cannot
go.
Peter, do you already have a solution for exposing a service in a nat
lan, and having a client in another nat lan connecting to it? I've
tried several prototypes for fixing this, and the major problem is
identitying the endpoint (from within the serverendpoint) in such a
way, that 2 lans can connect. Most lans run in the 192.168.1/24
adressing space. Every time i seem to end up with a strong wish to
remove the dependency on ip adressses from river.
Gr. Sim
I don't have a working solution yet, however this is roughly how it
will, when it does:
UDT multiplexes (many connections on one port), it's network address
will have a name, port and socketID, (this minimises the number of ports
a firewall must have, in the UDT java case, 1 per jvm).
Rendezvous mode is when two clients reside behind firewalls, the
protocol supports this, however both clients must try to contact each
other at the same time and it doesn't have anything to coordinate that,
this would need to be synchronised by a public third party.
UDT is based on UDP, some corporate firewall admin's block UDP packets
and it won't work on Symmetric NAT's, however it will work where UDP
STUN connections are possible (alhough it shouldn't need to use STUN).
So for example if a djinn had a public lookup service (PLS), the lookup
service would know the public address and port of it's clients NAT's.
If clients register services with the PLS, the connection will need to
be kept alive to keep the NAT port open (play with lease timeout's),
since UDT multiplexes, service proxy's may use the same NAT port that
has been opened for the registrar, using a different socketID.
It makes sense that the Registrar node could coordinate the connections.
I haven't thought about it much lately, I've been busy finishing off the
policy providers and security manager, but most resources you'll find on
the UDT websites, if you're interested, I could use some help.
Cheers,
Peter.
