[Nice] public API to get selected pair

[Youness Alaoui]

On 01/30/2013 12:54 PM, Bryce Allen wrote:
> This was not obvious to me from reading the spec, I guess because
> foundations can be the same across different components. I couldn't
> find a clear statement that they have to be unique within a single
> component, but it does seem to be implied by the rules:
> http://tools.ietf.org/html/rfc5245#section-4.1.1.3
> 
Yeah, it's not really obvious without reading the spec, and the libnice docs
don't seem to make it obvious either other than the fact that it's used as
argument in the signals, to represent a candidate.

> Our use case is adding support to the Globus GridFTP
> server (http://globus.org/toolkit/docs/latest-stable/gridftp/#gridftp)
> for direct transfers between two computers behind NATs and stateful
> firewalls. The plan for relay when ICE fails is to leverage existing
> GridFTP server infrastructure, which already has mechanisms for
> authenticating users and sending data between two network streams
> instead of from network to disk. Basically we're not using ICE at that
> point, just an application specific mechanism.
> 
> Globus GridFTP already has a UDT mode that is reasonably well tested and
> has some nice advantages over TCP. The new NAT traversal mechanism
> doesn't necessarily have to inter-operate with existing UDT servers, but
> leveraging the existing code and testing work is a big bonus.
> 
> I've done a fair bit of testing with stopping an ICE agent and
> replacing it with a UDT connection. The interval between packets to
> maintain the firewall/NAT session is at most Ta + UDT setup time, which
> seems to be fine with the default 20ms in practice. I think adding
> traversal to existing applications protocols is an interesting use case
> for ICE, even if it may not have been part of the original design
> considerations. ICE is used to discover the endpoints and punch holes
> if needed, and then the existing application protocol handles
> maintaining the connection.
> 
> -Bryce

That's an interesting project! Keep me informed on how it goes. Yes, it should
work, as long as both sides know that the ice agent disappeared at some point
and was replaced by another mechanism (which itself keeps the connection alive
somehow).
Most of the time, when we wanted to add NAT traversal to an application without
having to port it entirely to libnice, it was just easier to have a wrapper
application on top of it which will make the ICE connection, create a local
listening socket on both sides, and make the target application connect to
127.0.0.1 and automatically proxy anything from/to that local socket into/from
libnice. It works fine that way, although it's not the cleanest of solutions :)



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/nice/attachments/20130131/a1ba31f2/attachment.pgp>