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@peopl| | | epchq.com> | | | Sent by: | | | jdev-admin@jabber| | | .org | | | | | | | | | 06/08/2002 10:11 | | | AM | | | Please respond to| | | jdev | | | | |---------+----------------------------> >-------------------------------------------------------------------------------------------------------------------------------| | | | To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> | | 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:[EMAIL PROTECTED]] Sent: Saturday, June 08, 2002 8:25 AM To: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
