[JDEV] File transfer and Jabber

[Jens Alfke]

On Sunday, April 22, 2001, at 09:52 AM, Rob Kooper wrote:

> Since we already have the whole connection system in jabber I was 
> thinking
> of when I want to transfer a file, I'll send it to the server that I am
> connected to and send the file as chunks (size and rate depending on
> flowcontrol parameters).

In-band file transfer seems to be a somewhat controversial topic. I 
brought it up a few weeks ago and several people objected to sending all 
that data through the server. It is, however, by far the most 
straightforward solution to firewall and NAT issues.

> The server can then either collect the chunks till
> all data is received, and then send the chunks to the receiving user 
> (after
> first asking for its flow control parameters).
> [...] The flowcontrol I am talking about will contain the size of the 
> packet to
> send and the time between packets.

I think it would be a lot simpler if the transfer were driven by the 
recipient. First off, because that user should be able to decide whether 
to receive any of the file at all. Then, if desired, the receiving 
client can send <iq> queries to the sender's client to receive chunks of 
the file data; each query includes the file/resource name, possibly an 
authenticating 'cookie' provided by the sender, and a byte range to 
receive. There's no need for explicit flow control because the receiving 
client only requests chunks as fast as it can receive them.

There's no need for any special server support at all. All that's going 
on is two clients sending special <iq> queries and responses to each 
other. Purely a matter for client developers to standardize and 
implement.

Other notes:
• File sharing can be an extension of this, where the provider 
advertises (via a namespace in its public server-side storage?) what 
files are available, then other clients use the same queries to request 
chunks.
• The chunk size should be limited to some reasonable amount like 32k 
since each chunk locks up the sender's/receiver's connection. Plus, XML 
parsers may barf on huge elements.
•  This also allows for out-of-order downloads: for example, some older 
QuickTime movies include the header info at the end, so to stream such a 
movie the receiving client might want to ask for the last few kbytes of 
the file first.
• It would still be nice if the sender/receiver could negotiate whether 
a direct P2P file transfer is possible, since this will always be more 
efficient.

Thoughts?

--Jens
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2540 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20010422/623ae31c/attachment-0002.bin>