[standards-jig] Pondering DTCP
thoutbeckers at splendo.com
Thu Dec 12 23:31:49 UTC 2002
[wrapped a few responses into one message]
Thomas Muldowney <temas at box5.net> wrote on 12-12-2002 20:42:32:
>Well I've long been pondering DTCP and it's relation to what we
>generally use now in Jabber, HTTP. I think it's important to note that
>I don't mean HTTP as the WWW, I mean HTTP as a solid protocol. I'm
>failing to find a reason that we are abandoning HTTP in favor or
>something else that is overly simplified.
HTTP is a solid protocol. But not for everything. The same reason for
not using it with Jabber apply to not using it with for P2P connections.
Peter Saint-Andre <stpeter at jabber.org> wrote on 12-12-2002 23:58:06:
>These are not uses, they are features. What real-world applications
>would these be used for? For example, would direct exchange of XML be
>used for real-time document editing or SVG rendering or something like
>that (and if so, why could we not do that by passing the XML through
>the server, is there something special about such applications that
>makes peer-to-peer necessary)?
I'd call a chess program a use (though it's not the first use I'd think
of, since if I'd implement a Jabber Chess game I'd rather make it a
but think of the advantages:
- Not having the restrictions of Karma
- Lower latency
This goes for both XML as binary data.
Apperently admins are quite scared of datatraffic, so not getting your
namespace blocked on the server is another advantage.
> And what are the real-world uses for TCP
>tunneling? File transfer I understand (though I still prefer scp-ing
>something to my web server and sending someone a URL), but these other
>potential uses are rather nebulous to me.
Filetransfer is one use, but surtenly not the only application that
send binary data over a socket is it? Since filetranfers is not
asynchronous, so it can be easily done through HTTP. Add a bunch of NAT
stuff and it starts to get harder (you'll have to use PUT etc.). Then
replace filetransfer with something asynchronous (for example, giving
remote assistance to a user using RFB) and you'll see that HTTP doesn't
Matthias Wimmer <m at tthias.net> wrote on 12-12-2002 22:05:29:
>As long as we don't have an other use of DTCP then file transfer we
>can't specify requirements (and don't need the protocol).
I think the reason why we don't see many uses of such things right now
it cause they're no standard for it yet. Compare it to pub-sub. We need
something like Jid-Link that can supply applications with the means of
setting up different kind of P2P connections: reliable, encrypted
reliable, and fast unreliable in all situations.
IMHO there are three "main" features:
One: clients should be able to do efficient relaible asynchronous
realtime IP datatransfer in a situation where 1 or less of the peers is
behind NAT, regardless of who initializes the connection. This is
enough to implement most of the different uses (like filetransfer, RFB,
Two: A way of doing asynchronous fast unreliable IP datatransfer
between 2 peers (most likely UDP based) for things like sending video
Three: Inband binary data (not really P2P in most aspects), for clients
limited to one socket, etc.
I'm not saying all clients should support all 3, but there should well
defined defined standards for these 3 and most of the effort should be
put into them. Notice that nowhere here I am saying people should be
able to transfer files over 2 or 3, or send videostreams over 1 or 3.
I'm just suggesting that this is the stuff that should be well
supported, for example the libraries outthere.
Note that negotiating wich method should be used should *not* be
specified in eg. the Filetransfer JEP, but that this should be a
seperate layer (a la Jid-Link), else we'll have to reinvent the wheel
each time we want to do P2P data.
All other things, like using UDP to tunnel a reliable connection
between two peers behind a NAT, PASS, relay DTCP, HTTP-Proxy, etc. can
have it's uses for client, but it's unreasonable to expect others to
It's great if I can use SuperHyperClientX to send files to another user
of SuperHyperClientX when we're both behind a NAT gateway using UDP,
but if you want to send a file to Joe Client don't expect him to
Java/J2ME/GPRS Software Engineer @ Splendo
More information about the Standards