[standards-jig] Pondering DTCP

Tijl Houtbeckers 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 
>>connections. 
>>
>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.

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




More information about the Standards mailing list