[standards-jig] Pondering DTCP

Tijl Houtbeckers 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 
cut it. 

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 
implement it. 

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 
support that. 

Tijl Houtbeckers
Java/J2ME/GPRS Software Engineer @ Splendo
The Netherlands

More information about the Standards mailing list