On 31 Aug 2007, [EMAIL PROTECTED] wrote: > I'd prefer a less draconian approach of sharing resources equally > between peers too. There are too many limits and too many reasons to > get punished. I doubt anyone has the slightest clue about the global > real-world effect of the diverse queing and limiting strategies, > especially if you take all the bugs and corner cases into > account. Furthermore, everyone has different aims and > motivation. Some want to improve fairness whereas there's little > agreement about what is fair and what isn't in this context. Others > just want to maximize the throughput.
There are several deterministic versions of fair. - First come, first serve. - Minimize time from request to completion. - Maximize content diversity. - Maximize throughput. All of these can be on a per request or per peer basis. There are also bounds on resources such as the number of sockets/file descriptors that will be open at one time. The problem with the "first come, first serve" is that large files will tend to dominate the queue. As the shorter files finishes, they can be replaced with large requests. However, this is easiest to implement. In a queue with only one served file the minimized wait is to put shortest requests first. This has the problem that the downloading peer might be bandwidth limited. I believe that the multiple serving is really only to deal with a limit bandwidth peer. Ie, the multiple serving is actually to maximize throughput. Certainly another case is that several slow peers dominate the active set, while faster peers are left waiting in the queue. A better single served file algorithm would require accurate estimates of bandwidth between peers as well as the file size. This is actually the real time for the download. There are several active and passive bandwidth measurement techniques. "http://www.caida.org/tools/taxonomy/performance.xml"; "http://www.cs.ucla.edu/NRL/CapProbe/"; I have been investigating these to see if it is possible to dynamically determine the "level 1" bandwidth of a node. This would allow for better ultra/leaf decision making. Possibly automatic (and dynamic) bandwidth limits. However, most of the methods in the URLs are concerned with node to node bandwidth and capacity measurements. Unfortunately many of the mechanisms require pcap type functionality and/or root access. Co-operation of both sender and receiver can remove this requirement. Another reason for multiple file serving is to leverage multiple downloads of the same source. This and dmesh further complicate any analysis of the minimum wait time. However, peers requesting rare content are less likely to be able to find alternate sources. A semblance of rarity is in upload_stats as "bytes_sent-low/size". At least this is the contribution we have made to replicating this part of our library on gnet. Another good reason to measure the bandwidth is to match bandwidth of peers. This will help to minimize the open sockets and file descriptors. Consider a T1 host serving files to DSL and dialup nodes. If everyone is fair, it is best for the T1 host to serve the DSL nodes and let them distribute the content to the dialup nodes. Anyways, most of these goals seem to be in competition. However, I think there is a win if we could add bandwidth measurements to the queuing algorithm. Having a large number of sockets and fds dedicated to this is just a way to try and get around measuring bandwidth. However, laggards downloading large files at a slow rate will eventually start to dominate the queue without bandwidth measurement. ... ok, I will stop now so Christian can blow holes in everything I have said. Regards, Bill Pringlemeir. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ gtk-gnutella-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
