[bittorrent] UDP

Mike Ravkine krypt at mountaincable.net
Sat Mar 26 22:40:54 EST 2005


Kenneth Porter wrote:

> --On Saturday, March 26, 2005 10:58 AM -0500 Mike Ravkine 
> <krypt at mountaincable.net> wrote:
>
>> What ack mechanism are you talking about?
>
>
> Sorry, I misspoke.
>
> I was thinking of the ordering and checksums of TCP. If you separate 
> the objectives of transmission integrity and final file content 
> integrity, then you can use small UDP transmission fragments with 
> their own transmission integrity checksum, and do your own fragment 
> reassembly in a temporary buffer. 

It seems to me like you're trying to re-invent the transmission 
integrity scheme that's already offered to us with TCP..

> You don't need to ack the sender to confirm transmission, because you 
> can always retry individual packets to any member of the swarm 
> containing that packet's content. 

How big are these packets?  The above only makes sense on a macroscopic 
level.. 256kb at least.  Within that, we DO need to confirm transmission.

> This suggests that the protocol be extended to allow request of 
> sub-fragment content, such as one can do with HTTP and FTP in 
> requesting part of the available content with an offset/length pair.
>
This adds complexity and overhead.

> There's a problem here with a malicious peer injecting bad 
> sub-fragment packets (with good transmission checksums), because it 
> becomes harder to tell which peer is corrupting your fragments. 
> Perhaps you could request packet-level checksums for the failing 
> fragment from several peers to isolate which packets were maliciously 
> corrupted, and by whom.
>
Wow, lets add even MORE complexity and overhead.  The way final content 
integrity is currently handled (at the block level), and the problem of 
transmission integrity left to the network layer is very robust.  What 
you (and others that think ditching TCP is a good idea) describe would 
not only be to inevitably re-invent the wheel, it would be detrimental 
to that robustness.

--kRYPT



More information about the BitTorrent mailing list