From the UDT website http://udt.sourceforge.net


         UDT: Breaking the Data Transfer Bottleneck

   UDT is a reliable UDP based application level data transport
   protocol for distributed data intensive applications over wide area
   high-speed networks. UDT uses UDP to transfer bulk data with its own
   reliability control and congestion control mechanisms. The new
   protocol can transfer data at a much higher speed than TCP does. UDT
   is also a highly configurable framework that can accommodate various
   congestion control algorithms.

The main attraction for me, is by using existing UDP channels, it's much easier to traverse firewalls. UDP is a connectionless protocol. Additional performance may be obtained by using UDT in preference to TCP over wide area networks when NAT traversal isn't required.

NAT is used to share a public IP address among a number of privately addressed network computers.

Computer (A) behind a NAT can send data to the internet, the NAT re writes packet headers, a remote computer (B) can respond, the response packets are returned to computer (A) by the NAT.

If a River installation resides on a box in a private network behind a firewall and exports a service, and a proxy for this service is at some point obtained by a client residing outside the the private network, then that remote client cannot contact the service, unless a port is opened on the firewall and redirects packets to the service.

To cut a long story short, a service needs a port opened on a firewall, providing a way for external clients to contact it.

This can be done in the following ways:

  1. Configuring the firewall manually.
  2. NAT-PMP (If supported by NAT gateway)
     http://tools.ietf.org/html/draft-cheshire-nat-pmp-03
  3. UPnP IGD (If supported by NAT gateway)
  4. STUN http://tools.ietf.org/html/rfc5389

The limitation with NAT-PMP and UPnP is, they must be supported and enabled on a router but cannot be used for multi layer router network topographies.

The STUN protocol allows a network node residing behind a firewall to discover it's public port on a firewall and to keep it open by connecting to a public STUN server. Publicly accessible STUN servers are available on the internet. STUN doesn't succeed in all cases. Publicly accessible TURN servers, available on the internet, provide a method of relaying packets when STUN doesn't work.

Work on NAT Traversal is more mature and less complex for UDP than TCP, see http://tools.ietf.org/html/draft-ietf-mmusic-ice-tcp-14#appendix-A

It should be recognised that any connection obtained using these methods is not secure, STUN could misinform a client of it's public address to perform a substitution attack, a TURN server could perform a man in the middle attack. These network connections should only be used with secure Endpoints, utilising cryptographic authentication.

A ServerSocketFactory could be designed to perform the necessary steps to open a firewall port, discover public address, port and keep the connection open.

Cheers,

Peter.

Reply via email to