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: roadmap - ICE Interactive Connectivity Establishment
Date Tue, 02 Feb 2010 12:15:53 GMT
Hi Sim,

I've found an interesting Draft itef spec that discusses all the issues 
we've just been considering, they call it ICE.


    * ICE Interactive Connectivity Establishment
    * TURN Traversal Using Relay Nat
    * STUN Session Traversal Utilities for NAT


   1. http://code.google.com/apis/talk/libjingle/index.html --  Google
      code has a c++ ICE implementation with a BSD license.
   2. http://www.isoc.org/tools/blogs/ietfjournal/?p=117  - good
      overview & history
   3. http://tools.ietf.org/html/draft-ietf-mmusic-ice-tcp-08
   4. http://tools.ietf.org/html/rfc4091
   5. http://tools.ietf.org/html/draft-ietf-behave-turn-16  --  This one
      is most relevant to us to begin with.
   6. http://natblaster.sourceforge.net/paper/natblaster.pdf  --
      techniques for traversing NAT with TCP peer to peer. includes a c

It looks like the relay is the most reliable but the least scalable 
option, the standard everyone seems to be working toward is try to 
obtain a peer to peer NAT traversal first, using the relay to assist 
opening the connection, then fall back on the relay if it fails.  Items 
5 and 6 appear most relevant as these allow TLS connections. However 
given our resources, we should get a working relay before we worry about 
the p2p TCP too much.

The perl code mentioned earlier uses what is termed STUN, utilising UDP, 
it is not effective on corporate NAT's where UDP is typically blocked

Here's an interesting video from a Yahoo Engineer:


Let me know what you think.



Sim IJskes - QCG wrote:
> Peter Firmstone wrote:
>>> This is not needed, a connection to a JR is on a polling basis, 
>>> initiated from the service (acting as a client from an RPC 
>>> perspective). (think XMPP, XEP-0124 BOSH).
>> Ok, so if it doesn't poll (empty packet) within a certain time, it's 
>> lease expires?
> Ah. Thats a good one. Probably. The expectance is, that the device 
> immediately starts another poll after retrieving a result. But if 
> there are processing constraints / connection interruptions and this 
> cannot be met, it should not be fatal. After a timeout, the relay 
> should stop. Or maybe after having a filled (not full) queue for a 
> certain timeout. Depending on the trust (or deployment decision) 
> between server and relay the relay could offer a receive queue with a 
> depth of more then 0. And to the client of de service-over-relay the 
> takedown-rebuild cycle should be transparant.
> Gr. Sim

View raw message