[JDEV] File transfers

[Max Metral]

I don't understand how we keep making the mistake in disputing that inband
data as opposed to peer to peer IS BAD FOR THE SERVER HOSTER!!!! NO MATTER
WHAT!!!  Whether it has user convenience features is another question, but
this IS A FACT:

	Inband data will cause an infinite amount more load on the Jabber
server (i.e. ANY) than peer to peer data.

In your first example actually it's even WORSE for the ISP because that
person is going to stay online longer. (on the margin for sure)

But in the end, I agree with your conclusion.

-----Original Message-----
From: Marco Stolpe [mailto:fireglyph at gmx.net]
Sent: Saturday, June 08, 2002 8:25 AM
To: jdev at jabber.org
Subject: Re: Re[2]: [JDEV] File transfers


On Saturday 08 June 2002 02:22, Tijl Houtbeckers wrote:
> Or clients that want to implement features that require the
> transfer of small files (like icons or sounds) without wanting to
> implement HTTP or HTTP server (after all one goal of Jabber is to
> keep things simple for the client!).

On the one hand, I'm agreeing that implementing HTTP can become 
complicated, but on the other hand, for simple file transfers one 
probably doesn't need all those highly sophisticated features of the 
HTTP protocol - even HTTP/1.0 should suffice. Almost every 
programming language provides libraries for simple HTTP GET, the 
complicated part is HTTP POST with file uploads using MIME. I don't 
know HTTP PUT, but it should be much easier to implement.

> This ofcourse still leaves the need for better p2p signaling. Best
> would be ofcourse to combine both of them, letting both clients
> indicate wich options they have and then choosing the best one
> together. Maybe some discussion on how this signalling can be done
> best is a good idea rather then argueing about wether inband is
> good or bad..

I fully agree. The question is not, *if* one should use the server 
for file transfers or not, but *in what situations* it is best to use 
inband data, depending on the capabilities/attributes of the clients 
(and the server) and the actual load(s).

Example 1: After a chat, I'd like to transfer a file to my friend, 
using DSL. He has only a 56K modem, has started three downloads and 
the network of his ISP is already on its knees. But the load on the 
jabber server is low and I wouldn't have any problems to transfer the 
file to the server. So I (or my client) uses the server. This 
solution is user-friendly, because I can go offline directly after 
transmission and my friend can first download the other three files 
and later decide to download mine. It is ISP-friendly, because I 
don't cause much traffic for my own ISP and if my friend is 
responsible enough to download the file somewhat later, it's better 
for his own ISP as well.

Example 2: We're only chatting, my friend doesn't download anything 
else. The load on the Jabber server is high, almost nothing gets 
through. It is possible for my friend to establish a direct 
connection to my client's HTTP server and download the file. In this 
case, wouldn't that be the better solution?

What I don't like about all that is:

a) Although we want to implement an IM client, we're thinking about 
problems and asking questions how to implement the most efficient 
file sharing peer-to-peer application.

b) The rules to be applied after the signaling you're talking about 
could become complicated. How far should we go? Determine them 
manually, once and for all, based on rather theoretical assumptions? 
Work on them based on empirical data gained from real networks? 
Invent a highly sophisticated algorithm based on statistics/machine 
learning which is able to adapt to changes in the network and to 
predict future network load, leading to better decisions? Wouldn't 
*that* go even far beyond HTTP, making things for clients highly 
complicated instead of keeping it simple?

I think the problem here is that with any data (let's say three 
times) bigger than the average message a user would normally send to 
another user (by using a keyboard), we're more or less leaving the 
realm of instant messaging. Though applications can *use* the Jabber 
protocol for their own instant messaging needs (p2p, a2p, a2a), also 
leaving the area of pure GUI IM clients, nevertheless the Jabber 
protocol is (and should remain, IMO) an open protocol for instant 
messaging. Everything else is file sharing and those protocols are 
fundamentally different from IM.

So either combine IM and file sharing in one app, but use different 
protocols underneath - or invoke a thirdparty app based on the URL 
the client got out-of-band, like browsers can invoke telnet when 
getting URLs like telnet://213.123.466.237 ...

Bye,
Marco
_______________________________________________
jdev mailing list
jdev at jabber.org
http://mailman.jabber.org/listinfo/jdev