[Standards-JIG] File sharing JEP

Michal Vaner (Vorner) michal.vaner at kdemail.net
Sat Apr 8 07:34:44 UTC 2006


Dne sobota 08 duben 2006 00:45 Justin Karneges napsal(a):
> On Friday 07 April 2006 13:42, Michal Vaner (Vorner) wrote:
> > Dne pátek 07 duben 2006 18:34 Peter Saint-Andre napsal(a):
> > > 2. We never figured out a good way to do anything but file transfer
> > > (such as voice and video) using SI. Or at least I never figured it out.
> >
> > The SI is slow, because it is always relayed, therefore it was not OK for
> > it.
>
> Not true.  JEP-0065 can transfer p2p.

Sorry here, I forgot to mention when both sides are NATed, which is in most 
cases today.

> As for a way to do SI for voip, I keep bringing this up:
>   http://delta.affinix.com/specs/jep-rtsp.html
>   http://delta.affinix.com/specs/jep-media.html
>
> And I think everyone can appreciate how ridiculously simple jep-media is.
>
> Problems compared to Jingle:
>   1) No STUN.  Although that's not a reason to avoid SI.
>   2) Can't do advanced telephone-related things (emphasis on "advanced").
>
> #1 is easily resolvable..  just add STUN to JEP-65.  #2 I've never cared
> about at all.
>
> But anyway, Jingle seems to want to replace SIP, so #2 is a legitimate
> concern.  I guess we won't be using my approach. :)
>
> > > 4. It's possible we could define a Jingle transport method for SOCKS5
> > > bytestreams, thus re-using JEP-0065 (though I haven't worked out the
> > > details yet).
>
> I don't think a JEP-65 transport for Jingle would buy us very much.  It
> might help as a technical/political transition to getting rid of SI, but
> what about user-visible improvements?  I guess the question is: what can a
> Jingle negotiation bring to File Transfer that SI cannot?

I think there is one big problem with file transfers and Jingle - Jingle is 
UDP. You need to have your own* way to take care of lost packets, flow 
control and everything. You are unable to optimize the size of one packet to 
the maximum nonfragmenting size on the whole way, since you can not operate 
with most packet flags as a normal user. TCP does this all, but the problem 
is, it can not be STUNed and must be relayed trough the proxy. However, I 
think it is a bad approach to the situation using UDP for file transfers, we 
should instead want IPv6 and direct connection access for everyone.

*) Well, I count libraries here as well, since it is something that act's like 
the application's code. The TCP layer is the system itself and is a lot 
easier to use that some weird library. What you need to do when you use TCP: 
optain a socket, connect it and start sending data, without any need to care 
about how they will get there. With the library, you need to cary it with the 
application or check, if it is installed. You need to negotiate with the 
library and everything.

> Of more practical use would be an ICE transport for SI.
>
> -Justin

-- 

Ostatně soudím, že uzavřené protokoly a formáty by měly být zničeny, stejně 
jako Kartágo.

Michal Vaner (Vorner)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060408/f9a062a5/attachment.sig>


More information about the Standards mailing list