[jdev] Bytestreams fallback mechanism
stpeter at stpeter.im
Fri Dec 28 10:39:18 CST 2007
Guillaume Desmottes wrote:
> I'm working for Collabora Ltd. on the OLPC project. We developed tubes
>  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  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  proposal but it seems Spark specific.
> Xep-0041: Reliable Entity Link could do the job too but is was
That is a very old proposal, which we never seriously pursued.
> Any other solution
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the JDev