<br><br><div class="gmail_quote">On 27 March 2010 16:54, Yann Leboulanger <span dir="ltr">&lt;<a href="mailto:asterix@lagaule.org" target="_blank">asterix@lagaule.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


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

And of course XTLS has higher priority because it is slightly better defined:-)</div><div><br>-- <br>Homepage:   <a href="http://www.fantasticsid.com" target="_blank">www.fantasticsid.com</a><br>
EMAIL:         <a href="mailto:fantasticsid@fantasticsid.com" target="_blank">fantasticsid@fantasticsid.com</a>, <a href="mailto:cockneykevin@gmail.com" target="_blank">cockneykevin@gmail.com</a><br>IRC:             fantasticsid<br>

Jabber:         <a href="mailto:fantasticsid@jabber.com" target="_blank">fantasticsid@jabber.com</a><br>

</div>