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.
More information about the BitTorrent