[JDEV] File transfers

[Michael F Lin]

Max, I think I have enough of an idea now of what you are looking for to
make a recommendation.

Give up on Jabber and go use SIP.

As a review, SIP, or Session Initiation Protocol, is a protocol for
establishing circuit-switched, out-of-band media sessions. SIP proxies
(servers) themselves handle only the simplest text payloads; all large
binary data is handled out of band. Originally, only call establishment,
acknowledgement, and termination messages were to have travelled in-band on
the SIP network; recent extensions have allowed simple text presence and
instant messaging services to travel in-band as well. However, there is no
expectation that large binary payloads will ever travel in-band, because
SIP is a protocol for establishing out-of-band sessions.

Based on what you are looking for, SIP should sound pretty good to you
right now. Heck, the protocol even looks a whole lot like HTTP.

I've been saying all along that negotiating firewalls in this model is a
nightmare. Well, you should be happy, because the SIP people have it all
figured out. They've worked through every last detail of running
call-stateful, location-aware proxy servers on the edge of every firewall.
They've worked through the three-phase commit algorithms needed to
negotiate the path through the network while keeping the call-stateful SIP
proxies updated. But don't think it's easy, or that it works well. Here is
a seventy-page master's degree thesis describing how it is supposed to
work.

"SIP, NAT, and Firewalls"
Fredrik Thernelius. Master's thesis, Department of Teleinformatics, Kungl
Tekniska Högskolan, May 2000.
http://www.cs.columbia.edu/sip/drafts/Ther0005_SIP.pdf

This one of the briefer documents that does a halfway decent job of
describing how SIP is supposed to work in a generalized, non-utopian world.
And that's just the basic syntax and architecture. Anything actually useful
is an extension to SIP.

In my opinion, it's a huge step backwards to the days of Ma Bell and
circuit-switched networks, and it's hopeless. Every single attempt to make
circuit switching work for digital communications - ISDN and ATM to name a
couple - have completely and utterly failed. It's just too hopelessly
complex. Oh and by the way, ISDN and ATM at least did QoS, so you at least
got something out of all that nightmarish complexity. SIP doesn't even do
that. I read the papers on SIP, and my head hurts. I cannot even comprehend
how bad it is. We're going to hose them.

Please, please, please, let's just do it in-band. It is so brainlessly
simple. The only really fundamental change to Jabber is a smarter wire
protocol that can be described in 2 pages and implemented in an hour. Yes,
it requires more work by Jabber servers. But this work is mindless
byte-shuffling. It is so much simpler, so much easier to implement, so much
more obvious. No one should be able to get a master's degree for describing
how Jabber is going to work. I don't think I could fill 70 pages on it if I
tried.

But if you still want to do stuff out of band, you should really use SIP
and save yourself a lot of trouble, because they've already tackled all the
issues that you are just beginning to understand even exist. There is no
doubt in my mind, however, that some day not too far away we will find SIP
as a call-switching technology on the overloaded shelf of terrible ideas
into which millions of dollars and thousands of man-hours have been
needlessly poured.

-Mike




|---------+---------------------------->
|         |           Max Metral       |
|         |           <Max.Metral at peopl|
|         |           epchq.com>       |
|         |           Sent by:         |
|         |           jdev-admin at jabber|
|         |           .org             |
|         |                            |
|         |                            |
|         |           06/08/2002 10:11 |
|         |           AM               |
|         |           Please respond to|
|         |           jdev             |
|         |                            |
|---------+---------------------------->
  >------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                              |
  |       To:       "'jdev at jabber.org'" <jdev at jabber.org>                                                                        |
  |       cc:                                                                                                                    |
  |       Subject:  RE: Re[2]: [JDEV] File transfers                                                                             |
  |                                                                                                                              |
  |                                                                                                                              |
  >------------------------------------------------------------------------------------------------------------------------------|



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
_______________________________________________
jdev mailing list
jdev at jabber.org
http://mailman.jabber.org/listinfo/jdev