[bittorrent] Proposed Extension to Peer Protocol
alan.mcgovern at gmail.com
Thu Nov 9 02:59:10 EST 2006
(whoops, forgot to hit reply-to-all)
I have to say, it was never a sever problem for me, but it would make things
easier. The thing is there is no point asking another dev to look into their
source code as i already know quite a few cases where a connection would
just be dropped. The problem is i don't know which one it is that would be
causing another peer to dump me. It could be any number of things.
The reason why i decided to bring this up is that despite NUnit testing and
despite the fact that while testing in my localhost i sometimes get mass
suicide in the peers. I'm not sure what's causing it, but all the
connections will drop one after another in a very short space of time. Now i
have logged all messages i'm sending/receiving and i've looked at all of em,
but i don't see a problem with my own code. Therefore, how do i trouble
shoot this. An error message would be nice.
Another place where it would be useful in normal torrent downloading.
ErrorMessage(19) - Being disconnected because you have sent too many bad
pieces. That would be a nice stat to know because then you know you need to
force a hashcheck (or something else is going wrong).
That kinda thing.
On 11/9/06, Adrian Ulrich <torrent at blinkenlights.ch> wrote:
> Hi Alan,
> > Now, the problem is this. How do i fix my client if i don't know whats
> > wrong? Ok, i can tool my code to log each message as it sends/receives,
> > that still leaves me with the problem of knowing what exactly was
> But after completing the Handshake you'll know the PeerID (and software
> it's running). So you could ask the Author of the Client or dig into the
> sourcecode if the peer is running a Free/OpenSource client.
> I don't think it's a good idea to add extensions that will only be
> useful while developing a client (and to be honest: I haven't run into
> the same problem yet while writing my own BT-client).
> The extension would almost be useless in the 'real-world' because 95%
> of all closed connections are caused by exiting the application or
> > This message would be a standard peer message with a payload of a single
> > (or ushort if you want to conserve bandwidth). The error code in the
> > will link directly to a reason why the connection was terminated.
> Uh, please no magical error-codes. Make it easy: Text strings are the
> way to go :-) (Or maybe both, like SMTP / HTTP are doing it ...)
> I think a generic 'Message' message would be much more useful:
> <len=XX><id=Y><INT: type><INT: sequence><Message>
> type == 0 could be 'system messages/errors' / type 1 could be abused
> for Chatting between clients (-> sequence) and maybe type 2 could be
> used for spamming ;-)
> A. Top posters
> Q. What's the most annoying thing on Usenet?
> BitTorrent mailing list
> BitTorrent at lists.ibiblio.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the BitTorrent