[jdev] Bytestreams fallback mechanism

[Guillaume Desmottes]

Le vendredi 28 décembre 2007 à 09:39 -0700, Peter Saint-Andre a écrit :
> > Tubes are currently implemented in Gabble (XMPP) and Salut (XMPP link
> > local). See [2] if you are interested about the XMPP protocol.
> > Stream tubes use stream initiation 
> 
> By which I assume you mean XEP-0095.
> 

Exactly.

> > to establish their connections. For
> > now, only IBB is implemented in Gabble which is not very efficient. So
> > we'd like to add real p2p connections as OOB 
> 
> By OOB we usually mean XEP-0066. I don't think that gives you a real p2p 
> connection, though -- it's just a way to share a URI.

By OOB I usually mean "a direct p2p connection".
I started an implementation of this using XEP-0066 and URI of this form:
"x-tcp://<my-ip>:<port>"
That's probably a kind of abuse of XEP-0066 but that can easily do the
job.

Of course, that will only work if the joiner can reach initiator's IP
(and so are probably on the same network) but that's not a too bad
assumption for most of the OLPC use cases.

> It seems to me that you really want XEP-0065, where the initiator acts 
> as a streamhost.
> 
> > and, later, use Jingle
> > magic to perform NAT penetration.
> 
> I'm working on the Jingle ICE-UDP spec at the moment, and I think that 
> would give you what you need (at least I think it would -- your 
> requirements are not fully clear to me).
> 

Great.
Requirements are basically "establish a p2p TCP connections using NAT
penetration if needed and IBB as fallback".

> > In order to always use the "better" bytestream, we'd like to do
> > something like that:
> > a) Try normal OOB using a direct TCP connection
> 
> What do you mean by "normal OOB"? I don't think that XEP-0066 will solve 
> very many problems for you.

I mean XEP-0066 using x-tcp:// as URI.

> > b) Try OOB with NAT penetration
> 
> What do you mean by "OOB with NAT penetration"? As far as I know, there 
> is no such thing (XEP-0066 doesn't give you any NAT traversal).
> 

Right. I mean "establish a p2p connection using Jingle for NAT
traversal".
Sorry for the confusion.

> > c) Give up and use IBB
> 
> IBB does seem like a good fallback in many cases (at least we concluded 
> so for file transfer).
> 
> > Does XMPP have a standardised way to do that?
> 
> Stream initiation (XEP-0095) does not support fallbacks, renegotiation, 
> etc. That's one of the reasons we worked on Jingle.

So Jingle should be the new way to go when trying to establish
bytestreams?
I don't know a lot about Jingle. Is it design to become a replacement of
SI (XEP-009)?

> > Any other solution 
> 
> Jingle?
> 
> > or should we define our own protocol to do that?
> 
> Well of course you can define your own protocol, but I would bet that 
> other people are interested in similar functionality, so it might be 
> more productive to see if you can use Jingle and if not what gaps we 
> need to fill in Jingle so that it would work for you.

We definitely want to use standardised protocols as much as possible and
will be happy to contribute to them if needed.

> For example, perhaps we need a way to more seamlessly include things 
> like SOCKS5 Bytestreams and IBB as options in a Jingle negotiation (or 
> include Jingle as an option in a stream initiation negotiation, e.g. for 
> file transfer). We talked about that back in August or September, but I 
> have not yet documented how that might work.

This sounds very interesting and would probably solve some of our
problems. Any XEP draft referring about this?


Thanks a lot for your help


	G.

-- 
Guillaume Desmottes <cass at skynet.be>
Jabber <cassidy at jabber.belnet.be>
GPG 1024D/711E31B1 | 1B5A 1BA8 11AA F0F1 2169  E28A AC55 8671 711E 31B1