Excelsium

Looking for something more elegant, refined, automatic Lol Not sure if my full point came across.. I see some riddles about cars..: If the known fastest sources slots are taken then in the special case the user needs the last chunk of a download then grant the user an extra slot - if there is a fast source and the fast source has that chunk... of course. I see... but perhaps when 'it tries to replace this slow chunk(user) with the faster one' it could ask for permission to use the 'reserved for sending last chunk slot'... only in that circumstance of course and of course if the fast source has the required chunk, there is a known fast source etc. But So its difficult to build a fully functioning speed tracking feature.. I see. E

Hi.. Problem: - File 99% downloaded. - Downloads last chunk(s) from slow source(s). - Last 1% takes longer than first 99% (exaggeration). -- Sometimes there is no 'fast' source available. Solution?: - Track speed of sources. - One of the fastest sources grants extra temporary slot to user who needs the last 1%/chunk(s) of his download. - Maybe bandwidth prioritization for that slot. Is this practical? Maybe this is already implemented somewhere? E

why would you want to do that :)

yea.. It must not become more difficult/time/resource consuming to share or the long tail will be cut short :> DC is great in those areas.

Theres files on DC that cannot be found with BT. Also has communities BT does not have. Have to use both :>. Therefore the idea is interesting. But still need to have some kind of hubs 'Virtual' or 'Real' centralized ones. because of the communities and rare files that brings.

Results of testing. 0.2.2. Corrupt temporary files are repaired with 1 chunk redownload - havn

Hi, Just a small question

If the file is popular then there will be many sharing and many slots available to get that file. I think in the future upload slots per user will increase if segmented downloading is used by more users to counteract the problem of not enough slots which causes delay in obtaining the file, nothing more. If the file is not popular then theres probably nothing any one can do to speed up the download. -Amount of users that want the file is low. -Amount of users that share the file is low.

#177: I agree partially: It is either bug(s) in hardware or software or a combination that stops 1-5% of downloads from completing* using SDC++ segmented download feature. *1-5% in my case and in several other users cases. *Percentage of failing/failed downloads may vary in other bugged machines. I think I've said this already, I'll refer to this post if I see I need to make the same reply again. Or just not reply, my reply is here . #178: Agreed. except on the title for the mod/patch/etc.

#175 see #157: 3.2. and 3.1.

#173: I believe the bugs would be very similar or the same across the affected machines Making it easy to discover the exact location in a specific machine and fix a particular machines hw /sw or combination. - If bugs cannot be discovered or fixed then my technique in its automated or semi automated form is valid for this small group of users with said circumstances. - The group may grow in size as said in #157.

#171: Agreed, my technique is only valid for me and a small group of other users with said circumstances. - That group may grow if DC++ changes its technique as said in #157 - If the exact actionable specifics are discovered to 'fix the bug(s)', my technique is not valid and made obsolete. Until the exact actionable specifics to 'fix the bug(s)' are known I'll use my technique in its automated form when/if I get around to automating it.

#169: By causes I mean: The root causes of the corrupted temporary file that is beyond repair by the DC++ client. - The exact specifics of the 'bug' in which the user can take action to 'fix the bug' so they can use the segmented download technique in its current state with a 99.99999999%+ success rate. I dont believe the root causes have been proven yet - they could be hardware or software such as Windows XP. - the exact specifics have not been found. - or a combination of hw and sw bugs.

#167: I've always understood its only valid in said circumstances. correction to implemented 'automated' - its already been used by myself and others with said circumstances. - Agreed it wont be automated by you and probably not by anyone else reading this except myself - And if the root causes are discovered soon enough, not by myself either. - See #157,#164,#166 *I guess its ok if your refering to the implementation of the automation I'm done. more posts would be reffering to #157,#164,#166 etc and this one I guess. - Probably only valid for DC++ normal mode in its current state. That would be nice to deal with the small percentage of downloads that have been 'completed' but for whatever reason turn out to be a corrupt copy of the file the user tried to copy 'download' from a peer. Match TTH of just completed download to the one put in the queue. In fact that would probably go a long way to solve the problem of many TTHs for same filename - Also just corrected #157 some more.

#165: - About bittorrent: my technique is only valid in said circumstances. when the user has reliable high success rate using other methods. - The thread was never locked. - Your right, we've made our arguments.. my most relevant I feel are in #157 and #164 - Yup I may release a 'patch' if the root causes are not found... at the moment only a few would use it. - Would probably be never required if DC++ changed its technique because I feel the root causes would be discovered.