[standards-jig] Pondering DTCP

Ben Schumacher ben at blahr.com
Fri Dec 13 01:19:46 UTC 2002


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Justin Karneges wrote:
| One company I've been talking with absolutely wants peer-to-peer
messaging
| 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? How does this really reduce the complexity of the
client? 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 believe even ICQ does that anymore, as it significantly increases
the number of failure points in the system. In fact, I stopped using ICQ
long ago, because a large number of my messages were reguarly lost as a
result of poor protocol design. If you are working on contract for this
company, I would suggest you educate them on why this is a bad idea.

Regardless, even if you tried to layer both chat and file transfer over
the same connection, you're going to run into a slow of other problems,
unless you use something like BEEP. If you're sending a file via this
socket, you don't want to have to wait until its finished to send any
message across, do you? Are you planning on implementing this sort of
layering into whatever protocol you use over your TCP socket, cause I
assure you, its not going to be easy to do.

| As for arbitrary TCP tunneling, that could be used for any kind of server
| application that may want take advantage of DTCP's reverse
connections.  Say
| you are behind NAT, but wish to serve http?  or mp3 streaming?  All is
| possible.

Are you're proposing that we change the whole semantics of HTTP to
provide this ability? Or are you suggesting further complicating Jabber
clients by adding the ability to listen for incoming connections on one
socket, then pass requests across a DTCP connection to a web server?
*shudder* I don't even want to think about that. Regardless, why should
we do this when methods for this already exist. What you're suggesting
here isn't a "Direct TCP" connection anymore, but port forwarding, and
there are a number of hardware and software solutions to this problem
anymore. Jabber doesn't need to solve this problem, nor should it try.
Its already been taken care of... in fact, I believe in an earlier
thread about DTCP, you mentioned that NAT-to-NAT connections shouldn't
be a problem, because people should just configure their edge (NAT
router) to the necessary ports to their client machine. Obviously, you
are aware of this technology, so one has to wonder why you are now
proposing that we try to reinvent the wheel.

Why would I need to serve HTTP from behind a NAT? The only people who
need to do this are probably administrators, and they should have the
ability to port forward at their edge. If I'm an end user, then I just
sign up for one of the many free webhosting services (or purchase an
account with a for-pay service) and serve my pages from there.

If I wanted to stream MP3s, there is no reason I couldn't do it within
the HTTP semantics using a proxy as proposed earlier. Every MP3 player
I've ever used supports streaming from an HTTP server, so if we choose
to remake a protocol to be more HTTP like, it would only require passing
the correct URL to my MP3 player, and we're off.

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.

Cheers,

bs.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9+TWwUpoGqensAXIRAm+BAJ9R++BmHk0hOx/0BUzNeCVcidzIMwCeOPC+
R+GDPw2u1HfGJQQtFBbvJT4=
=9g5m
-----END PGP SIGNATURE-----




More information about the Standards mailing list