Big Muscle

Member
  • Content count

    702
  • Joined

  • Last visited

Posts posted by Big Muscle


  1. I've noticed that large files come in smaller blocks, even if there is only one source.

    yes, it's true

    After finishing a segment, there is an idle pause before starting the next, and sometimes I get a "No slots available" message and have to wait.

    this is false. Pause is maximally 10 ms and you can't lose the slot.


  2. But actually first you removed (changed) something from (in) the client, and for this reason Strong DC++ 2.0 is incompatible with oDC, right? Hubowners did not do anything. :fear:

    no, I haven't removed anything.

    a) only simple condition has been added to disallow downloads without TTH tree

    :) change hasn't been done by me, but by DC++ developers.

    What ??

    that you are crying on a bad grave :)


  3. There is a 'chunk overlapping' function already in SDC++ witch is suppose to leave fastest sources when there is "no free block" - it disconnects slower and faster user continues his segment. I suppose it's not working perfectly since no one mention it earlier? :)

    It works perfectly... erm.. but nothing works perfectly :D:) it's just because:

    a) it works only for sources with known speed

    B) it requires that the current chunk would be downloaded below 15 seconds with new overlapping source

    c) if the source was very fast before, it can be very slow now or it doesn't have to have a slot already

    but I admit that this feature still needs some improvements especially in forcing the connection to fast sources when there's a slow one remaining etc..


  4. Er, this is what I see in Transfers... The client gets TTH, then downloads files.xml.bz2 and then starts to download from the same users...

    it has nothing to do with multisource. It's due to feature Autosearch automatch queue (or how is it exactly called)

    Also multisource has nothing to do with hubs, so it can't affect them in any way.


  5. So I won't use your clinet. Live with it ^_^

    It's your choice. You will get a lot of fake files, corrupted files and you will not be able to download anything from 99% of users. Live with it ^_^

    I also think hashing is stupid.

    I do. ^_^

    What's stupid with that? That you can't share fake files? Or that you can't upload corrupted files? Yes, it's really stupid :)


  6. possible implementaion is to send $RevConnectToMe to all active users and $ConnectToMe to all passive, then collect ips from answers (not actually connecting in first case and closing port in second)

    which causes hub overload


  7. English:

    The same problems are observed at attempt to receive a file a leaf from linux the client (if I am not mistaken that at the user costs valknut. Its tag - <DCGUI V:0.3.7, M:A, H:1, S:3>)

    p.s. Forgive for my English =)

    it was already written - remote client doesn't have full TTH support so we won't download from it. It's a feature and not a problem!