[standards-jig] Pondering DTCP

Tijl Houtbeckers thoutbeckers at splendo.com
Fri Dec 13 01:35:58 UTC 2002

Ben Schumacher <ben at blahr.com> wrote on 13-12-2002 2:19:46:
>Hash: SHA1
>Justin Karneges wrote:
>| One company I've been talking with absolutely wants peer-to-peer
>| capability, to reduce server load.  This would make their service
>similar to
>| ICQ, where thru-server messages are just a fallback.  Whether or not
>this is
>| smart is debatable, but the point is that you would not want to have 
>a | separate TCP connection scheme for chatting if you already have one
>for File
>| Transfer.  Analogous to this is IRC's DCC, which supports Chat and
>File using
>| a common base.  There is a method to my madness, I swear :)
>How does negotiating a new stream to deliver messages inbound really
>decrease server load?

What's more load on the server, negotiating a direct TCP connection 
with another peer and then sending 10.000 messages over it, or sending 
those 10.000 messages through the server? Even if it's not a real P2P 
connection but something using DTCP-relay running on the same server 
the server will still have to do less XML validating, routing, etc. 

>How does this really reduce the complexity of the

I think it's pretty safe to say it doesn't. :)

>You've stated several times over that you think that DTCP is a
>better protocol than many of its alternatives because its easier. I
>submit to you that having to introduce a whole new state machine into
>clients to figure out if you have a direct connections to another
>client, establish the new connect, check for errors, etc., 
>significantly increases the complexity of a client and goes against 
>the Jabber Way. 

I don't think Justin proposed DTCP cause for this purpose, it's just an 
example of what DTCP could be used for. Try doing this with HTTP, and 
you'll see it only get's more complex. 

If I hear all this pro-HTTP stuff I start wondering why we ever 
implemnted Jabber as it is anyway! Even Microsoft declared HTTP a dead-
end, not in the last place cause of what we've shown is possible with 

>I'm with stpeter, temas and Matthais on this one, I don't see any
>application where a new protocol is preferred over using something that
>is HTTP-based.

If you just want to play an accesible URL in your MP3 player I suggest 
you just send a URI. This won't fix all your NAT problems etc. and it's 
still not asynchronous application. 

You want uses?
- Voice/Video over IP
- Shared whiteboarding/document editing (perhaps in combination with 
sending XML through the server) - games
- distributed simulations
- anything else that's bandwith-intesive/asynchronous/binary and likes 

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

More information about the Standards mailing list