Intelligent Chunk Selection - Diverse Parts For Rare Files
#1
Posted 13 April 2007 - 05:02 AM
Guess it would improve downloading of rare files, if they are requested by more than one user.
User A has a complete copy of the file.
The file is requested by users B and C.
Please make e-Mule force user B download chunks of the file different from user C, and vice versa.
It would allow users B and C using each outher as an additional seed for missing chunks.
(read about Intelligent Chunk Selection, but does not work as described here for my eMule 0.47c)
#2
Posted 13 April 2007 - 05:40 AM
mik1, on Apr 12 2007, 10:02 PM, said:
Quote
Math is delicious!
MmMm! Mauna Loa Milk Chocolate Toffee Macadamias are little drops of Heaven ^_^
Si vis pacem, para bellum DIE SPAMMERS DIE!
#3
Posted 14 April 2007 - 09:18 AM
mik1, on Apr 13 2007, 07:02 AM, said:
Guess it would improve downloading of rare files, if they are requested by more than one user.
User A has a complete copy of the file.
The file is requested by users B and C.
Please make e-Mule force user B download chunks of the file different from user C, and vice versa.
It would allow users B and C using each outher as an additional seed for missing chunks.
(read about Intelligent Chunk Selection, but does not work as described here for my eMule 0.47c)
I agree, but I think eMule already does it like this?
At least it's how its explained in the "User Made Guide and FAQs" - "Why are my downloads so slow", under the heading "A basic overview of the ED2K network" http://www.emule-pro...p;rm=show_topic
(*sigh* It's almost longer to explain where it is than to quoute it)
I'm no expert though, it could be its just a random (but needed) chunk that gets uploaded. Which would also work, but somewhat less efficient I guess.
#4
Posted 14 April 2007 - 04:57 PM
#5
Posted 14 April 2007 - 05:12 PM
nobody1000, on Apr 14 2007, 09:57 AM, said:
#6
Posted 16 April 2007 - 05:41 AM
cafebean, on Apr 14 2007, 10:12 AM, said:
Math is delicious!
MmMm! Mauna Loa Milk Chocolate Toffee Macadamias are little drops of Heaven ^_^
Si vis pacem, para bellum DIE SPAMMERS DIE!
#7
Posted 16 April 2007 - 03:07 PM
/zz
This post has been edited by zz: 16 April 2007 - 03:07 PM
#8
Posted 16 April 2007 - 08:03 PM
cafebean, on Apr 14 2007, 10:12 AM, said:
Unfortualelly you didn't understand me. I was depicting situation when 10 clients were downloading the same file simultaniously and asking for exactly the same chunk from the middle of shared file even if all parts were available for them download and they had no parts at all by themselves.
#9
Posted 16 April 2007 - 09:24 PM
nobody1000, on Apr 16 2007, 01:03 PM, said:
#10
Posted 17 April 2007 - 01:33 PM
#11
Posted 17 April 2007 - 04:52 PM
nobody1000, on Apr 17 2007, 06:33 AM, said:
#12
Posted 26 April 2007 - 02:03 PM
#13
Posted 12 June 2008 - 01:35 PM
First of all i want to say i have no knowledge about how code works. So, just asking a small question ;
What is the chunk choosing differences between official eMule and some mods with ICS(intelligent chunk selection) feature ?
Regards.
This post has been edited by omeringen: 08 May 2010 - 07:16 PM
#14
Posted 08 May 2010 - 07:28 PM
There is another two topics about it;
More Intelligent Chunk Selection
[patch] Intelligent Chunk Selection As in enkeyDEV.5 mod
The "patch" topic is very old, maybe there is some changes, i am not sure. . .
My question still stands. Sometimes eMule is becoming real dummy about chunk selection. And you know some of the mods have Sotn feature to get over it while releasing. And most of them have ICS feature. . . This subject has been talked about for a long time at mods section, so let's continue here.
Why there is no ICS at official client ?
This post has been edited by omeringen: 08 May 2010 - 07:37 PM
#15
Posted 11 May 2010 - 07:23 AM
omeringen, on 08 May 2010 - 10:28 PM, said:
enkeyDEV code contains a fault (preview chunks priority logic is reversed), as well as questionable code for chunks selection mod from current client (we're downloading from) based on all chunks not just those it holds, resulted in a bit complex ICS implementations map :
1. MorphXT and derived - if download preview chunks first is selected ICS is bypassed (official logic is used) until those chunks are downloaded.
2. eMuleFuture (< 1/0) and derived (perhaps even additional mods) - if download preview chunks first is selected they are likely to be downloaded very late.
3. AcKroNiC, SharkX & zBOOM (frozen project) - preview chunks priority logic as well as chunks selection mod are fixed.
As far as I know there are complementary code implementations (named differently and perhaps with small changes) which try to reveal information about hidden chunks (by SOTN / HideOS) via history of chunks requests by clients - if they were not sources (1'st full sources of files, or in other words this info is gathered if these clients requested chunks from us). This info is used by ICS to determine selection mod (according to chunks "rareness"). This info can be used (and is) also by anti leecher mechanism for detecting suspicious clients (clients asking for chunks they seem to poses).
Quote
It might have to do with SOTN (& HideOS) hiding chunks messing ICS functioning (due to improper figuring of chunks "rareness"). Perhaps revised SOTN (that won't hide chunks from ICS identified clients - which can be detected via handshake protocol) will increase official devs motivation to consider replacing official chunk selection to ICS (or an alike).
This post has been edited by taz-me: 11 May 2010 - 07:27 AM
#16
Posted 11 May 2010 - 02:57 PM
This post has been edited by omeringen: 11 May 2010 - 03:03 PM
#17
Posted 11 May 2010 - 03:24 PM
1. For old (<= 0.50a) official clients : SOTN might be "doing good".
2. For ICS (or for that matter : all "smart" / "advanced" chunk selection) clients - current SOTN is messing up accurate chunk status, thus damaging.
To reduce further damage to ICS based clients, newer versions of mods with SOTN must make sure not to hide chunks from clients with ICS (can be identified via protocol handshake). Usage of current implementation of SOTN in new versions of mods reduces the chances of official client migrating to ICS ...
#18
Posted 12 May 2010 - 05:59 AM
Part hiding features are not the point here. . . I am sure that all the coders would remove Sotn/hideOS features if official client have had ICS, because there will be no need to use them.
This post has been edited by omeringen: 12 May 2010 - 06:00 AM
#19
Posted 12 May 2010 - 11:11 AM
BTW: it's taz (always was, is, will be), since it's taken here (likely by myself however at the time my email was at a former employer and password probably gone ...).
This post has been edited by taz-me: 13 May 2010 - 05:46 AM
#20
Posted 13 May 2010 - 12:44 AM
For slot control only, currently recommending: Tombstone Xtended 1.0 (or higher) if you absolutely must have slot control
Quote