[JDEV] File transfer and Jabber

[Iain Shigeoka]

At 06:46 PM 4/22/2001 -0700, Jens Alfke 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.

I think its perfectly "legit" for client developers to approach this 
problem this way.  However,  I think in terms of scaling Jabber up as an 
overall system, this would severely limit the size of a practical Jabber 
user community.  The traffic through a Jabber server would just be too high 
if file sharing became widespread and took this approach.

I believe that if Jabber client developers want to see Jabber grow to the 
popularity of a system like AIM we need to consider what a Jabber system 
with 1 million users would look like and how to make that 
practical.  In-band file transfers are just not feasible using this 
approach. Oob file transfers must be the solution.  This allows the heavy 
bandwidth usage to be distributed and shared.  Either direct 
client-to-client or client-server-client where the server can be switched 
to some other system.

How about this for a proposal.  Define specifications for a separate oob 
server.  To make it simple to convert any web server into a compliant oob 
server, we define the system using only httpd.  It accepts file uploads 
given authentication, and allows file downloads using temporary URL 
links.  Part of the standard should be incentives to run oob servers by 
people other than Jabber.  For example, perhaps the standard defines that 
clients must download from the oob server an URL, an image file (one of say 
three types defining three standard ad size types), and the requested URL.

Clients transferring files out do the following:
----------------------------------
Client hits oob server with a standard HTML form submitted and filled out 
with standardized authentication information.

Server responds with a standard HTML page either defining login success or 
failure.
Authenticated clients use http file upload to upload the file.

Server responds with a page with the temporary URL the file obtain be 
obtained, a one time key to access the file, and a timeout value specifying 
the amount of time the URL will be valid.

Client uses Jabber to send a message to client transferring file in with 
the URL, one time key, and timeout value.


Clients transferring files in do the following
----------------------------------
Client receives jabber message with file URL, one time key, and timeout.
Client hits the oob server at the URL given, specifying the one time key as 
a cookie.  It must actually perform three downloads to be compliant:

         URL - Contains the ad html link, FILE_URL, and ad image options or 
html indicating no ad required

         AD_URL/ad_size.png or ad_size.svg - Contains the Ad image.  The 
entire and exact URL was specified in the ad image options list.

         FILE_URL/file.x - A direct link to the desired file (also obtained 
from the original URL)

The client is then required to display the ad and link it to the ad 
HTML.  The commercial aspect (ads) is there to encourage third parties to 
host oob servers.  People generous enough to donate free oob servers will 
of course have the option of not turning on ads.  The client transferring 
information out is the one that has created an account with a given oob 
server (and agreed to whatever ad system they run).  The client getting 
files doesn't need to have any oob server accounts to participate.  If you 
want to encourage file sharing, then you could reverse that so that the 
client getting files must have the oob server account, and that initial 
login is reversed (the downloading client logs in, gets the one time key, 
the uploading client uses the key as a cookie to perform the upload, then 
the downloading client uses the key and the url info to get the file).

I think its easier to envision some system like this scaling and being more 
practical from a "who's going to pay for the bandwidth" point of view.

Comments?

-iain