Re: Arbitrary data streams in XMPP (Purpose: Desktop Screen Sharing)

On 12.02.2016 13:04, Niklas Andersson wrote:
>  What are your thoughts/comments/questions?

I was about to write "Jingle" but Matthew was faster. :) So I'm try to
elaborate a bit on that: Your abstract requirement is to establish a
session between two (or more) entities which can be used to transfer an
arbitrary bytestream. File transfers and (live) audio/video
transportation requires the same.

In those cases XMPP is typically used only as signalling protocol,
because it's relatively easy to connect entities over XMPP (even
considering firewalls, mobile links and other obstacles). But you
usually don't want to transfer a large amount of data over a pure XMPP
channel (only as last resort/fallback). Thus you only perform the
signalling and the negotiation of a bytestream session between the
entities via Jingle.

The mechanisms how the bytestream is constructed are manifold. Ideally
the entities are able to establish are direct TCP connection. But this
doesn't work (in most cases). Jingle knows a ton of alternative
mechanisms, each with their own pros and cons. For example XEP-0260
Jingle SOCKS5 or XEP-0176 Jingle ICE-UDP Transport Method.

In terms of protocol specification(s) everything required is here. But
experience of XMPP file transfers has shown that it's not easy to get a
"works always" user experience. IMHO this is mostly because the
implementations are not as good as they could/should be (and Smack is
not an exception here). But implementing the various mechanisms is not
an easy task, considering that there are many, not all are supported or
available and you have to able to fallback to (multiple) other mechanisms.

- Florian

_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [email protected]
_______________________________________________

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQF8BAEBCgBmBQJWvdEPXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMzU3QjAxODY1QjI1MDNDMTg0NTNEMjA4
Q0FDMkE5Njc4NTQ4RTM1AAoJEIysKpZ4VI4120gH/0SVSK4t3g0Ccgn4Kz0lqAaN
6a7CEFWrA1DWSLLPAoOEvNO0+/u7rMw2DFBPMNXjaH1Zbr7aHEyP0+lzDh+YrEVq
4nUlQBwAhoS6YJaFyYyn2wiTQjurO3Lqz+hn17uzXRzVKzu3JJ5sxkZz4+KEIXeJ
XQTtN+OKs91QFgBO4Kot9DbTo09f+aO7PBj61AATvI5oBf7t3Zv43UCFhdNpKlX4
X96QqBb7XvayxE1HJGzgtN6gIGNKCfyRx3QuxuYXZzohv7AeTrgomFsIju7cCk6x
K9jUUzlwxvz/g9AQ3Dl0CTnu268Ybi2soaXtJmcxH0WFa231SJ2RqeuEfmPleRA=
=qFj/
-----END PGP SIGNATURE-----