Op ma 25-02-2002, om 06:44 schreef Levi Ramsey: > On Mon Feb 25 2:52 +0100, Keld J�rn Simonsen wrote: > > A wish, not necessarily for 8.2: > > > > I would like to have automated finding the best site > > for a mirror, or actually the best site for a specific > > net service. > > > > The idea is to save users from a question like finding > > the best site. This could be a mirror for update, > > or the best timer available. > > > > The criteria for which is the best could be which > > is the fastest to respond. That is, issue a ping > > or another appropiate request to a list of potential > > mirrors and then wait and see which responds first. > > Another way could be to look at the nomber of hops like traceroute > > and take the site with the fewest hops. I think the fastest > > would be the better tho, as speed is going to matter in the end.
Bandwidth is what is important(something not easily measured without using significant bandwidth) not latency (pingtime) And experience will learn you very fast which servers are fast > > Maybe allowing rsync from all mirrors with package granularity would be > better... > > How this could work: > A) upon mirroring, mirrors generate a checksum of the checksum > files > B) when you want to update, the program asks every server for its > meta-checksum > C) In a shotgun-like manner, updates are fetched from all servers > with a specified checksum. > D) Faster mirrors would handle more of the load, but mirrors on > slow connections would still be feasible, and would take some load > from the fast mirrors. End result: greater capacity. > > I believe that similar functionality exists in a few P2P protocols, like > FastTrack. > They snip individual files in small pieces and assemble the file after downloading the pieces. Could be done but "we" know more about the cookersystem. Simply using a diff.bz2 between new and old rpm and downloading different files from different mirrors would be faster
