[jdev] Bytestreams fallback mechanism

[Peter Saint-Andre]

Guillaume Desmottes wrote:
> Hello,
> 
> 
> I'm working for Collabora Ltd. on the OLPC project. We developed tubes
> [1] which is a Telepathy component that allows arbitrary applications to
> communicate together through an existing IM infrastructure.
> 
> 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.

> 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.

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).

> 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.

> 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).

> 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.

> I found this [3] proposal but it seems Spark specific.
> Xep-0041: Reliable Entity Link could do the job too but is was
> retracted.

That is a very old proposal, which we never seriously pursued.

> 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.

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.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://www.jabber.org/jdev/attachments/20071228/041ab2e4/attachment-0002.bin>