[jdev] questions about gsoc: file transfer over jingle

Zhenchao Li cockneykevin at gmail.com
Mon Mar 29 06:17:38 CDT 2010

On 27 March 2010 16:54, Yann Leboulanger <asterix at lagaule.org> wrote:

> Zhenchao Li wrote:
> > Hi, Yann,
> >    Thanks for your reply. Now I see one big advantage of jingle really
> > is it employs much more optional transport methods. To fully utilize
> > this advanntage for file transfer, we need to implement ICE-TCP . But
> > there's the problem: AFAIK there isn't an XEP defined for ICE-TCP
> > <http://tools.ietf.org/html/draft-ietf-mmusic-ice-tcp-08>, it's a work
> > in progress. What we have is one for ICE-UDP
> > <http://xmpp.org/extensions/xep-0176.html>. But unlike voice or video
> > transmission, file transfer needs to ensure packet integrity, which
> > rules out FT using ICE-UDP only. Implementing a ICE-TCP stack requires
> > much design and careful implementation, and even sounds like another
> > gsoc project. After some search I find that the libnice library
> > implements ICE-UDP as well as a "pseudo TCP implementation"
> > <http://nice.freedesktop.org/libnice/pt03.html>. Perhaps that's one
> > viable way to transfer file?(At the risk of rewriting this transport
> > method sometime in the furture when ICE-TCP is standardized.)
> >     I've also been investigating the possibility of implementing XTLS
> > for encrypting FT streams. XTLS itself is listed as a proposal on the
> > xmpp ideas page, and we have a draft
> > <http://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption-02> and an
> > "XEP" <http://xmpp.org/extensions/inbox/jingle-xtls.html> for reference.
> > It's not quite complicated and there are some python libraries
> > available(python binding for gnutls, tlslite). Would it be a good idea
> > to add this additional feature?(After implementing and thoroughly
> > testing jingle FT).
> I don't know how far from latest version ICE-TCP and jingle-TLS are. I
> don't know if it's worth implementing that or if it will change a lot
> before standardization. Maybe some other people on the list know more
> about those specifications.
> One point is also to know what other clients support.
> Another thing I don't know is what would be best: implment ICE-TCP or
> XTLS. XTLS could be used for audio / video and FT, so yes, it's a very
> nice feature! ICE-TCP is one of the reason to switch to jingle FT, but
> it may be a bit too early to implement that?
> BTW another reason to switch to jingle is the ability to change the
> transfer method. You try socks5, you don't find a host, you fallback to
> IBB.
> --
> Yann
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________

Then it seems we need to lower the priority of pseudo TCP over ICE-UDP for
FT, since it may cause incompatibility between gajim and other clients and
also there isn't a standard to support it. Different clients might implement
TCP stack over ICE-UDP with different details, which is bad. But still it
can be an interesting and useful feature to implement. So I guess if there's
enough time we could still implement that and let FT fall back on other
standardized transport methods when pseudo TCP is not supported by the other
side. And as Justin pointed out, pseudo TCP could even be an alternative to
ICE-TCP. Assuming this, we will 1. rewrite our code for pseudo TCP when
pseudo TCP over ICE-UDP becomes something better defined, 2. add another
transport method i.e. ICE-TCP in our code when it becomes part of XMPP
standard. With the help of libnice, for the time being it all boils down to
writing well structured and flexible code for different transport methods.
And of course XTLS has higher priority because it is slightly better

Homepage:   www.fantasticsid.com
EMAIL:         fantasticsid at fantasticsid.com, cockneykevin at gmail.com
IRC:             fantasticsid
Jabber:         fantasticsid at jabber.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20100329/cddec506/attachment.htm>

More information about the JDev mailing list