[standards-jig] Pondering DTCP
thoutbeckers at splendo.com
Fri Dec 13 17:53:46 UTC 2002
David Waite <mass at akuma.org> wrote on 13-12-2002 17:49:02:
>>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
>How do you mean? HTTP P2P connections in the way that clients like
>Exodus do it now, or HTTP P2P connections like the Gnutella protocol?
There's a few reasons why DTCP is already better then the way HTTP is
being used with Jabber right now, and even as how it could be used.
Most importantly HTTP it's not asynchronous. For filetransfer this
might not be a very big issue, but for many other uses it would be. A
lot of things for filetransfer are now being doubled in the
filetransfer JEP and HTTP itself (content-types, file-sizes, and
perhaps even range, etc).
Then there's the whole NAT situation. Even with no NAT involved for an
asyncronous connection I have to open 2 sockets. When there is one peer
behind NAT I have to open two connection, one GET and one (as suggested
by others) PUT. PUT means using HTTP/1.1 wich means I MUST support
chuncked tranfer coding amongst other things.
I prefer something "overly simplified" over this solution.
Java/J2ME/GPRS Software Engineer @ Splendo
More information about the Standards