A way to stop users from downloading the same file twice...

Archived discussion about features (predating the use of Bugzilla as a bug and feature tracker)

Moderator: Moderators

Locked
Enmakenryuu
Posts: 3
Joined: 2004-03-06 02:56
Location: California
Contact:

A way to stop users from downloading the same file twice...

Post by Enmakenryuu » 2004-03-07 10:03

Ive had this problem more then i a few times....someone downloads a file from me and then as soon as its done they re download it...i dont exactly know why they do it...but it would be nice to have something implamented that automaticly cuts off a connection of someone alredy downloaded a certin file from you.....becouse mt Download speed suffers greatly when someone is Uploading....ive gone literally from 150kbps..to 7 kbps...but i still let people dl from be becouse it's not fair for me to dl and not allow others to...

Todi
Forum Moderator
Posts: 699
Joined: 2003-03-04 12:16
Contact:

Post by Todi » 2004-03-07 10:59

People are downloading the same file more than once from you? The only situation where that would be useful is when they get your filelist. Try PM'ing them and ask what's going on, if it's intentional or a bug.

Anyway, you should probably limit your bandwidth a bit. Lots of topics on the subject here in the forum, where clients with bandwidth limiting are explained (like BCDC).

Twink
Posts: 436
Joined: 2003-03-31 23:31
Location: New Zealand

Post by Twink » 2004-03-07 15:41

This might be an occurance of the safe and compressed transfers bug. Try disable that feature in advanced settings and see if they still repeat. Personally I find this feature too handy to turn off for long periods of time, so I only disable it when I notice people having problems.

PseudonympH
Forum Moderator
Posts: 366
Joined: 2004-03-06 02:46

Post by PseudonympH » 2004-03-07 16:23

The question is whether the rewriting of the compression code in 0.307 will fix this bug or if it will just add a whole slew of new ones...

Qbert
Posts: 73
Joined: 2003-06-07 03:12

Post by Qbert » 2004-03-07 16:54

We haven’t seemed to have explicitly located the problem yet, if any. And if we finally do locate an exact problem, there isn't much compression code (Only part of DC++) to rewrite. It would just get small changes. The actual compression is handled by other libraries, which as I now remember and have a change to write in this forum, those libraries that DC++ ships with are outdated. I kept wanting to perform formal tests to show that when I updated the sources for the libraries, compression speed was better and CPU usage was less.

The libraries I feel should be updated, even excluding my non-formal tests.
My Visual Studio .NET 2003 is licensed under my name, and the same for my operating system... What about you?
I surf on an OC3 without limitations, two to be exact, and I'm not joking.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2004-03-11 20:22

PseudonympH wrote:The question is whether the rewriting of the compression code in 0.307 will fix this bug or if it will just add a whole slew of new ones...
As someone on the front lines of the bug report tracker, I think 0.307 will do well. I'm actually scouring the forum for bugs that need to be fixed (from any version, as long as they're seen in 0.307), so if you know of any, send them my way.
Enmakenryuu wrote:Ive had this problem more then i a few times....someone downloads a file from me and then as soon as its done they re download it..
Do you have a .SFV file in that directory? Does your file check out fine against it? It could be a compressed transfer bug, but I suspect that it's failing a checksum. A little more information is needed, though.

Locked