[ejabberd] Transfer File function - supported?

Konstantin Khomoutov flatworm at users.sourceforge.net
Mon Dec 12 18:54:37 MSK 2011


On Mon, 12 Dec 2011 07:27:07 -0800 (PST)
David Chan <chan_hok_ching at yahoo.com> wrote:

> I would like to implement photo/file sharing (much like whatsapp's
> photo sharing), between many mobile phone users. Is there any
> built-in functions/modules that I can make use of? 
> 
> E.g., Some sort of functions provided by a file server. 
> Also, it has to be scalable, i.e. be able to scale-out by adding
> cluster nodes
> 
> So, I suppose my case is an in-band scenario?
> Coz a file has to be uploaded to the server before the receiving user
> downloads it.
You seems to be greatly confused.

First, no file transfer protocol existing for XMPP has a concept of
uploading anything to the server.  In any existing protocol, a pair of
clients first performs a handshake phase which is used to settle on a
concrete protocol and the details about file transfer, and then perform
the actual transfer *between the clients*.  In any case except for
"pure peer-to-peer" transfers, the server is only involved as an entity
routing the file's data one way or another.  In other words, XMPP file
transfers do not implement store-and-forward paradigm (I think if they
do, they would not have been named "transfers" after all).

Second, "in-band" means that the file's bytes are transferred inside the
regular XML stream used by a client for conventional activity, that is,
a file is sent just as a series of <message> or <iq> stanzas.

Also note that in-band protocols are very inefficient: first, they
encode the data using base64 (+30% on the wire, not including the
conventional overhead coming from encapsulating this payload into XML
stanzas), and this "stream" of data is not really a stream as it's
multiplexed with normal stanzas with no notion of priority, so if you
have a congested link, sending a file in-band almost always will clog
exchanging the regular message/presence information.  Yet another
complication is that ejabberd instances usually have traffic shapers
configured for regular client XML streams (for good, to mitigate
certain DoS attacks).

In other words, in-band transfers look barely suitable for your case.

One addition: while I was writing this response, Badlop (one of
ejabberd devs) hinted me about the existence of a popular "jabber disk"
service [1].  This thing implement kind of "store-and-pull" approach: a
client is able to upload a file to a virtual "disk" and then give some
sort of an URL to another client, which then can use that URL to fetch
the file.  Hence it's probably worth researching.

One another thing I can think of: as you seem to be developing an
intergated solution (that is, its clients might not even be aware your
application speaks XMPP) why not just use proven highly-scalable
methods like plain HTTP[S] for file uploading/fetching?  I think if
your mobile application has Internet access to talk XMPP it should have
no problems talking HTTP[S].

1. http://dev.jabbim.cz/jdisk


More information about the ejabberd mailing list