Slot notification inefficent
Moderator: Moderators
Slot notification inefficent
Why is it connecting to sources every few seconds TCP to check for open slots, shouldnt the client just jump on a remote queue and then be notified by UDP when they reach the top of the queue ie when a slot is available?
Run netstat and you see multiple TCP connections to the same host all in time wait status.
Run netstat and you see multiple TCP connections to the same host all in time wait status.
A similar idea has been proposed here:
http://dcplusplus.sourceforge.net/forum ... php?t=1381
I'd really like this feature too, it would make the DC network just a bit more fair. It should, in my opinion, be implemented the way "sarf" proposes, using "reverse connecting".
/Anders
http://dcplusplus.sourceforge.net/forum ... php?t=1381
I'd really like this feature too, it would make the DC network just a bit more fair. It should, in my opinion, be implemented the way "sarf" proposes, using "reverse connecting".
/Anders
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Re: Slot notification inefficent
Note, in DC++, "few" is either 50 or 60 seconds. That's how long it takes before DC++ decides to check for open slots.Nocturnal wrote:Why is it connecting to sources every few seconds
See also "upload queueing code" by cologic in this forum. It's not full featured, but it is a good starting point.
Upload queues are being worked on and thought of. I don't think a separate mechanism needs to be invented to tell someone that they're next in line, nor does the slot checking need to be done more infrequently.
You realize that right now, DC++ doesn't queue uploads at all, it's just luck of the draw on who gets open slots, right?
Re: Slot notification inefficent
Yeah, sometimes I'm really lucky and other times, well I'm not. It's just another DirectConnect protocol annoyance.GargoyleMT wrote:You realize that right now, DC++ doesn't queue uploads at all, it's just luck of the draw on who gets open slots, right?
Emule queue system
Emule has quite an inteligent queuing system which uses the idea of credits whereby each client is rewarded for uploading by advancing in the time based queue more quickly. Each client has a unique identifier and maintains a list of other clients identifiers and how many Mb they have uploaded. Eg Client A uploads so many Mb to client B, client B records client A's id and how many Mb then next time client A wants to download from client B a time based multiplier (exponential decay relationship to Mb) is calculated eg 2 meaning every minute on client A's queue will count as two compared to a fair queue. The system is resistant to queue cheating as your Mb data is stored on other clients that you have uploaded to.
Also I think some hashing system and segmented downloading system is needed. The emule uses md4 hash calculated over blocks of 9500kb then a master hash calculated over the whole file to verify the integrity of a completed download. As each 9500kb block is downloaded and verified it is made available to share to other clients negating the need to download the whole file before it can be reshared. If the reported hash does not match the calculated hash the block is discarded and redownloaded. (They do have an option called inteligent corruption handing that is supposed to reduce the need to redownload the whole block if possible - I have not gone over the code to determine how this works). Hashing is a necessity because a corruption in someones download can be duplicated multiple times to everyone who uses them as a source, wasting much bandwidth and time.
The source is available at http://emule-project.net
Also I think some hashing system and segmented downloading system is needed. The emule uses md4 hash calculated over blocks of 9500kb then a master hash calculated over the whole file to verify the integrity of a completed download. As each 9500kb block is downloaded and verified it is made available to share to other clients negating the need to download the whole file before it can be reshared. If the reported hash does not match the calculated hash the block is discarded and redownloaded. (They do have an option called inteligent corruption handing that is supposed to reduce the need to redownload the whole block if possible - I have not gone over the code to determine how this works). Hashing is a necessity because a corruption in someones download can be duplicated multiple times to everyone who uses them as a source, wasting much bandwidth and time.
The source is available at http://emule-project.net
Corruption
PS Also the file may download fine but may be corrupted locally ie on the filesystem or local lan. Therefore any hashing system should periodically rehash a percentage of files shared to revalidate the integrity of the local copy.
This thread documents some user rating ideas people here have had pertaining to DC++; in a couple of recent threads now I've linked to it...[/url]
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us