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


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
_______________________________________________

Reply via email to