-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160
As far as I have understood there is one place which currently hosts all the dist files and uses up around 2Gig of space, that is the opendarwin server which was generously offered to us?be more than happy to do that once all of the software parts have been put into place.
David, what infrastructure is actually missing? :-) We have a mirror server, and we have the code in Fink CVS to use it... so, what's missing? Sure, more "master" mirrors in the future will be nice, but not needed to get things going...
If we really choose to release this and people start setting their System to "MasterFirst" then something like a huge ressource increase, bandwidth and system ressource wise should be imposed on their server. Please do correct me if I am missunderstanding things.
Not to mention, how does the code handle the availability of multiple Masters?
In my basic ideas and I think Feanor and BBraun understood it the same way, the distribution looks somewhat like this:
Master Distfile <--------> European Master Distfile <--------> blah Master DistFile
And several Slave DistFile Mirrors update from the different Master server.
Now we have a single server that is able to host all distfiles (maybe along with the sourcefogre mirrors? ) and I can hardly call that an infrastructure. But again, that is a personal opinion.
<snip>
OTOH, we very often run into troubles because some upstream maintainer removed the source tarball, or worse, silently changed it (although MD5's will catch this). So, I think for stable users users, searching the Master first makes a lot sense and will probably result in a much better experience IF our master mirrors are fast and "always" reachable.To me that is a moot point. In case of failure the code would automatically jump to the next mirror listed. When a 404 or "file not found" or whatever is encountered the connection is reset quickly enough to not introduce long delays as the mirrors are cycled. Yet, I can agree, stable users will most likely rely on sources that are not changing too quickly or often.
Another example: a company or university wants to use Fink on all their systems and sets up some central server which hosts binaries, and also source files. They could configure their own master source mirror, so that users trying to build something from source do not have to go outside (which may not even be possible) to get the source.
In my understanding that is a local slave mirror. This mirror updates from a Master Mirror and then "echos" its data back to the local clients. Thus the university only needs to grant access to the world to the single slave mirror and not all of the clients.
I agree, that such a local slave mirror should always be setable.
No need to argue, it is the decision of the project leads, I am simply voicing my opinion. IN the long run it does not really matter anyways, bot approaches have their pros and cons and my concerns are rather esoteric not very factual.
We can argue which option should be default, but I see no reason to completely drop the MasterFirst option, but several to keep it. If it's not the default, then it can't harm average Joe User, can it?
<snip>
The idea on the FR is to "order" the servers based on ping results. While that (as I argued) doesn't give any info on the servers transfer speed, a server with a low latency is more likely to be fast than one with a low one... and you can sort out servers you can#t reach at all this way, too. We might want to implement something like this as an optional feature in "fink configure".Actually you would have to use a Layer4 Traceroute to really get reliable data and you'd have to implement a connect probe which times how fast the peer accepts the connection. I have such a program done in C, unfortunately it was written for our company and I cannot release the sources, yet I am sure that it is quite possible to implement such in Perl. Another problem is, that you cannot have this as a static list. You would have to rerun all test at a given interval to make sure that your timing is still correct. Averaging connect times that make sense is a statistically non trivial issue, so there should be a lot of thinking going into this ;)
It would be great to have such a system though.
Thanks :)
- -d
- - "Deep into that darkness peering, long I stood there wondering, fearing,
- - Doubting, dreaming dreams no mortal ever dared to dream to dream before.." Edgar Allen Poe - The Raven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)
iD8DBQE+kC4FiW/Ta/pxHPQRA+HBAJ4vQWLIdIMtptkgxqMUFzmi2hVxCgCguVg4 MPu0H643kYhiq49tiDKoe30= =ptOn -----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
