Hi Sim,
I've found an interesting Draft itef spec that discusses all the issues
we've just been considering, they call it ICE.
Terms:
* ICE Interactive Connectivity Establishment
* TURN Traversal Using Relay Nat
* STUN Session Traversal Utilities for NAT
Links:
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
implementation.
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:
http://www.youtube.com/watch?v=9MWYw0fltr0&eurl=http%3A%2F%2Fwww.voip-news.com%2Ffeature%2Ftop-voip-videos-051707%2F
Let me know what you think.
Cheers,
Peter.
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
