chunk-request-rotation system bug (from hydranode blog)

[bogeyman]

Found this in the Hydranode blog:

[Surround]

I rather think madcat didn't understand "request parts" and "sending parts" messages ...

With request parts, one always requests 3 parts (3 pairs of start-offset and end-offset) of a file. If one client (eMule) sends only one of those 3 parts in return, it's ok, the "send data" package will contain the start-offset and the end-offset of the range sent. If mlDonkey sends all 3 requested parts, it's ok, the "send data" package(s) will contain the start-offset and the end-offset of the range sent.

If madcat thinks he does not need to parse the start and end-offsets of the received data package, and then request chunks again, even if he already received that range, just because he relies on eMule's behavior to never send all requested data, then this is a hydranode problem, not one of mldonkey!

I remember, he already stumbled over those messages some time ago ... Oh my dear, their is so much crap out there on the net ... some clients send the 3 chunks in reversed order ... LOL ...

.. sorry, no time to check the hydranode code

It's hydranode requesting chunks twice, (if you carefully read what madcat wrote, you'll notice that!) and mldonkeys response to send the data twice is absolutly correct behaviour!

[Madcat]

There was no need to start up this discussion in the first place, because it's irrelevant. HydraNode behaviour was modeled based on my observations on how eMule's and eDonkeys behave [snippet from hydranode log], I just found it somewhat surprising that mldonkey behaved differently, then adjusted my code to compensate, and moved on.

I don't know why mules and edonkeys rotate chunks like that, and frankly, I dont care for the reasons, I just assume they have a good reason for it, just as mldonkeys have a good reason for doing it differently - and since I'm newcomer in the network, I just try to learn from how others behave, and behave the same way.

Madcat.

[Amorphous]

it just happens that mldonkey doesn't get something right.
that's the problem when a protocol has no clear and open spec.
@madcat: thx for your comment.

[Miriup]

[Amorphous]

hehe. good idea. i would like to, but it's unlikely i have enough time for such a huge job...