[standards-jig] Pondering DTCP
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:
>-----BEGIN PGP SIGNED MESSAGE-----
>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
>| ICQ, where thru-server messages are just a fallback. Whether or not
>| 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
>| Transfer. Analogous to this is IRC's DCC, which supports Chat and
>| 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
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
Java/J2ME/GPRS Software Engineer @ Splendo
More information about the Standards