Download speed limiter and other features

[Vader]

Some feature requests:

1) Download speed limiter. I'm sharing my connection with other people and if I use DC++ it's taking almost all the bandwith and internet is slowing down for them. And if I could limit the download speed, there won't be such a problem.

2) Download sheduling. Not only when to download files, but also at what maximum speed.

3) Icon blinking. DC++ icon in the tray should blink at private message receieved or other events (for example disconnection from HUB).

BTW how the search is done in DC++, when I search does it check file list of every user in a hub? If so. maybe it's better to do like this: when user connects to the hub it uploads to him his file list, and when user searches fo something he just downloads one big list from the hub and later searches it. Of course It needs a hub with good internet connection, so this option could be disabled for others hubs.

[TheParanoidOne]

The features you have suggested have already been suggested and discussed to varying degrees. Some are also already in the Feature Request Tracker. I've included a few links to start you off, but this is in no way a comprehensive list. All search terms are highlighted.

1. Download Speed Limiting
[ 661945 ] Bitrate limit on downloads

2. New version popup annoying and dangerous (for me)! (partial discussion).
[ 712152 ] Scheduled downloading

3. Simple, useful feature
Not in Feature Request Tracker.

As for search, the way you described it initially is more or less how it goes. The suggestion you made seems like a bad direction to go in. Centralisation = bad! It leads to single point point of failure/attack. I know that I wouldn't want my filelist to be stored persistently in some central location. I'm sure people in the US wouldn't like that either, seeing as it could lead to law suits by the *IAA.

Setting the social aspects aside for the moment though, I think it might be a hassle to implement as well. It would require changes to clients (obviously) and hubsoft as well I think. You would still need to use the current system as well, for backwards compatibility (--> More complexity --> more things that could break). It may also need a change to the DC protocol as well, but I'm not too sure about that.

Also, you mentioned downloading this big list when you want to search. Imagine, hub population = 1500 users. Each with file lists ~128KB (based on my compressed version). Search file = ~190MB! And that not even taking into account multi hub or uncompressed lists!
An extreme example maybe, but you get my point, right?

Having just read what I wrote, it seems like I'm attacking your search idea. That wasn't my intention. Just pointing out some of the aspects you may not have thought of.

[GargoyleMT]

If so. maybe it's better to do like this: when user connects to the hub it uploads to him his file list, and when user searches fo something he just downloads one big list from the hub and later searches it. Of course It needs a hub with good internet connection, so this option could be disabled for others hubs.

That is similar to the way the Napster protocol and OpenNap network do file searches. Users upload their list, the server searches it and sends back results. What's the real advantage to the Napster way or your way? If you're on large hubs, with large shares, your idea just doesn't make sense - an aggregated file list (remember people are constantly updating/refreshing their shares) will be absolutely _huge_ and that bandwidth will have to come straight out of the hub's reserve!