[standards-jig] A Proposal to the DTCP/JOBS/PASS madness
thoutbeckers at splendo.com
Fri Dec 13 20:50:07 UTC 2002
Jan Niehusmann <jan at gondor.com> wrote on 13-12-2002 21:33:04:
>On Fri, Dec 13, 2002 at 08:09:52PM +0100, Tijl Houtbeckers wrote:
>> I don't think you've covered the problem of establishing a generic
>> bytestream between two peers, just by providing a way to set up an
>> IPv4 socket between two peers. You should be able set up a generic
>> bytestream for filetranfser or other purposes (incl. asynchronous!)
>> regardless of wether you want to use a socket for it or not.
>As jabber itself doesn't even need IP (it may as well be implemented
>through a serial line), every attempt to implement out-of-band
>communication is condemned to fail in some situation.
>Additionally, out-of-band connections are against the basic principle
>of jabber, to have a single c2s channel and leave all the routing
>worries to the server.
>Unfortunately, real-world issues prevent the transfer of arbitrarily
>large amounts of data through the jabber servers. This is the
>fundamental reason to implement out-of-band file transfer.
>If you only have a single network connection to use, I don't see how
>you could create an out-of-band communication link at all, so you have
>to live with the bandwidth limitations the server imposes.
Well, I could think of a few out-of-band communactions on a mobile
device that could be initiated through Jabber (first to mind is
Bluetooth / WiFi). But that's not so much my point. what I've been
trying to point out through most of the discussion is that we need a
framework (a JEP) for establishing bytestreams from one peer to the
other. Wether this is done with IBB, OOB, TCP, IPv4, IPv6 or whatever
shouldn't matter. It should be a *true* generic framework.
On the basis of *that* JEP there can be other JEP's like DTCP, JOBS,
PASS, IBB, Bluetooth, Postal Pigeons, and whatever is proposed now. On
the other side there are the JEPs like filetransfer, etc.
What is being proposed here is being presented (by some) as a generic
framework but it's not, it's only generic for TCP sockets and possibly
The most needed thing besides a TCP based stream IMHO is IBB. Apart
from that a fast-unreliable method (most likely based on UDP ofcourse)
and an encrypted way of transfering. Enough possibilities for various
degrees of security should be possible in the framework.
Besides these methods there is ofcourse still room for more excentric
things like: reliable transfer over UDP for faster transfer and to
allow setting up a stream without a proxy when both parties are behind
a NAT, WiFi/Bluetooth, JXTA and postal pigeons :)
If something like this could be realised on of Jabber's real-world
weakness would become just another one of it's strengths. Judging by
the reactions on the list though I have my doubt that everyone agrees
with me on this.
Java/J2ME/GPRS Software Engineer @ Splendo
More information about the Standards