[
Back to the Fabrizio Oddone page
|
What's New
]
QuickestMirror
Last updated: June 10, 1997
Latest build:
1.0a5
What's this?
fab://info-mac.org?disk/disk-charmer-308.hqx
A new idea for the Internet. Technically speaking, a new Uniform Resource Locator (URL) scheme. Besides the specification for the fab URL scheme I am going to supply the first implementation, a "helper application" (tentatively dubbed QuickestMirror) for the new scheme.
Purpose
Do you usually access information replicated on several Internet servers? If you are a Macintosh user, the answer is probably yes. Whether you are trying to download a program from the Info-Mac archives, to grab the latest stuff by Peter N Lewis, or to browse the Apple Developer World site, the information you are looking for is available on several servers.
How do you pick a server? Although you are really concerned about network performance, most people often recommend "choose the mirror nearest to you". This is not a sound recommendation, because empirical evidence and scientific inquiry show clearly that geographical nearness is not a valid indicator for network efficiency.
This and other important results are found in this most interesting paper by Mark E. Crovella and Robert L. Carter, which I found almost by chance with Alta Vista. More about this later.
How does it work?
When you try opening an URL like this:
fab://ftp.stairways.com/stairways?
QuickestMirror will show an ordinary list like the one shown below. Faster sites drift to the top, since the list is dynamically updated.

A simple URL of the fab variety looks like this:
fab://devworld.apple.com?develop
(A precise and implementation-independent definition of the fab URL scheme is here.)
QuickestMirror will look up the string in bold characters into its local database, constructing a list like this:
http://devworld.apple.com/develop
http://devworld.euro.apple.com/develop
How does QuickestMirror know the host list?
These lists are stored locally, inside QuickestMirror itself. For this reason, if you know of distributed resources worth including please let me know.
It is certainly possible to devise a protocol allowing to retrieve such lists dynamically. Interested parties may want to know about spoofing attacks first.
Will my favorite Internet app take advantage of the new URL scheme?
Well-behaved Macintosh applications handle URL-related actions through InternetConfig. These applications will transparently use the new URL scheme.
There are notable exceptions, of course, such as Netscape, that will need an AppleScript kludge like this:
tell application "Netscape Navigator"
register protocol "QMir" for protocol "fab"
end tell
This instructs Netscape to let QuickestMirror handle fab URLs.
Still unconvinced?
Since a complete understanding of the aforementioned paper requires a background in maths and statistics, I summarize here their findings:
(these sentences have more or less been excerpted from the paper)
- The number of hops between two Internet hosts is not strongly correlated to round-trip latency. Thus, the distance in hops between two hosts is not necessarily a good predictor of the expected latency of a document transfer.
- The extra cost at runtime incurred by dynamic latency measurement, as compared to prior static knowledge of hop distances, is well justified based on the resulting improved performance.
- Selection based on dynamic latency measurement is preferable to random selection.
- The effect of randomly distributing replicas throughout the Internet is to sharply decrease the latency between a client and server; that is, you do not need to devise a host replication strategy. As an added bonus, you gain fault tolerance.
- Network congestion plays a significant role in the overall distribution of round trip times.
- Dynamic policies consistently outperform static policies; furthermore, the difference between static policies and dynamic policies increases with increasing document size. In fact, even random server selection is preferable to choosing any static server for documents larger than 5K bytes.
Requirements
QuickestMirror will definitely require InternetConfig (possibly 1.1 or later, although 1.3 or later is recommended). It will require Open Transport 1.1.1 or later to assess network performance; MacTCP users will still be able to pick a server at random, which is better than a fixed selection.
QuickestMirror will be distributed as a fat application; it will also require a 68020 processor. If there is demand, I will build a 68000 version for separate distribution.
Availability
Testing (not public!) is almost complete. If you are interested in joining the beta crew contact me at the address below.
accesses since
March 8, 1996.
This page was last built with Frontier on a Macintosh on Fri, Jun 13, 1997 at 14:21:37 by
Fabrizio Oddone, fab@kagi.com