On Tue, Sep 23, 2008 at 03:01:39AM -0400, James Antill wrote: > On Mon, 2008-09-22 at 22:51 -0500, Les Mikesell wrote: > > All they should have to do is request the same URLs. > > > > Why can't that happen automatically? That is, within whatever blocks > > geoip might consider 'near', arbitrarily select the first-choice mirror > > based on the source IP range in a repeatable way. That way everyone > > behind the same proxy requests the same URL and the caching works > > automatically. GeoIP doesn't have this level of granularity. Best we can get from that database "for free" is the country for a given address. Furthermore, I absolutely don't want to return the same mirror at the top of the list _for everyone_ in a given country. We want to load balance the requests across the mirrors in a given country. If your organization wants to ensure that everyone within it always is directed to the same mirror first, get the mirror owner to add your organization's netblock to the list of netblocks on their entry in MM's database. Then MM will always hand out that mirror to your users first. > MirrorManager gives the clients the URLs to try in a specific order > (and soon with even more data). Yum/urlgrabber will try the URLs in the > order it gets them. > So what you are saying essentially is: "Why can't MirrorManager decide > what the best URL is for a netblock/geoip and always list it first, just > to make the proxy problem zero-conf" > And I can guess that the answer to that is basically "Because it > doesn't work", feel free to send Matt patches though if you think > otherwise. If someone can give me a method of getting the entire Internet's BGP routing table, and a good algorithm for finding the bandwidth-weighted shortest path between two arbitrary points in that table, I'll gladly include that in MM. Until then, MM simply can't know enough to always give you the same (ideally correct) answer for any given set of clients. The netblocks trick is already pretty slick, and "good enough" for a lot of folks. but yes, patches would be welcome! Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
