no there is not. at least not around the reask. i just reviewed the code the other day. as a matter of fact do we use the official GetTimeUntilReask function. SX should in fact be slower because we use SourceCache which buffers sources we received in excess for a while. CreateSrcInfoPacket is unmodified for the most part, the only changes done are required to work with the ICS code but are fine. IsSourceRequestAllowed has also a number of changes but all of them conclude with the statement "return false;" which means we certainly do not ask earlier, rather later. the one only change that might cause faster reasks is in SetDownloadState where I readded the below code. note that this is still official code which was removed in 0.49a or b that i needed to readd to stop swapped sources to be stuck for 20 minutes:
case DS_NONEEDEDPARTS:
// Since tcp asks never sets reask time if the result is DS_NONEEDEDPARTS
// If we set this, we will not reask for that file until some time has passed.
SetLastAskedTime();
//DontSwapTo(reqfile);
//MORPH START - Changed by Stulle, Ensure we reset m_dwLastTriedToConnect for A4AF and more
//Note: I don't know why but this code is required for Morph... some more research may show why but I am not up for that right now.
default:
switch( m_nDownloadState )
{
case DS_WAITCALLBACK:
case DS_WAITCALLBACKKAD:
break;
default:
m_dwLastTriedToConnect = ::GetTickCount()-20*60*1000;
break;
}
break;
//MORPH END - Changed by Stulle, Ensure we reset m_dwLastTriedToConnect for A4AF and more
}
if (reqfile){
did i miss anything? btw, i figured out why it was required when i dug deeper into it at a later time. turns out we set download state to NNP, which will reset dwLastTriedToConnect. then we swap the source to another file and if this was successful hope that the download continues for another file. not resetting this variable, however would stop eMule from sending AskForDownload so we timed out because we never sent the DownloadCancel opcode and never sent a new block request, either.
anyhow, i would also like to point out - AGAIN - that there is no proof provided that any of the clients marked as bad are indeed legit MorphXT clients. as of now there exist at least two leecher mods which are based on MorphXT and still bear that name! all we do have is James' word for that and i really don't think any of that is quite sufficient. you, Wiz, pointed it out yourself, there is just not enough information!
reading your last post, James, also shows that you don't understand how the fakes are detected. Wiz or zz_fly had the idea that we could detect fake mods if they suggest they were, say, MorphXT but did not send the name attached to the nick, which is mandatory for these clients. this will not catch bad mods based on MorphXT - in this case - but only bad clients with custom modstring where users set MorphXT as the modstring, while nothing is added to the nick. however, this is only done by few stupid leechers, as usually the leechers adjusted to this practice and started sending the name tag, too. other fakes may be nick or mod thieves, i figure. IMO, there is no other way to identify any client as bad, unless you probably know which protocol extensions should be sent but are not. i doubt, however, that wiz went to the extent of checking this because this requires updates once it changes.
wiz, as for the chunks, IIRC this could also happen when disabling full chunks in official, given another client is able to accumulate enough score to exceed the client in upload. anyway, it would be interesting to see how much clients do actually suffer from this. as a matter of fact will the queue turn over quicker due to the shorter upload transfers. so the disadvantage they gain from being kicked earlier might just as well balanced by the next transfer which starts quicker.
This post has been edited by Stulle: 24 June 2010 - 09:02 AM