Excelsium

Member
  • Content count

    99
  • Joined

  • Last visited

Posts posted by Excelsium


  1. my solution is to disconnect manually the slow src, apex auto. connects to another :)

    Looking for something more elegant, refined, automatic :P 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.

    StrongDC++/ApexDC++ already contains feature which saves last user's download speed and when this user connects and there's no free block and user's speed is at least 5x bigger than the speed of some running chunk, it tries to replace this slow chunk(user) with the faster one.

    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

    a ) user's last download speed must be known

    b ) it still doesn't work correctly because there's condition to avoid crash and this condition also sometimes avoid replacing slow user with faster one :P

    point A can't be fixed, but there must be something done with B but I don't know what ;)

    So its difficult to build a fully functioning speed tracking feature.. I see.

    E


  2. 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


  3. 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.


  4. 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.


  5. #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.


  6. #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.


  7. #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.


  8. #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.

    just a theoretical solution nothing to be 100% fix but it is possible maybe, i just found a new connection fix for DC++ 0/699 with the sockets causing problems under windows

  9. #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.

    and you say it would be nice to have a feature to check files after they have been downloaded, this could possibly be a good feature but at the end of the day i think it is not something that will be used to much

    - 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.


  10. #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.


  11. #163: StrongDC++ technique does not allow this, DC++ does

    - You've said DC++ may change its technique so that it too does not allow downloads with corrupted temporary files to complete.

    - I've corrected #157.

    - as said in #157 the root cause(s) will probably be discovered and posted online because the amount of users experiencing the redownloading chunk problem will increase if DC++ changes its technique in the way described.

    - I also acknowledge that my techniques are completly obsolete if the root cause(s) are discovered.

    - The bug(s) is unidentified and is located somewhere in my machine (hw/sw)

    - And/Or in the latest DC++ client.

    - My technique is a workaround for that bug to download a file successfully without corruption in 1-5% of cases where I cannot with StrongDC++s segmented download technique.


  12. Reply to #161:

    DC++s method allows a download with a corrupted temporary file to complete.

    StrongDC++s method detects that the download has a corrupted temporary file and does not allow the download to complete. (Redownloads chunk ad infinitum if itself cannot repair the corrupted temporary file.)

    I will edit #157.


  13. yes, true. That's why there is a lot of "same" files with different TTH and we want to change it.

    Also DC++ wants to changes and current SVN contains also rereading last downloaded block from disk and if it's corrupted, it will be redownloaded. And there's no your solution, just a redownloading corrupted block.

    Features which may work sometimes for someone is no worth to do. I wish you finally understand it, that if you make your solution, it will only work for you and maybe one other person. And it won't work either for you always but only sometimes. When your HDD moves to corrupted place (if it's HDD error) in normal downloading, you will get corrupted file for normal downloading :)

    1. StrongDC++s segmented download technique does not allow a download with a corrupted temporary file to complete.

    2. DC++s download technique in its current state does allow a download with a corrupted temporary file to complete.

    3. If DC++s download technique is changed so that it does not allow a download with a corrupted temporary file to complete:

    3.1. The amount of users who experience the redownloading chunk problem will be increased.

    3.2. I feel several people will put effort into finding the root cause(s) of this issue (they could be software or hardware) - and post online. - Because of 3.1.

    The users could fix their problem if the root cause(s) are discovered.

    That bug iceman50 mentioned could be one of the causes.:

    just a theoretical solution nothing to be 100% fix but it is possible maybe, i just found a new connection fix for DC++ 0/699 with the sockets causing problems under windows

  14. To Zlobomir:

    - A Knife can be used to slice bread or to kill people.

    Final repost of this note:

    - Note: The majority of peers in the network use the 'unsafe' download technique 'dc++ normal mode' - it allows corruption.

    - When I run out of explanations and arguments I will indeed stop posting and refer people to my earlier replies.

    Refer to my earlier replies.


  15. But Excelsium, in terms of corrupted files nor even 99% is acceptible. It will be 99% OK with you, 98% with your peers, 95% with their peers... and will end in crap.

    1. It is accetable (to users of said circumstances) because it wastes less than the redownloading chunk ad infinitum problem. It also brings them to their destination (complete uncorrupted download).

    - Redownloading file with (95-99%+) success rate wastes less than said problem.

    2. See earlier replies. - It is only used by users that have said circumstances

    - It is already used by users that have said circumstances.

    - It is and will only be used (enabled) by users of said circumstances.

    - The only difference will be that it will be automated.

    - Users of said cirumstances who use this technique check their downloads before sharing, they dont share 'crap'.

    - Note: The majority of peers in the network use the 'unsafe' download technique 'dc++ normal mode' - it allows corruption.

    - People who think its not acceptable for users of said circumstances to use this technique can refer to this and earlier replies. rather than me reposting for infinity.


  16. The real fact is that maximum benefit can be reached by fixing hardware problems, then no switching to other methid would be needed and there would be no waste. Dot.

    Incorrect on one point: Could also be software problem as you admitted. (Outside of DC++ client).

    - Due to the exponential possibilities it would cause much waste to find the exact cause.

    - Hence my technique is a solution* hence I will automate my technique.

    * Only for users with high (95+%) success rates with my technique.

    - Unless of course its something like iceman50 pointed out - a real bug in the latest version of DC++.

    just a theoretical solution nothing to be 100% fix but it is possible maybe, i just found a new connection fix for DC++ 0/699 with the sockets causing problems under windows

  17. There's no point in adding something, because of your hardware problems, that could help sometimes to some users.

    because of your hardware problems

    - Factually incorrect: could be software.

    I see value in it because of the success rates I personally experience so I will add it (Automate it) for myself if no-one else.

    - I've seen at least a few other users that would benefit.


  18. I will never reply to this topic anymore. If you can't understand that the success rate in normal mode and other p2p clients is only a circumstance and it can behave differently for other users, than don't wait any answers from me.

    Yes it is circumstance users with this circumstance will enable my technique.

    - We already have done manually - it will be automated.