[bittorrent] Proposed Extension to Peer Protocol

Adrian Ulrich torrent at blinkenlights.ch
Sun Nov 12 14:48:21 EST 2006


Hi Alan,

 If in the meantime someone requests that piece off me, i'll just
> postphone sending them the piece until it passes a hashcheck. That will stop
> me getting banned by other peers.

At least my client would 'penalty' a peer doing something like this:
Unchoking a client but failing to send a chunk within a $long_time
isn't nice.


> Take a look at the TCP protocol. There are dozens of errorcodes for
> different events that might occur.

Your TCP/IP-Stack may have a dozens of errorcodes but TCP itself is
pretty 'dumb'.

It could send you a 'RST' or no SYN/ACK .. and even ICMP doesn't have
many error codes. Why? -> KISS.


> This is a *lot* more useful than just the connection
> vanishing on us.

But this is what a TCP implementation does: It tells you
if it could establish a connection and it will tell you after
the connection has been closed. It doesn't tell you stuff like
'We lost X packets while sending Y to Z' (Well: your kernel may know
about this, but your application doesn't)



> It would be nice to be able to figure out what does go wrong 

Ok, maybe we should start to collect some possible error codes.
IMO a 'broken data' received message isn't of much use.. but
if we are able to come up with a list of useful error codes
a new message-id could be justified.


 #1: You sent me broken data
 #2: You are a leecher (client doesn't upload enough)
 #3: .... ?


-- 
            A. Top posters
            Q. What's the most annoying thing on Usenet?



More information about the BitTorrent mailing list