win98 compatibility & other reqs

[combo 0]

Hi!

A win98 compatible non-outdated segmented downloading capable dc++ client would be nice.

The latest version of original DC++ now uses unicows.dll and (probably) works on win98, so this part may be portable to ApexDC++.

Others:

-easy way to remove something from download queue (without open the download queue window)

-ban user from downloading (I hate users who download at 1 MB/s from me and use 5 kb/s netlimiter).

-flexible thread management (preferrable user (who I'm downloading at high speed from) with one click, so I won't lose its slot).

Sorry for my bad English.

[Lee 84]

Hi!

A win98 compatible non-outdated segmented downloading capable dc++ client would be nice.

The latest version of original DC++ now uses unicows.dll and (probably) works on win98, so this part may be portable to ApexDC++.

Others:

-easy way to remove something from download queue (without open the download queue window)

-ban user from downloading (I hate users who download at 1 MB/s from me and use 5 kb/s netlimiter).

-flexible thread management (preferrable user (who I'm downloading at high speed from) with one click, so I won't lose its slot).

Sorry for my bad English.

Welcome.

• Banning won't be implemented: leecher tool
  
• Removing file from the transfer view is nice, I hope Big Muscle implements this in RC11
  
• Explain flexible thread management
  

[combo 0]

[*]Banning won't be implemented: leecher tool

You are right, this is not the best solution. But I need something to differentiate the "good and bad users". (For example option to set a different upload limit for a special user). I don't want to generally limit my upload speed, because "good users" are allowed to download from me as fast as they can. But I don't want to allow "bad user" this... (Now I diconnect them and hope that my client give to an other user the new free slot). And other P2P systems have ranking system too...

[*]Explain flexible thread managemen

I meant clever segment management. I know that I can set in the download queue window the number of segments and the source users... An example: I'm downloading a huge file from 6 users at low speed. After waiting 2 hours a new "high speed segment" starts (earlier I got no free slots message from this user). It would be nice, that I could _prefer_ this user (don't disconnect from him (because I may "lose" his slot) until I download the biggest possible part of the file (even the client may "overwrite" some earlier downloaded parts). Sorry English is not my native language (as you probably see ); I can't explain better: The client should manage the segments to get the smallest download time. I know that there is no universal rule for this, so client may give the user more options. (In my example a non-multisegmented client is more effective than a segmented.)

[Big Muscle 1]

Maybe I understand what you're talking about - losing slot when chunk is finished.

I don't know exactly how it's done in PWDC, but if it's like in StrongDC++ then there's possibility to lose slot only when you have enabled DC++ emulation for hub you're downloading from...

When emulation is disabled, then you can't lose slot In next version of StrongDC++ there will be feature that if user speed is known then chunk position will be assigned according to the speed :)

[Zlobomir 3]

And on the other hand: If your idea is applied, you start to download from the "fast" user, and he goes offline (power/net failure, whatever, at his side)? And then the other 6 users do not have slots? It does not make much sense, all is luck.

[Lee 84]

Combo: So basically you want an option to 'reward good uploaders' which will prioritise them and give more bandwidth to those users. However, I believe this is against DC rules to prioritise users?

[Zlobomir 3]

Combo: So basically you want an option to 'reward good uploaders' which will prioritise them and give more bandwidth to those users. However, I believe this is against DC rules to prioritise users?

I do not believe it is, but I believe that with some shaper all our rewards will be useless. So isn't it better to preserve the "pureness" of the program? I personally have proposed such features before, but now I see there is not much sense. If there is not good will, little can be done. At most, "bad" users will start to avoid ApexDC++.

[Lee 84]

If you have downloaded over 50MB off a user, give him one point. 100MB, two points, etc.. This probs cannot be stored for every user, so it would only apply for one session.

The more points, the large percentage of upload speed they require. Obviously this is a very basic idea..

Another very simple idea would be to give a user more speed if they have uploaded 100MB to you. Maybe this could be configured to the user's preference. I'm not sure how the speed would be detected and distributed.

[Zlobomir 3]

If you have downloaded over 50MB off a user, give him one point. 100MB, two points, etc.. This probs cannot be stored for every user, so it would only apply for one session.

The more points, the large percentage of upload speed they require. Obviously this is a very basic idea..

Another very simple idea would be to give a user more speed if they have uploaded 100MB to you. Maybe this could be configured to the user's preference. I'm not sure how the speed would be detected and distributed.

1st: It seems quite hard to me, it's kind of an "IP-based shaper" inside the program.

2nd: It is not bad "automation" for high-speed users or at least for users with separate up/down bandwidth. But for people like me on a miserable speed (I run what-you-can-think-of on my server, namely HTTP server, DC++, BT, and occasionally download manager), it will be a burden. Especially if according to the idea, DC++ requires more, more, more speed, cutting it off the other apps, but the "leecher" can't use it due to his own connection limits (or even worse, DC prefs).

Edited March 5, 2006 by Zlobomir