You are sitting in a café and you decide to check your stock portfolio. Your request passes through the Internet to a stock quote server in New York. At the same time, someone next to you is watching live coverage of a Senate hearing and a couple of hundred brokers around the country are checking their portfolios using the same quote server in New York. You are competing with these people for resources: Net bandwidth, the quote server's disk, and processing time. As the Net makes available more and more resources that must be shared by more and more people, allocating these resources equitably becomes difficult.
Resource management for one computer - even one shared by many users - is relatively easy: the computer's operating system keeps track of all the users and their programs and hands out the computer's resources in some manner it deems fair. But there is no operating system for the Internet to make sure all users are happy (or at least equally unhappy). Firstly, the machines are managed by different organisations (Citibank, for example, will not let anyone manage its machines in order to ensure even distribution of its network load) and, secondly, some fundamental problems - exponential growth, the high overhead of collecting distributed information, and the impossibility of predicting resource usage - doom a traditional, centralised approach.
An alternative is to decentralise the decision making and infor-mation gathering processes. This is the approach taken by agoric systems. Agoric comes from agora, the Greek word for marketplace. The programs and computers in these systems become buyers and sellers of resources, much like a real-life marketplace. Buyers compete for scarce resources and try to get the best price they can, while sellers attempt to maximise their profit.
Mark Miller and Eric Drexler first used the term "agoric systems" in a paper they co-authored in 1988. Miller then went on to co-found Agorics Inc in Los Altos, California. The company applies a market-based system to allocating bandwidth in a computer network. With most networking protocols such as Ethernet, a user watching Independence Day can hog the bandwidth and keep everyone else's email from getting through, even though the mail is more valuable and should get through at the cost of dropping a frame or two of video, which would be undetectable.
A centralised, system-wide solution to this problem would be like trying to manage all the traffic in Manhattan by sending a police car to each intersection every few minutes to report the situation back to headquarters. The extra traffic would quickly bring the system to its knees. But setting aside bandwidth for video and data would be like reserving a lane at all times for police traffic: wasteful, because if there was no data traffic, the video should be able to use all the available bandwidth.
Agorics' solution allows applications to compete for available bandwidth. Each network switch awards bandwidth to the application willing to pay the high-est price - the one that needs it most.
Much more complex and ambitious is Michael Stonebraker's distributed database management system, Mariposa. Each Mariposa server has buyer and seller processes running on it. A buyer negotiates with a seller at another site to perform work on its behalf. To get prices for the stocks in his portfolio, a user in San Francisco would submit the appropriate query to a Mariposa server just as in a regular database system. But along with the query, the user sets a limit on the price and time the system can take to run the query - US$15 for an answer in 30 seconds, say, and nothing if it takes longer than five minutes. The query and other information is passed to a buyer process that breaks the query into pieces and sends them to seller processors running at various sites. Each seller responds to the buyer's request with the price it will charge to perform the work and an estimate of the time it will take.
The buyer may ask quote servers in New York and San Francisco to bid on reading the database file and picking out the entries in the user's portfolio. And the buyer may ask other Mariposa sites to perform other work, such as sorting the entries. The computer in New York may charge $10 and send the answer back in 10 seconds, while the San Francisco site may charge only $5 but take 10 minutes. The buyer collects all the bids and then notifies the winning sell-ers to begin work. This bidding process involves some communications overhead, but in most cases it is vastly outweighed by the time it takes to perform the work.
In addition to buying and selling computing power and network bandwidth, a Mariposa server can purchase database tables or copies of tables from other sites. If a Mariposa server in Chicago noticed that a lot of local users were accessing stock prices, it could try to buy a copy of the entire stock table from New York or San Francisco. The Chicago site would have to pay for the table as well as for updates when stock prices changed.
Unlike many current agoric systems, Mariposa does not keep buyers and sellers distinct. A seller that has been asked to submit a bid for some work can subcontract all or part of that work to another site, making it a buyer as well. Mariposa researchers simulated a company with offices around the world; Mariposa buyers compared how much each office paid remote sellers with how much it would cost to buy the necessary data. As a result, heavily used tables moved from office to office with the rising and setting of the sun, and overall system performance improved.
Agoric systems are not the answer to all the world's distributed computing needs. Just as in a capitalist economy, where not every worker is an independent contractor, computing also has a need for cooperation and centralised organisation. But the agoric approach is likely to become important for wide-area distributed systems like the Internet.
Jeff Sidell is a graduate student at UC Berkeley.