<%BANNER%>

Resource and Requirement Schemas Applied to Auctioning in a Computational Market


PAGE 1

RESOURCE AND REQUIREMENT SCHEMAS APPLIED TO AUCTIONING IN A COMPUTATIONAL MARKET By MARK JOSEPH TOBIAS A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2001

PAGE 2

To Amy

PAGE 3

iii ACKNOWLEDGEMENTS I must first and foremost express my deepest appreciation to my committee chair, Dr. Michael Frank, for presenting me with the opportunity to work on such a fascinating project. His continuous guidance played a significant role in bringing this project to fruition. I would also like to thank my other committee members, Drs. Jonathon Hamilton and Joachim Hammer, for their meticulous review of this thesis. I would also like to express my gratitude to all members, past and present, of the OCEAN research project. Through painstaking collaboration, their contributions produced meaningful results that appear in this thesis. And on a personal note, I must express my most sincere thanks to my wife, Amy. Her unending support and encouragement were a constant source of inspiration throughout this experience.

PAGE 4

iv TABLE OF CONTENTS page ACKNOWLEDGEMENTS ............................................................................................. iii LIST OF TABLES ........................................................................................................... vi LIST OF FIGURES ......................................................................................................... vii ABSTRACT ..................................................................................................................... ix CHAPTERS 1. INTRODUCTION ....................................................................................................... 1 1.1. The History of Computational Markets ............................................................... 1 1.2. The OCEAN Software System ............................................................................ 4 2. OCEAN SOFTWARE ARCHITECTURE ................................................................. 9 2.1. Usage Philosophy ................................................................................................. 9 2.2. Architecture ........................................................................................................ 10 3. TRADE PROPOSAL SCHEMAS ............................................................................ 20 3.1. The Need for Standardization ............................................................................ 20 3.2. XML in the Auctioning System ......................................................................... 21 3.3. OCEAN Trading Schemas ................................................................................. 22 4. TRADE PROPOSAL API ......................................................................................... 41 4.1. Introduction ........................................................................................................ 41 4.2. Java and XML .................................................................................................... 42 4.3. The Document Classes ....................................................................................... 43 4.4. Creation and Manipulation of Schema Constructs ............................................ 46 5. AUCTIONING .......................................................................................................... 56 5.1. Introduction ........................................................................................................ 56 5.2 Proposal Propagation .......................................................................................... 57

PAGE 5

v 5.3 Auctioning Subsystem Design and Implementation .......................................... 60 6. DISTRIBUTED AUCTION SIMULATION AND RESULTS ................................ 74 6.1. Simulation as a Testing Tool ............................................................................. 74 6.2. Simulator Implementation .................................................................................. 75 6.3. The Simulation Scenarios .................................................................................. 78 6.4. Notes On Results ................................................................................................ 93 7. CONCLUSIONS AND FUTURE WORK ............................................................... 94 7.1. Conclusions ........................................................................................................ 94 7.2. Future Work ....................................................................................................... 95 APPENDIX SCHEMAS ...................................................................................................................... 97 A.1 Resource Schema ................................................................................................ 97 A.2 Price Schema ..................................................................................................... 100 A.3 Buyer Schema .................................................................................................... 103 A.4 Seller Schema .................................................................................................... 107 REFERENCES .............................................................................................................. 112 BIOGRAPHICAL SKETCH ........................................................................................ 115

PAGE 6

vi LIST OF TABLES Table page 6.1 Configurations of Simulation Scenarios .................................................................. 79 6.2 Baseline Measurements of Main Scenario Groups .................................................. 82

PAGE 7

vii LIST OF FIGURES Figure page 2.1 The OCEAN System ................................................................................................ 12 2.2 OCEAN Node Architecture ..................................................................................... 15 2.3 Intercomponent Communication .............................................................................. 17 3.1 Diagramming Notation Legend ................................................................................ 23 3.2 CPU Structure .......................................................................................................... 2 4 3.3 Price Structure .......................................................................................................... 28 3.4 Schedule Structure .................................................................................................... 29 3.5 Buyer Structure ........................................................................................................ 3 1 3.6 Task Structure .......................................................................................................... 33 3.7 Task List Structure ................................................................................................... 35 3.8 Task Group Structure ............................................................................................... 36 3.9 Seller Structure ......................................................................................................... 39 4.1 Document Class Structure ........................................................................................ 45 4.2 Resource Classes ...................................................................................................... 50 4.3 Task Related Classes ................................................................................................ 51 4.4 Price Classes ............................................................................................................ 52 5.1 Trade Proposal Propagation ..................................................................................... 58 5.2 Node, Agent, and Auction Classes ........................................................................... 61

PAGE 8

viii 5.3 Auction Creation Classes ......................................................................................... 64 5.4 Trade Proposal Classes ............................................................................................. 66 5.5 A TreeSet of Resources ............................................................................................ 70 5.6 Resource Compatibility ............................................................................................ 72 5.7 Compatibility Correctness ........................................................................................ 72 6.1 Matches for 5 Node Auctions, 3 Buyer and 3 Seller Documents ............................ 83 6.2 Matches for 5 Node Auctions, 6 Buyer and 6 Seller Documents ............................ 84 6.3 Matches for 10 Node Auctions, 3 Buyer and 3 Seller Documents .......................... 84 6.4 Matches for 10 Node Auctions, 6 Buyer and 6 Seller Documents .......................... 85 6.5 Matches for 5 Node Auctions, 3 Buyer and 6 Seller Documents ............................ 85 6.6 Matches for 5 Node Auctions, 6 Buyer and 3 Seller Documents ............................ 86 6.7 Matches for 10 Node Auctions, 3 Buyer and 6 Seller Documents .......................... 86 6.8 Matches for 10 Node Auctions, 6 Buyer and 3 Seller Documents .......................... 87 6.9 Timeout Effect on Matches for maximum hops = 2, known nodes = 2 ................... 88 6.10 Timeout Effect on Matches for maximum hops = 4, known nodes = 4 ................. 88 6.11 Timeout Effect on CPU Usage ............................................................................... 89 6.12 Maximum Hops Effect on Matching, 2 known nodes, 10s timeout ....................... 90 6.13 Maximum Hops Effect on Matching, 4 known nodes, 20s timeout ....................... 90 6.14 Known Node Effect on Matching, 2 maximum hops, 10s timeout ........................ 91 6.15 Known Node Effect on Matching, 4 maximum hops, 20s timeout ........................ 91 6.16 CPU Usage of Validating vs. Non-validating Scenarios ........................................ 92

PAGE 9

ix Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science RESOURCE AND REQUIREMENT SCHEMAS APPLIED TO AUCTIONING IN A COMPUTATIONAL MARKET By Mark Joseph Tobias December, 2001 Chair: Michael P. Frank Major Department: Computer and Information Science and Engineering At no other time in human history have so many people had access to powerful computing resources. And yet, many of these resources lie idle for long periods of time, simply running a screensaver, or not running at all. Conversely, there are many individuals and organizations who have intense computations to perform, but do not have access to the resources that are required to execute them. The goal of the Open Computation Exchange and Auctioning Network (OCEAN) is to provide a virtual marketplace where participants exchange the temporary use of their computational resources for economic compensation. OCEAN, a major ongoing research effort conducted in the Computer and Information Science and Engineering Department at the University of Florida, is what is often referred to as a computational market. A computational market is a marketplace in which computational resources are the traded commodities. The focus of this thesis is on

PAGE 10

x the process by which trade occurs in the market. In particular, technologies were developed that provide traders with the ability to form trade proposals and submit them to auctions, where potential trading partners have also submitted proposals. Due to the fact that trade proposals in the market may be complex, expressive data description languages for trade proposals were developed according to the XML Schema specification. These XML-based trade proposals are generated via Application Programming Interfaces, and subsequently consumed by the Auctioning component of the OCEAN system. When a trade proposal is submitted to the Auctioning system, it finds another trader in the market that can satisfy the submitted trade request, if it is feasible to locate such a trader. A simulator was developed to test the performance of the auctioning algorithms with respect to configurable parameters.

PAGE 11

1 CHAPTER 1 INTRODUCTION 1.1 The History of Computational Markets The commodification of computing resources is not a novel concept. Indeed, systems that can be described as computational markets have been implemented as early as 1968. Sutherland demonstrated how auction methods were used to allocate time to users of the PDP-1 computer in the Aiken Computation Laboratory at Harvard University [29]. The hours of the day were divided into regular time slots. Users were assigned different amounts of currency based on their project's importance. Then, the users would submit bids for time slots. For a given time slot, the user who submitted the highest bid would have use of the computer. By using the auction methods described, a monetary value was associated with computation time, which is a basic feature of computational markets. This paper is important because it may be the first application of economic principles to the problem of computer resource allocation. Another major research effort was the Agoric Papers [8, 15]. Although there is no implementation associated with these publications, they established important groundwork for modeling distributed computation in economic terms. Although Sutherland's work [29] was important for using economic principles to solve resource allocation problems, it did not address the problem in distributed systems. Drexler and Miller approached this problem by describing auction mechanisms for allocating distributed resources. In one of their solutions, a seller auctions off resources to

PAGE 12

2 competing buyers. Escalator algorithms are used in such a way that buyers only submit an initial bid. Bids increase at a constant rate until the highest bid is determined. The highest bidder obtains the seller's resources. Drexler and Miller continued, describing initial market strategies, and how they achieve stable pricing mechanisms. Later work [31] has proven Drexler and Miller's algorithms to be effective for achieving this goal. The Agoric Papers made two important contributions to computational markets. First, they provided market-based mechanisms to allocate distributed resources. And second, they addressed the issue of how pricing stability can be achieved in computational markets. These are essential for a successful computational economy. A more recent research effort is the Compute Power Market project [3]. This project has designed a decentralized, market based architecture that is highly dependent on agents. The decentralized architecture is similar in some respects to the architecture of the OCEAN system. This is discussed further in section 2.2.1. Buyya and Vazhkudai have also made the same observation that drives this thesis. Namely, that the information resource providers and consumers convey to the market can be complex [3]. In addition, capabilities must exist whereby potential trading partners must be checked for resource compatibility before a trade is allowed to proceed. Like the commodification of computing resources, the engagement of idle computers to perform useful tasks is also not a new concept [3]. Possibly the first such implementation to exhibit this behavior was developed by Shoch and Hupp, which they named a "worm" [25]. The worm was characterized by two very important traits. First, it was parallelizable—able to be broken into discrete segments, each segment running on

PAGE 13

3 a different host. Second, the worm was able to sniff out idle machines on the network. Although this project was not concerned with the economics of computation, it still represented a significant step toward fully functional computational markets. This observation lies in the fact that the worm's traits are important features of programs used in computational markets. For one, idle machines in a network must be located. Also, users of programs that can be parallelized stand to benefit most from computational markets, because they achieve the highest utilization of available resources. More recently, implementations of systems that successfully run programs on idle computers have been developed. The two systems that have received much attention are the SETI@home project and Distributed.net [24, 7]. While each of these projects has had success in parallelizing computations and running them on otherwise inactive machines, neither qualifies as a computational market. Both of these projects rely on the altruism of their participants; users donate CPU cycles in a concerted effort to solve some computationally intense problem. In the case of SETI@home, users analyze radio telescope data to search for extraterrestrial life. Distributed.net participants engage in a variety of collaborative efforts, such as breaking encryption ciphers. There are several commercial ventures that are attempting to extend the concepts of a computational market to business advantage. Some of these include United Devices, Entropia Distributed Computing, Parabon Computation, and Porivo [30, 9, 20, 22]. In each of these ventures, organizations that have intense computations to perform become partners with the venture. The types of programs vary; they include web application performance testing, bioinformatics analyses, and engineering applications. Idle

PAGE 14

4 processors of individuals or organizations are recruited to perform the computations. Often, the idle processor owners are compensated for their services. None of these systems, however, share the OCEAN philosophy of maintaining an open market. In no case are participants able to meet and negotiate independent of the business entity. The computation performers have no influence as to the price they charge for services rendered. Effectively they must accept whatever payment is disbursed, or donate services charitably. The provision of a fully functional market, where traders are able to meet, exchange information, and negotiate contracts, is one of the unique aspects of the OCEAN research project. 1.2 The OCEAN Software System 1.2.1 Overview The aim of the OCEAN project is to provide an infrastructure to support automated purchasing and selling of distributed computing resources over the Internet [18]. Any individual or organization with unused or idle computing resources can offer them as an OCEAN server, thereby renting their facilities for profit. Conversely, any individual or organization with a computing task to perform, but who does not have direct access to the resources required to carry out the task, may rent as many OCEAN servers as they can afford in exchange for each server performing a part of their computing task. There is an obvious advantage for each party involved. The resource provider is compensated for the use of their otherwise stagnant resources, thereby offsetting the cost, and possibly generating a profit, for the purchase of said resources. The resource purchaser is able to perform their computing tasks while forgoing the purchase of expensive hardware.

PAGE 15

5 Most commonly, a developer will have a computation that is by nature highly parallel, and they deploy the application on as many OCEAN servers as they can afford to purchase. The basic process for such a scenario is as follows. A developer must first have programming libraries at their disposal, which allow him or her to develop an OCEAN-aware application. The developer indicates, either statically or dynamically, the resource requirements of his or her application, and the maximum price they will pay for the computation to be performed. The resource requirements, coupled with maximum price, form a bid in the market. Anyone who submits a bid is referred to as a buyer When the administrator of an OCEAN server has resources that are ready to go idle, he or she becomes a seller by forming an offer based on the minimum price they will accept for the use of their resources. Bids and offers are entered into the OCEAN distributed auctioning system. The auctioning system matches potential buyers with sellers, and vice versa. When the auctioning process produces a potential trading match, all parties involved are notified of the match. The negotiation process then allows traders to determine the actual prices at which trade will occur. Once prices are agreed upon, the developer's application is deployed by the task spawning and migration system, and the computation is executed on the remote OCEAN servers. When each OCEAN server is finished performing its work, they can be paid for services rendered. See Chapter 2, OCEAN Software Architecture, for a more detailed discussion of OCEAN and its components. It should be noted that, even though the above process is the most common OCEAN transaction, this is not the only scenario possible. The auctioning and negotiation processes remain the same, but the types of resources requested and provided

PAGE 16

6 do not necessarily have to be related to a computation. For example, a buyer may purchase space on a large data store (possibly the result of an OCEAN computation) for some period of time. Also, a buyer may be purchasing a resource future the right to resources at some time in the future. The OCEAN trading framework is designed to accommodate such interactions. See Chapter 3, Trade Proposal Schemas, for more information regarding the format of trade proposals. That which begins as a simple, straightforward concept becomes complex in a very short amount of time. The two basic ideas behind OCEAN are simple ones. First, allow individuals to profit from the use of their otherwise idle computing facilities. Second, provide a cost effective way for individuals to perform their computing tasks. However, to provide the infrastructure to support these interactions is not an easy task. An OCEAN transaction requires that the following events must occur. First, the traders involved in a transaction must locate one another, and agree on the terms of a contract. Once resources have been negotiated for, the buyer's computation can be deployed over the OCEAN servers in a secure fashion, if that is part of the contract terms. Each OCEAN server will return the results of its computation, if that is part of the contract, and payment can be exchanged. This process occurs with as little human intervention as possible, and requires the cooperation of many complex software components. See the next chapter for a more in-depth discussion of the OCEAN software architecture. 1.2.2 The Auctioning System The focus of this thesis is the Auctioning system of the OCEAN project. The main purpose of the auctioning process is to match traders with the best possible trading

PAGE 17

7 partners. For buyers this means finding sellers who not only offer the best prices, but also provide the resources that the buyer is requesting. For sellers, the Auctioning system is responsible for finding the highest paying buyers, without exceeding the resource capabilities of the seller. However, this is not a trivial task. Buyya and Vazhkudai make the observation that resource requirements of buyers can be complex [3]. The buyer may have strict requirements regarding hardware and software resources that must be satisfied. For example, a buyer may require a secure environment to protect sensitive data. Or, they may require a high-speed network connection because a large volume of data is to be transmitted with a task. A buyer may also need certain hardware, a sophisticated graphics board, for example. Similarly, sellers may offer many differing types of services; they may have a vast array of hardware, software and data resources at their disposal. In order to handle the complexity of trade proposals, expressive data description languages were developed in the Extensible Markup Language, or XML. These languages were developed according to the XML Schema specification [36], defining the format that trade proposals assume. Application Programming Interfaces (APIs) were developed for the Java™ programming language that allow OCEAN traders to define the resources they request or provide. In addition, the APIs allow traders to express the prices at which they are willing to trade. In XML vernacular, these APIs generate the XML content that defines a trade proposal. Chapter 3 examines the trade proposal languages in depth. Chapter 4 covers the Trade Proposal API.

PAGE 18

8 The auctioning system is the component that consumes the XML-based trade proposals. It parses all relevant trading information for each incoming proposal, and attempts to find a matching trader(s). Distributed algorithms were implemented to perform this function. The auctioning process occurs in a distributed, peer-to-peer framework among many nodes in the OCEAN system. Potential trading partners, before being matched, must have their resource descriptions checked to verify that the traders are compatible in terms of resource request and provision. Chapter 5 explores auctioning in the OCEAN system. Finally, a simulator was developed to test the performance of the auctioning system relative to configurable parameters. The OCEAN system is still in development. At the time of this writing, no other components of the system are mature enough to test with the auctioning system. Thus all testing of the auctioning system must be performed through simulation. Chapter 6, Distributed Auction Simulation and Results, discusses the testing simulator and the results of its operation.

PAGE 19

9 CHAPTER 2 OCEAN SOFTWARE ARCHITECTURE 2.1 Usage Philosophy The Open Computation Exchange and Auctioning Network is a system in which anyone may participate. Any individual or organization with a computer can download the OCEAN software system and participate in the Exchange and Auctioning Network, heretofore referred to as the Network for brevity. In this sense, it is "open," i.e. open for anyone to join. But OCEAN is meant to be "open" in other senses as well. Miller and Drexler [15, p. 135] define an open system as one where "software spread across a distributed computer system serves different owners pursuing different goals." This is one of the main goals of the project: to provide an environment where participants obtain useful services through their interactions with one another. Coularis et al. [6] describe an open system as one that can be extended and implemented in new ways without disturbing its existing functionality. One of the keys to providing this openness is to ensure software interfaces of the components are specified and documented. This is one of the most pervasive philosophies of the OCEAN research group. That is, the software system will define a set of standards, including software interfaces and communication protocols that anyone is free to extend and implement. As long as the interfaces and standards established are adhered to, the functionality of the system will not be compromised.

PAGE 20

10 Among other things, this thesis defines and documents the software interfaces to the auctioning system, along with the format to which trade proposals must conform. Using these standards, anyone is free to use and extend the APIs and trade proposal schemas to participate in the Network. By providing a set of extensible APIs and trading formats, the auctioning system follows the philosophy that the Network should be open. 2.2 Architecture 2.2.1 Architecture of the Deployed System Coularis et al. [6, p. 2] define a distributed system as "one in which hardware or software components located at networked computers communicate and coordinate their actions only by passing messages." The OCEAN software system fits this description. The most common type of architecture for a distributed system is the client-server model [6]. A client-server type of architecture for OCEAN would employ a server process, or many processes to handle all auctioning, negotiation and accounting between buyers and sellers (clients). The potential volume of users that are able to participate in the Network is enormous; anyone with a computer may join. Thus, the likelihood of encountering scalability problems is a huge factor in the system design. A system is described as scalable if its effectiveness is not compromised upon significant increases in the number of resources and the number of users [6]. The client-server model can present scalability problems for two reasons. One, the server may be a bottleneck when the user volume is large. Two, a server can act as a single point of failure. For these reasons, a client-server type of architecture is unsuitable for the OCEAN system.

PAGE 21

11 Buyya and Vazhkudai propose a decentralized architecture for the Compute Power Market that is based on mobile agents [3]. This is important, because the decentralized architecture improves the fault-tolerant capabilities of the system. Their architecture relies on a distributed network of market servers to implement the market mechanisms. While the Compute Power Market approach improves fault tolerance over a client-server approach, it does not achieve maximum scalability. The fact that there are a finite number of market servers has implications—if the number of users increased dramatically, it is possible that there are not enough market servers to keep the market operating efficiently. The OCEAN system attempts to improve scalability by implementing a distributed, peer-to-peer based architecture. The OCEAN software system, developed in the Java™ programming language, is packaged as a single unit, and can be installed on any computer with a Java™ Virtual Machine (JVM), thereby causing the machine to become a node in the Network. Any node can perform any function in the Network. Thus any node can hold an auction, execute a buyer's computation, serve as an application development environment, or an application launch point. The high level interactions among nodes is depicted in Figure 2.1. As can be seen from Figure 2.1, all nodes are connected to one another in one of two ways. Either they are connected directly via the Internet, or indirectly through a node that operates as a gateway to other nodes in an intranet behind a firewall. Note that specific types of node indicate the role that each one is playing at a given point in time. For example, a node that is acting as an auction server at some point in time can act as a

PAGE 22

12 server performing a computation at another time. The only exception to the completely distributed nature of the OCEAN system is the presence of a centralized accounting system. The main responsibilities of the accounting system are to log transaction information to stable storage, to disseminate payments to resource providers and extract payments from buyers. In general, the prices at which resources are bought and sold are may not be very large. For example, an individual’s desktop PC may be rented for only a few minutes. An account is kept for every trader. This is similar to a conventional bank Public Internet Application Launch point Firewall/ OCEAN Proxy node Private Intranet Auction node Server node Server node Auction node Server node Auction node Application launch point Cenral Accounting System Figure 2.1 The OCEAN System Financial Networks

PAGE 23

13 account, but micropayments accrue to or are deducted from the trader account when a transaction is completed. The accounting system must interact with existing financial institutions to make withdrawals or deposits on behalf of its users. When the balance in the account of a resource provider reaches some threshold, they can be sent their payments. If a buyer does not have sufficient funds in their account to compensate a provider, a proposed transaction is not allowed to commence. Although a centralized accounting server might serve as a single point of failure, it presents some advantages to market participants. For one, it simplifies the financial operations of the OCEAN system. If this function were distributed across the nodes of the Network, transaction histories could get cumbersome for nodes that make extensive use of the market. Logging all transaction histories would consume precious computing resources, thereby hindering the earning capacity and productivity of a node. Also, there is the issue of trust between the financial networks and the OCEAN participants. When the financial operations are governed by a single entity, the financial markets only have to trust that entity. In a decentralized model, financial institutions are required to trust all market participants. This would present some hassle to the users of the OCEAN system. Furthermore, there is no requirement that there is a single accounting server. Note that administrative control over accounting operations are centralized, not that the accounting system runs on a single server machine. Suitable fault-tolerance can be achieved by distributing the accounting system operation among many servers, much like Buyya and Vazhkudai propose for the distributed market system of the Compute Power Market. This approach works toward achieving maximum scalability, openness and flexibility. Because any node has the ability to hold an auction, scalability issues

PAGE 24

14 associated with market servers are alleviated. Dramatic increases in the number of traders in the Network are not a problem, because at any given time, possibly every node in the network is holding an auction. The architecture provides Network participants with maximum flexibility by allowing them to assume any role at any time, even multiple roles at once. For example, a node may be holding an auction, and executing a buyer's task simultaneously. Another advantage of the peer-to-peer approach is the proliferation of the Network. It has been noted that P2P communities form by themselves [21], and further evidence of this has been seen in the past, with the rapid growth of the Napster online music exchange network [16]. However, the peer-to-peer approach has potential design issues. Parameswaran et al. notes the problem of inefficient directory lookup operations [21]. The OCEAN system encounters a similar issue. To be more specific, it is impractical for a node to communicate with all other nodes in the Network. A node should only interact with a subset of the Network when internode communication is required. However, determining to whom a node communicates with is a difficult problem. For example, say a trader is to enter a proposal to an auction. In order to improve the trader’s chance of finding a trading partner, a successful auction, i.e. one with a high rate of success for matching proposals, must be located. In that case, a well-defined rating system must exist for an auction. This problem is not addressed in this thesis. 2.2.2 Node Architecture In order to gain a more clear understanding of the auctioning capability of the OCEAN system, it is necessary to examine the architecture at the node level. The major software components of an OCEAN node are depicted in Figure 2.2.

PAGE 25

15 There are three external APIs: the Trade Proposal API, the Application Programmer API and the Node Configuration and Operation API. These provide human traders the mechanisms necessary to interact with the OCEAN node software and with the system as a whole. Each is examined further. Communication Security Naming Negotiation Task Spawning & Migration Auctioning PLUM Trader OCEAN Node Trade Proposal API App. Programmer API Node Configuration & Operation Node Node Internet Central Accounting System Figure 2.2 OCEAN Node Architecture Local Accounting

PAGE 26

16 Trade Proposal API. The Trade Proposal API allows traders to specify all of their trading information. This includes the resources they provide/request, the prices at which they would like to trade them, and so on. This API is examined extensively in Chapter 4, Trade Proposal API. Application Programmer API. The Application Programmer API contains all of the libraries that a programmer requires to create an OCEAN-enabled application. The API consists of a set of Java™ classes. Thus, the system only supports programs written in Java™. However, a major goal of the project is to eventually support applications written in other programming languages. Node Configuration and Operation API. This simple API allows a node operator to configure or dynamically change parameters that affect the operation of the node. In general, some of these parameters affect the auctioning process. This API is examined in greater depth in Chapters 5 and 6. Within an OCEAN node, there are several major software components. For brevity, not all components are described here, only the most significant ones. Each one is described below, along with their interactions with other components. Trader. This component acts as an interface between the human participants and the rest of the node components. Note that human interaction is accomplished through use of the external APIs. In effect, the Trader subsystem acts on behalf of the human users to allow them to communicate with the Negotiation, Auctioning, and Task Spawning and Migration subsystems. Auctioning. The Auctioning subsystem provides a forum in which traders meet to exchange price and resource information. Its operation is examined extensively

PAGE 27

17 throughout this thesis. The Trader subsystem must provide information to the auctioning subsystem so that trade proposals are entered in auctions. When the auctioning system needs to communicate with the auctioning systems of other nodes, it does so with assistance from the Peer List Update Manager (PLUM) and Security components. PLUM. The main purpose of the PLUM is to ameliorate the problem of directory lookup operations mentioned by Parameswaran et al. [21]. More specifically, it is impractical for nodes to communicate with one another in a broadcast fashion. Instead, they must communicate with a select few peer nodes. It is the responsibility of the PLUM component to determine a list of peer nodes with which a node will communicate. Security. The Security component plays an integral part in all communication performed between nodes. When one node communicates with another, the Security system must verify that the communication is legal. Furthermore, the Security component must protect sensitive user data when it gets transferred over the network. Communication. The Communication component has the responsibility of handling all low-level communication between nodes. It interacts with the Security Auctioning Security Communication Auctioning Security Communication Figure 2.3 Intercomponent CommunicationNodeNode

PAGE 28

18 subsystem to accomplish communication among components on different nodes. For example, when a trade proposal is propagated from one auction to another, the proposal must pass through the Security and Communication layers of each node en route to the receiving auction. This relationship is depicted in Figure 2.3. Naming. The Naming system is responsible for name resolution in the Network. The Communication system relies heavily on this component. It is undesirable for components to refer to OCEAN nodes strictly by their IP addresses. The reason for this is that IP addresses can change, not to mention that they can be obscured by firewalls. In addition, it is desirable to not only locate computers in the Network, but it is also necessary to identify other entities so that they may be located. These entities include computing tasks, data, and resources. The Naming and Communication subsystems provide this functionality: locating any OCEAN entity on the Network. Negotiation. The Negotiation component allows traders to automate the process of negotiation. The Auctioning system determines who are potential trading partners. However, the Negotiation system provides the means for traders to agree on the terms of a contract. This includes resolving conflicts that arise when a trader has many potential trading partners. Task Spawning and Migration. The Task Spawning and Migration (TSM) component is responsible for the proper dissemination and execution of computing tasks in the Network. When a contract for the execution of a computation is successfully negotiated the TSM subsystem will migrate computing tasks to remote servers through the Security and Communication layers at each node. When the server receives the

PAGE 29

19 task(s) it is to execute, they must be started and run to completion, or until some negotiated time limit has elapsed. Also, that task may spawn new tasks and so on. Local Accounting. Each node uses the Local Accounting component to communicate with the centralized accounting system. When contracts are successfully negotiated and subsequently honored (or not) the Local Accounting subsystem will ensure that the transaction is logged to the Central Accounting system. This thesis is mainly concerned with four parts of the node architecture: the Trade Proposal API (Chapter 4), the Node Configuration and Operation API (Chapters 5 and 6), Trader component (Chapter 5) and the Auctioning component (Chapter 5). It should be noted that at the time of this writing all other software components, and the Trader component to a lesser extent, remain in the design phase of the software life cycle. In fact, this thesis represents the first implementation of components of the OCEAN software system, save for a simple prototype developed with the JavaSpaces technology [27]. The interested reader is encouraged to consult the OCEAN web site [18] for ongoing developments.

PAGE 30

20 CHAPTER 3 TRADE PROPOSAL SCHEMAS 3.1 The Need for Standardization In order for trade to occur in the market, it must be possible for traders to express their proposals in formats that all OCEAN nodes can understand. In the case of resource providers, this includes information describing all of the resources at their disposal and the prices at which they will be offered. In the case of buyers, they must express their resource requirements and the prices at which they will bid for their computations to be performed. However, this is not a trivial problem, because the requirements buyers impose on providers may be complex. For example, a buyer may require sophisticated graphics hardware, a high-bandwidth network connection, or strict security protocols. Similarly, there may be many hardware and software resources that a provider makes available, and they may only be available according to predefined schedules. Thus it becomes necessary to express OCEAN trade proposals in a standardized format. By using structured trade proposal representations, any OCEAN node can parse relevant trading information from a proposal description and submit the proposal to its auction. In addition, with relative ease, tools can be developed that generate trade proposals from Graphical User Interface input, or programmatically from an API. Another benefit of standardizing trade proposal formats is realized when the OCEAN market can find no trader to honor the submitting trader's request. The trade proposal can be submitted to a competing market, in hopes that it can find a suitable match for the

PAGE 31

21 trader. Because the proposal is expressed in a standard format, the referred market would be able to parse all relevant information contained in the proposal, and attempt to find a suitable trading partner. In this case, the referring market could charge a "finder's fee," or employ a similar compensation vehicle, so that it does not give referrals on a completely altruistic basis. 3.2 XML in the Auctioning System Having established a need for the standardization of trade proposal formats, it is necessary to examine how these format schemas are constructed and used. The Extensible Markup Language, XML [33] was chosen as the framework for expressing trade proposals and their formats. This choice was motivated by two of the greatest benefits of XML. That is, XML provides a way to convey metadata, or data that describes data. Often this is called self-described data [12]. This is significant because a trade proposal document is self-descriptive. In other words, all trading data plus information describing the trading data is contained in one document. Also, because XML is entirely text-based, it is platform independent. This is important to the OCEAN system because it is to be deployed on many platforms. The subset of the XML family of technologies that is most relevant to this thesis is XML Schema [36]. At the time of this writing, this is a newly approved recommendation of the governing body of the XML standard, the World Wide Web Consortium, or W3C [35]. The schema recommendation is a replacement for the older Document Type Definition (DTD) specification, and enhances the expressive power of data description languages [12].

PAGE 32

22 The XML Schema specification defines the format taken by an XML schema. XML schemas define the legal structure of a set of XML documents. An XML document that conforms to an XML schema is said to be valid [12] with respect to the schema. From an application development standpoint, the major benefit of using a schema to define the structure of a class of documents is that applications which depend on the data contained in valid instance documents have a well-established set of rules to follow when generating or parsing the XML content. Another benefit of the Schema specification is that schemas are easily extensible; anyone may extend the schemas to suit their needs [10]. This feature contributes to the openness property of OCEAN. If any of the trade proposal schemas are extended, the new schemas can be used in place of the originals. This is because a valid instance of the new schema is technically a valid instance of the extended schema [10]. At the time of this writing, administration of the trading schema formats is controlled by the OCEAN project. However, in the future if the OCEAN project is successful, it would be desirable to relinquish administrative control of the schemas to a non-profit standards body such as the World Wide Web Consortium [35]. In that case, parts of the standard set of protocols that define OCEAN are administered by a non-partisan organization. 3.3 OCEAN Trading Schemas XML schemas were developed to provide languages for expressing trade proposals in the OCEAN system. These schemas establish the constructs that are required to describe a trade proposal in a computational market. This includes formats for expressing computing resources, prices, schedules, and other entities. There are four separate, though not necessarily independent, schema documents. Taken together, the

PAGE 33

23 schemas form a data model for conducting trade in the market. All of the complete schemas are printed in the Appendix. Note on Graphical Notation. The following sections contain figures that were generated with the XML Spy Integrated Development Environment [1]. Figure 3.1 shows a legend for some of the diagramming components used. Figure 3.1 Diagramming Notation Legend 3.3.1 Resource Schema The resource schema, listed in section A.1 of the Appendix, defines constructs for commonly used resources in any computational market. In many cases, describing a resource is in part dependent upon the notion of a measurement. In the OCEAN schemas, a measurement is an element with attributes for the scalar measurement quantity and its associated units, according to recommendations given by Martin et al. [12]. The attribute “value” is of decimal type, and “units” is a string. In general an instance of a measurement appears in the following form. Optional Element Required Element Begin a choice among elements Begin a sequence of elements

PAGE 34

24 Following are the defined resource constructs and descriptions of the data types that define them. A description of the data model for each data type is given where necessary. Examples of valid instances of data types are given where relevant. CPU. CPUType is the data type for describing CPUs. The data contained in a CPUType are an optional Platform element and an optional ClockSpeed measurement element. ClockSpeed is a measurement with units of “GHz” or “MHz”. Platform is an element that contains an Operating System and an Architecture construct. Useful extensions of the data type could include cache size and benchmark ratings. Figure 3.2 shows a diagram of the structure. Figure 3.2 CPU Structure Operating System. OSType is the data type for describing an Operating System. This type contains an attribute “value” that identifies the Operating System. Legal values for “value” are “Windows,” “Solaris,” and “Linux.” The type also contains an optional attribute, "version," for specifying the Operating System version. Useful extensions to this type would include more operating systems, and define the legal strings for Operating System version. Architecture. ArchType is the data type for describing CPU architecture. This type contains an attribute "value" identifying the hardware architecture. Legal values for “value” are “x86” and “Sparc”. Useful extensions to this type would include more

PAGE 35

25 hardware architectures, such as PowerPC, MIPS, and so on. An example of an element of type CPUType follows. Memory. MemoryType is the data type for describing a measurement of memory. The “units” attribute must be one of "TB," "GB," "MB," or "KB." Note that a MemoryType does not have to imply main memory, only a memory measurement. An example element of type MemoryType appears as follows. Graphics Hardware. GraphicsHWType is the data type for describing graphics hardware. This type contains one element, VideoMemory of type MemoryType Below is an example of an element that conforms to type GraphicsHWType A useful extension of the type could include manufacturer and product number. Network Connection. NetworkConnectionType is the data type for describing a network connection. It contains one element, of type BWType The BWType data type describes network bandwidth. It is a measurement, with legal “units” attribute values of "Mbps" and "Kbps". This data type does not distinguish between bandwidth to the network backbone or to the Local Area Network; a useful extension

PAGE 36

26 would include such definitions. The example below depicts an element of type NetworkConnectionType Data Object. A Data Object is a general-purpose description for a collection of data. DataObjectType is the data type for describing a Data Object. It contains a DataObjectID element, which has a string value. The string value of DataObjectID contains an OCEAN data object name, which identifies it uniquely on the Network. At the time of this writing, its proposed format is described in [19]. A DataObjectType also has an optional Size element, which is of type MemoryType Below is an element of type DataObjectType ocean://www.ocean1.com/@oceanapp1/dataobj1 3.3.2 Price Schema The price schema, listed in section A.2 of the Appendix, defines the constructs that traders use to specify the prices of commodities in the market. Following are the data types and descriptions of data models for each price construct. Legal examples are provided where relevant. Currency Amount. A Currency Amount is commonly used by price constructs, and is defined by the CurrencyAmountType A Currency Amount is a quantity of some currency. For example, 2 US Dollars (USD), or 1 British Pound (GBP). This is similar to a measurement as described in Section 3.3.1, but instead of an attribute named

PAGE 37

27 "units," it has an attribute named "Currency" to identify the currency used. At the time of this writing, the “Currency” attribute is a string type, but in the future will be restricted to recognized 3-letter currency codes. An element of type CurrencyAmountType appears below. Flat Price. A Flat Price, described by the FlatPriceType data type, represents a time independent price in the market. This is distinct from a time dependent price, which is a price per unit time. It should be noted that a Flat Price only makes sense by itself if some time value is associated with the price. For example, a seller indicates a time limit on the use of its resources if specifying a Flat Price. This would ensure that a buyer’s computation does not take over a seller’s resources for an exorbitant amount of time. This should be a future extension of the type. A flat price has one child element, CurrencyAmount of type CurrencyAmountType An example of a FlatPriceType appears below. Time Dependent Price. Described by the TimeDependentPriceType data type, this is a time dependent price in the market. A time dependent price is a currency amount per some span of time. For example, 0.01 USD per 1 second is a time dependent price. The data type has two child elements. One is a CurrencyAmount of type CurrencyAmountType The second is a Timespan element, of type duration The duration type is a standard XML Schema data type that defines a span of time.

PAGE 38

28 ISO 8601 Date and Time Formats [10], specifies its structure. Below is an element of type TimeDependentPriceType PT1.0S Figure 3.3 Price Structure Price. The data type Price defines the Price construct. A diagram of the elements and types involved with the construct is given in Figure 3.3. The data type has one of three possible child elements. The child can be FlatPrice of type FlatPriceType Also the element can be a TimeDependentPrice of type TimeDependentPriceType Or, the element can be a combination of the other two price descriptions, a FlatPlusTimeDependentCombo It has two elements, one of type FlatPriceType and one of TimeDependentPriceType A FlatPlusTimeDependentCombo element would be useful in specifying a price that consists of an initial fee, plus rental fees. Defining the Price data type gives a uniform way for dependent schemas and dependent applications to access one Price element

PAGE 39

29 without being concerned with the underlying price type. An interesting extension to the Price construct could include a definition of a payment plan. For example payment may be required up-front, or upon completion of a computation. Below is an element of type Price Schedule. The Schedule construct also has a data type that shares its name. Its purpose to define an availability or reservation schedule. This data type consists of a collection of ScheduleItem elements, explained below. The structure of the two constructs is shown in Figure 3.4. Figure 3.4 Schedule Structure Schedule Item. The Schedule Item construct is described by a ScheduleItem element. This element contains a start time plus a choice between an end time or time span. Taken together, the two elements describe the starting time and the duration of a schedule item. The startTime element is of type dateTime Like the duration type, dateTime is specified by ISO 8601 [10]. The Timespan element is of type duration The endTime element is of type dateTime as startTime is. When endTime is used, the duration is simply the difference between startTime and

PAGE 40

30 endTime Following is an example element of type Schedule with two elements of type ScheduleItem 2001-10-12T12:00.0-5:00 2001-10-12T18:00.0-5:00 2001-10-13T01:00.0-5:00 PT8H30M It should be noted that although there is a defined construct for a Schedule, it remains unsupported in the Auctioning system. This is due mainly to the lack of a welldefined scheduling component in the current version of the OCEAN software system. 3.3.3 Buyer Schema The buyer schema, listed in section A.3 of the Appendix, defines the constructs used to produce a proposal for a buyer. The schema references data types defined in the price and resource schemas. Following are the defined buyer constructs and descriptions of the data types that define them. A description of the data model for each data type is given, with examples of valid instances of data types where relevant. Buyer. The BuyerType data type defines the top-level construct of the buyer schema, the Buyer element. Note this does not represent a buyer per se, but rather a

PAGE 41

31 buyer’s proposal document. Its structure is depicted in Figure 3.5. The first two elements contained in the BuyerType are the BuyerID element and Address element, both of type string. The BuyerID is meant to contain the buyer's identification number within the OCEAN accounting system. The Address element is meant to contain the unique OCEAN node name of the node from which the trade request originated. Its exact format is not yet defined. This element indicates to whom replies for the trade request should be directed. Although the BuyerID and Address elements are straightforward, the BuyerType also contains an unlimited number Bid Item constructs. These are the elements that will describe bids in the market. A useful extension of the data type would include elements that describe a proposal’s path through the Network. Also, appearing below is a skeleton of a Buyer element. Figure 3.5 Buyer Structure

PAGE 42

32 7864093
ocean://www.oceanlaunch1.com/@app1
... ...
Bid Item. The Bid Item construct, defined by the BidItemType element, gives a choice between all supported entities that can be bid upon. As of this writing, the BidItemType indicates that a bid may be submitted for a Task List, Task Group, Resource Bid, Resource Future, or Resource Option. Each of these is discussed below. The structure of the BidItemType is shown in Figure 3.5. However, before each of these is examined, it is necessary to explain Tasks and related constructs in the OCEAN system. 3.3.3.1 Tasks, Task Lists and Task Groups In the OCEAN system, a Task is the basic unit of work that an OCEAN application performs. It forms the basis of program migration in the OCEAN software system. Essentially, a Task is a program (typically a thread) that can be migrated from one node to another and executed at the receiving node. OCEAN applications typically implement many Tasks, each performing some useful unit of work, as part of some larger collective effort. Therefore it is necessary to include in the schemas methods to group Tasks together. There are two types of Task collection descriptions. A Task List is set of Tasks, each of which is bid upon and migrated separately. This type of description is useful if

PAGE 43

33 each Task is computationally complex or if the bid price of each Task can be determined with ease. A Task Group is a group of Tasks that get bid upon and migrated as a whole. This description is useful if there are many small Tasks that can be executed on the same host, or if the bid price can only be determined for a group of Tasks. As another example, a Task Group is useful in a subcontracting model. This computing model works as follows. A Task Group is bid upon and negotiated for. The trader who obtains the Task Group then partitions the Task Group into a Task List, or into smaller Task Groups. Then the newly partitioned units are auctioned and migrated at a collectively lower bid price than the original. Thus the original seller earns a profit while avoiding the work involved. Below are descriptions of the Task related constructs. Figure 3.6 Task Structure Task. The TaskType data type describes the Task construct. Its structure is shown in Figure 3.6. The first element contained in a TaskType is the TaskID This has a string value, which is intended to be the unique OCEAN task name that identifies it

PAGE 44

34 on the Network. There are two unbounded lists of elements. The first is a list of DataObject elements of type DataObjectType Each DataObject element describes a Data Object that gets migrated with the task. The other list is an unbounded number of Resource elements, which is actually contained within the RequestedItems element. A Resource element, which represents a Task's resource request, is of type ResourceRequestType This type is explained in the next section. The TaskType also contains optional elements for Complexity of unspecified type, and a ReservationSchedule element, which is of type Schedule An element of type TaskType appears below. ocean://www.oceanapp1.com/@job1/task2 Complexity – this construct is unspecified, and remains reserved for future use. The intention is to provide a description of the algorithmic complexity of a Task. This would be useful when attempting to match bids of unlike price descriptions. For example, a buyer values a Task at 0.01 USD per second. A seller offers a computer for 1 USD. This could be a match, if the buyer indicated that the complexity of the computation and the size of the data set guarantee that the computation executes for at least 100 seconds. However, this interaction should not take place unless the seller

PAGE 45

35 indicates a time limit for their resource availability. Otherwise, the buyer can monopolize the seller’s resources at an unfair discounted rate. This functionality remains unsupported at the time of this writing. Note that in the absence of a Complexity description, trade proposals of unlike price type cannot be compared. Therefore matching trade proposals with unlike price types remains unsupported in the Auctioning subsystem. Figure 3.7 Task List Structure Task List. The TaskListType data type describes a Task List. Its structure is depicted in Figure 3.7. A TaskListType has an unbounded list of TaskListItem elements. A TaskListItem contains three elements: a Task of type TaskType a BidPrice of type Price and the bid identifier BidID of string type. The format of a Bid ID is not defined at the time of this writing. An example of a TaskListType skeleton appears below. ... ... bid21@128.227.242.3 ...

PAGE 46

36 Task Group. The TaskGroupType data type describes a Task Group. Its structure is depicted in Figure 3.8. The TaskGroupType has an unbounded number of Task elements, of type TaskType followed by a single BidPrice element, of type Price and the bid identifier, BidID An example of a TaskGroupType skeleton appears below. ... ... ... bid21@128.227.242.3 Figure 3.8 Task Group Structure 3.3.3.2 Resource Requests The notion of a Resource Request is intricately woven into the buyer schema. Every element (Task Group, Resource Bid, etc.) that forms a bid in the market is allowed to request a resource. Following are the constructs with data types that can be used to make a Resource Request. Resource Request. The ResourceRequestType data type describes the Resource Request construct. A Resource Request can be made on the following constructs: Stable Storage, CPU, Memory, Graphics Hardware, Network Connection,

PAGE 47

37 Data Object, and Library. The ResourceRequestType contains a Type element, which contains a choice of an element associated with one of the constructs as described below. The CPU, Memory, Graphics Hardware, and Network Connection constructs are used in the manner described in section 3.3.1. New constructs are defined as follows. Stable Storage. The StableStorage element describes a request for stable storage. This element contains one element, RequestAmount of type MemoryType Library. The Library element, of string type, describes a software library that the application requires. Examples include Secure Sockets Layer (SSL) and OpenGL. 3.3.3.3 Resource Bids, Resource Futures, and Resource Options The other types of Bid Items in the market are Resource Bids, Resource Futures and Resource Options. A Resource Bid is simply a bid on a set of resources. It has no other context associated with it, such as a Task. An example use of this construct is to request space on a stable storage unit. A Resource Future is analogous to a futures contract in a financial market. The Chicago Board of Trade [5] defines a futures contract as "A legally binding agreement, made on the trading floor of a futures exchange, to buy or sell a commodity or financial instrument sometime in the future." A Resource Future in OCEAN takes on a similar meaning. It is the purchase of a collection of resources at some time in the future. A Resource Option is analogous to an option contract in financial markets. The Chicago Board of Options Exchange [4] defines an option as "the right, but not the obligation, to buy or sell a stock (or other security) for a specified price on or before a specific date." A Resource Option in the OCEAN system takes on a similar meaning. A

PAGE 48

38 Resource Option is the right, but not the obligation, to purchase a set of resources for a specified price on or before a certain date. Resource Options remain an unspecified type, reserved for future use. Resource Futures, though they have a defined data type in the schema, are unsupported by the Auctioning system. This is mainly due to the lack of a well-defined scheduling component in the OCEAN software system. Following are descriptions of the Bid Item constructs that do not require a Task construct. Resource Bid. The ResourceBidType data type describes a Resource Bid. A ResourceBidType contains a RequestedItems element, which contains an unbounded number of Resource elements of type ResourceRequestType The other elements contained are a BidPrice of type Price and the bid identifier, BidID Resource Future. The ResourceFutureType data type describes a Resource Future. It is actually an extension of the ResourceBidType with the addition of a ReservationSchedule element, of type Schedule Resource Futures remain unsupported in the Auctioning system due to a lack of a Scheduler component. 3.3.4 Seller Schema The seller schema, listed in section A.4 of the Appendix, establishes the rules that define a proposal for a seller. Like the buyer schema, the seller schema references data types defined in the price and resource schemas. Following are the defined seller constructs and descriptions of the data types that define them. Seller. The Seller element serves as the top-level construct. It is pictured in Figure 3.9. It contains two other elements. First, the SellerID like the BuyerID is

PAGE 49

39 an element with a string value that identifies the seller. The other element is SaleableResourceUnits This element contains an unbounded number of SaleableUnit elements. Figure 3.9 Seller Structure Saleable Unit. A Saleable Unit is a collection of resources that are for sale at some price. The construct defines an offer in the market. The SaleableUnit element is composed of an unbounded number of Provided Resources. These are given by Resource elements of type SellerResourceType and are examined below. A SaleableUnit also contains a single AskPrice element, of type Price and an AskID element of string type. The AskID uniquely identifies the trade proposal in the market. Ask ID format is undefined at the time of this writing. Below is an example of a SaleableUnit skeleton. ... ... ... ask21@128.225.21.2 Provided Resource. The SellerResourceType data type describes a Provided Resource. A Provided Resource may be one of the following constructs: CPU, Memory, Graphics Hardware, Stable Storage, Data Object, Network Connection, and

PAGE 50

40 Library. The SellerResourceType contains a Type element, of type SellerResourceTypeEnum The data type also contains a ResourceID element, whose string value identifies it on the Network, plus an optional AvailabilitySchedule element, of type Schedule Just as in the case of buyers, the Schedule construct is not supported in the Auctioning system. The SellerResourceTypeEnum data type contains a choice of an element associated with one of the constructs as described below. The Data Object, Network Connection, Library, Memory, and Graphics Hardware constructs are used as defined in section 3.3.1. The exceptions to those descriptions follow. CPU. The CPU element is of type CPUSellerType. It is very similar to CPUType defined in section 3.3.1; the only difference is that all data is required. In the resource schema, many elements are optional. This is not so in the seller schema. Resources should be specified with as much detail as possible because buyers may need to be very selective when choosing a trading partner. Stable Storage. The StableStorage element describes an available storage unit. It has a required AvailableSpace element; it is a memory measurement of the available space on the data store.

PAGE 51

41 CHAPTER 4 TRADE PROPOSAL API 4.1 Introduction Having examined the OCEAN Trade Proposal schemas themselves, it is necessary to examine how they are used in applications. The first part of this equation is the generation of documents that conform to the schemas. The consumption of documents is examined in the next chapter. In general XML is not easily read and written by humans, and OCEAN trade proposal documents are no exception. The Trade Proposal API serves as a wrapper for OCEAN Trade Proposal documents. To put it another way, the API is an interface to the trade proposal schemas. By providing application programmers and resource providers this wrapper functionality, the individuals involved in submitting trade proposals in the OCEAN system are relieved of the burden of creating XML documents directly. To directly produce the XML content of a valid trade proposal would prove to be tedious and error prone. It should be noted that the Trade Proposal API used by resource providers is intended to be used as an API to be called by more user-friendly interfaces, such as an HTML form or other GUI. Trade proposals that originate from sellers are more static, in a sense, than buyer-originated proposals. By static, it is meant that relevant information is known ahead of time. The number of sellers in the market is expected to be much greater than the number of buyers. This observation stems from the properties of the

PAGE 52

42 market. Anyone with a computer can be a seller, but buyers will usually have complex, highly parallel computations or huge amount of data to store—a much smaller percentage of the human population. It is therefore in the best interests of the market to provide sellers simple facilities for entering trade proposals. Buyers, on the other hand, will need to generate trade proposals in a more dynamic fashion. The resources required for a buyer's computation may depend on many factors that are not known at compile time. In general, the buyer will not know what resources are available ahead of time. For example, resource requests may be dependent upon the size of a data set that has not been generated. Also, market conditions may dictate what resources are available at a given time. The buyer may need to lower the resource requirement specifications or adjust bidding prices to be able to find a trading partner. Thus, it is imperative that buyers have mechanisms to dynamically generate trade proposals at run time. 4.2 Java and XML Java and XML are complementary technologies. Sun Microsystems advertises that XML and Java are a perfect match, giving applications “portable code, portable data” [26]. McLaughlin makes the observation that without programs such as parsers, XML is essentially “vapor-ware” [13]. The OCEAN Trade Proposal API is a testament to this. Without facilities to generate and consume trade proposals, the Trade Proposal schemas are not useful. All of the API implementations in this thesis are dependent upon JAXP, the Java API for XML Processing [28]. JAXP is actually a collection of interfaces that supports the parsing, manipulation and transformation of XML documents. It employs a

PAGE 53

43 pluggable architecture that allows different implementations of its interfaces to be interchanged dynamically. Application code always uses classes or interfaces in JAXP, without any knowledge of the underlying implementation. The implementations used for this thesis were developed by the Apache XML project [2]. The motivation behind this choice is that Apache has extensive support for XML Schemas, which at the time of this writing is a newly approved W3C recommendation [36]. However, it should be noted that any implementation that supports the XML namespaces and XML schema technologies can be easily substituted, without changing or recompiling the Trade Proposal API source code. The processing of XML documents through JAXP is accomplished according to three XML specifications. These specifications are the Document Object Model (DOM) [32], Simple API for XML (SAX) [14], and XML Stylesheet Language Transformations (XSLT) [34]. The OCEAN Trade Proposal API makes extensive use of the DOM for creating documents. The auctioning system makes use of SAX for document validation and the DOM for parsing. XSLT is used to transform node trees to text in the Auctioning system. The use of the DOM in the API is examined in more detail in the next section. 4.3 The Document Classes The Document classes establish the basis of the Trade Proposal API by encapsulating the XML-based OCEAN trade proposal documents. As mentioned previously, these classes form a wrapper around the trade proposal documents. This approach benefits the traders in several ways. The resource providers and application programmers do not have to produce XML content directly; this is an error prone and tedious process. An alternative to writing raw XML content is to programmatically

PAGE 54

44 produce it using an implementation (e.g. JAXP) of the DOM. This is less tedious, but can still be error-prone because it is possible to produce an invalid document. Also, for programmers who are unfamiliar with XML and the DOM, the learning curve required to become proficient with these technologies would serve as a hindrance to the success of the OCEAN market. After all, in order for the market to be successful, it must be possible for traders to participate with relative ease. The trade proposal API accomplishes this by providing an extensive, but straightforward library that places a layer of abstraction between the DOM and an OCEAN market participant. The main purpose of the DOM is to define a standard functionality for the navigation and manipulation of the content and structure of XML documents [12]. This is accomplished by representing an XML document as a node tree In the DOM, every type of XML content in the document is considered a node—elements, white space, attributes, comments, etc. By accessing the tree structure, new nodes can be added and existing nodes can be found without searching the text file in a top-down fashion. The Trade Proposal API and auctioning system make extensive use of this. Nearly all use of the DOM is actually performed through a utility class, XMLutils The abstract parent class for encapsulating a trade proposal is OCEANDoc which is extended by the JobReqsDoc and OCEANResDoc concrete classes. The JobReqsDoc and OCEANResDoc classes encapsulate buyer and seller proposals, respectively. A Unified Modeling Language (UML) diagram of the class structure is shown in Figure 4.1. Readers unfamiliar with the UML diagramming notation are directed to [17].

PAGE 55

45 At the heart of the OCEANDoc class is a Document the JAXP interface that represents the node tree of an XML document. Not only does the Document interface serve as the node tree, but it is also serves as the context in which all document constructs are created. The reason for this is that everything defined in JAXP is an abstract class or an interface. Thus nothing can be instantiated directly. Instead, JAXP makes use of +isValid() : boolean +createCPU() : CPU +createDataObject() : DataObject +createGraphicsHW() : GraphicsHW +createLibrary() : Library +createMemory() : Memory +createNetworkConnection() : NetworkConnection +createStableStorage() : StableStorage +createFlatPrice() : Price +createTimeDependentPrice() : TimeDependentPrice +createSchedule() : Schedule +createScheduleItem() : ScheduleItem +createTimespan() : Timespan -xmlFile : File -xmlFileName : String -theDoc : Document -rootNode : Element -validating : boolean OCEANDoc +addBidItem(in bi : BidItem) +addTaskGroup(in tg : TaskGroupDescription) +addTaskList(in tl : TaskListDescription) +addResourceBid(in rb : ResourceBid) +createTaskDescription() : TaskDescription +createTaskGroupDescription() : TaskGroupDescription +createTaskListDescription() : TaskListDescription +createResourceFuture() : ResourceFuture +createResourceBid() : ResourceBid +createDataObjectRequest() : DataObject -address : String -buyerID : String JobReqsDoc +createSaleableUnit() : SaleableUnit +addSaleableUnit(in su : SaleableUnit) -sellerID : String OCEANResDoc Figure 4.1 Document Class Structure

PAGE 56

46 Factory Patterns [11] to realize construction of implementations of crucial interfaces like Document The signature of Document includes methods for creating all standard XML constructs, such as elements, comments, attributes and so on. So, once an instance of Document is obtained, it is then possible to construct the XML content via the other DOM interfaces, such as Element and Attribute This property of JAXP and DOM is the reason why constructs of the Trade Proposal Schemas must be instantiated through the OCEAN document classes. This is examined further in the next section. The remaining attributes of OCEANDoc are straightforward. A File instance is kept, along with a String indicating the name of the file that holds the XML content. It is worth noting that documents will generally not be written to disk. However, the File is kept in case the need arises. A boolean value, isValidating indicates whether the document is to be validated with respect to its schema. Similarly, the isValid() method determines whether the document is valid with respect to its schema. The methods for each document class involve creation and addition of the toplevel schema constructs. For example, create a SaleableUnit through the OCEANResDoc.createSaleableUnit() method, and add the unit to the document via the OCEANResDoc.addSaleableUnit() method. The JobReqsDoc contains similar methods for creating and adding its top-level constructs such as Task Lists and Task Groups. 4.4 Creation and Manipulation of Schema Constructs Upon further examination of the signatures of the document classes, all other attributes and methods are concerned with the schema constructs described in Chapter 3. For each major construct in the proposal schemas, there is an associated class in the

PAGE 57

47 proposal API. Similar to the way the Document classes encapsulate entire XML trade proposal documents, each schema construct class encapsulates the XML representation of its node in the document tree. The bulk of the work regarding construction of XML documents is actually performed by these classes. In reality, the Document classes main responsibilities are to provide ways to construct these objects and to delegate document construction to these objects appropriately. Recall that the Document interface serves as a context in which all XML document constructs are created. One consequence of this is that it is forbidden to attach a node created by one Document implementation to a node created by a different Document instance. In other words, the same Document implementation must create all nodes in an XML document. In the Trade proposal API, requiring that all schema construct objects are instantiated by the document to which they belong enforces this rule. In fact all constructors of these classes are protected and thus accessible only to members of the package or to classes that inherit them. All schema constructs share a common abstract base class, OCEANDocNode This class has two very important attributes, rootNode and doc of types Node and Document respectively. rootNode is the root of the construct’s subtree in the XML document, and can be obtained via the getRootNode() method. doc is the Document instance in which the construct is created. For a given trade proposal, all of the schema construct classes share the same reference to a Document instance. The Document class that creates the schema construct always passes its own Document instance to the constructor of the class to ensure the “single Document rule” is not violated.

PAGE 58

48 The abstract buildNode() method in OCEANDocNode is the method that implements document creation. Its purpose is to construct the node tree of the class, based at rootNode given the state of the class. If the state of the class cannot produce a valid representation with respect to the trade proposal schemas, an exception of type OCEANDocException is to be thrown. Due to the fact that buildNode() is abstract any class that implements OCEANDocNode is required to implement this method. While OCEANDocNode defines the framework for building the content of a schema construct, the implementing classes must also provide an interface to the data model of their particular construct. This means that for any schema construct, the corresponding API class must provide access to its data model via class methods and attributes. In general, any data that a schema construct contains is kept as a protected attribute of the class representation. That attribute can be manipulated through public get and set methods, or set at object construction time. The API classes can be grouped into like units according to their function in the proposal schemas. The Resource class serves as the abstract base class for all resources. It inherits from OCEANDocNode adding several attributes and methods. The two methods, compareTo() and isCompatible() are used in the Auctioning sysem. There are four attributes kept by all Resource implementations. resourceID is the resource identifier on the network, used mainly by the Auctioning system. resourceType is the type of resource; this value always is the name of the implementing class. schedule is an optional Schedule associated with the resource.

PAGE 59

49 When the requested flag is true the resource is requested by a buyer; when false the resource is provided by a seller. The API includes seven implementations of the Resource class. They are CPU DataObject GraphicsHW Library Memory NetworkConnection and StableStorage These classes represent the most commonly used computing resources. However, it should be noted that Resource is freely extendable, as are the given implementations. The UML class diagram appears in Figure 4.2. Each Resource implementation is defined by its attributes. Attributes can be set at object construction time or by the set method of that attribute. For example, the following code creates a CPU running Windows 2000 on an x86 architecture rated at 900 MHz, and adds it to a Saleable Unit. OCEANResDocresDoc=newOCEANResDoc; SaleableUnitsu=resDoc.createSaleableUnit(); CPUcpu=resDoc.createCPU (“x86”,”Windows”,”2000”,900.0f,CPU.UNITS_MHZ); su.addResource(cpu); It should be noted that the addition of su to resDoc in the above sample would throw an OCEANDocException The Saleable unit, as defined by its current state, is not valid because no price has been specified. The next group to be examined is the tasks. A UML class diagram of the task description system is given in Figure 4.3. The relationship between the trade proposal schemas and the Java API classes is easily seen here. Recall from section 3.3.3 that a BidItemType can contain a Task Group, a Resource Bid, a Resource Future or a Task List. The one difference in the API is that TaskListDescription does not inherit from BidItem This is a subtle, albeit important difference. In the Java

PAGE 60

50 #buildNode() +getRootNode() : Node -rootNode : Node -doc : Document OCEANDocNode #buildNode() +compareTo(in o : Object) : int +isCompatible(in r : Resource) : boolean -resourceID : String -resourceType : String -schedule : Schedule -requested : boolean Resource #CPU(in n : Node, in d : Document) #buildNode() +compareTo(in o : Object) : int +isCompatible(in r : Resource) : boolean -os : String -osVersion : String -arch : String -clockSpeedVal : float -clockSpeedUnits : int CPU #Memory(in n : Node, in d : Document) #buildNode() +compareTo(in o : Object) : int +isCompatible(in r : Resource) : boolean -memValue : float -unitsVal : int Memory #GraphicsHW(in n : Node, in d : Document) #buildNode() +compareTo(in o : Object) : int +isCompatible(in r : Resource) : boolean -videoMem : Memory GraphicsHW #StableStorage(in n : Node, in d : Document) #buildNode() +compareTo(in r : Resource) : int +isCompatible(in r : Resource) : boolean -availSpace : Memory -totalSpace : Memory -reqAmt : Memory StableStorage #DataObject(in n : Node, in d : Document) #buildNode() +compareTo(in o : Object) : int +isCompatible(in r : Resource) : boolean -dataObjName : String -objSize : Memory -isResource : boolean DataObject #Library(in n : Node, in d : Document) #buildNode() +compareTo(in o : Object) : int +isCompatible(in r : Resource) : boolean -libName : String Library #NetworkConnection(in n : Node, in d : Document) #buildNode() +compareTo(in o : Object) : int +isCompatible(in r : Resource) : boolean -bwVal : float -unitsVal : int NetworkConnection Figure 4.2 Resource Classes

PAGE 61

51 API, and later in the Auctioning system, a BidItem is an entity that is to be bid upon. However in the buyer schema, a BidItemType is a convenient way to provide a choice among several constructs. By examining the diagram, it can be seen that bids can be entered for Resource Bids, Resource Futures, Task Groups and Tasks. However, Tasks can never be bid upon if they are part of a Task Group. Only if they are part of a Task List can Tasks be bid #buildNode() +getRootNode() : Node -rootNode : Node -doc : Document OCEANDocNode +getResources() : TreeSet #buildNode() BidItem #TaskListDescription(in n : Node, in d : Document) #buildNode() +addTaskPricePair(in t : TaskDescription, in p : Price) -Prices : Vector TaskListDescription #TaskDescription(in n : Node, in d : Document) +getResources() : TreeSet #buildNode() +addResource(in r : Resource) +addDataObject(in dataObj : DataObject) -taskID : String -resourceReqs : Vector -dataObjects : Vector -schedule : Schedule TaskDescription #TaskGroupDescription(in n : Node, in d : Document) +getResources() : TreeSet #buildNode() +addTaskDescription(in td : TaskDescription) +getTaskDescriptions() : Vector -bidPrice : Price TaskGroupDescription #ResourceBid(in n : Node, in d : Document) +getResources() : TreeSet #buildNode() +addResource(in r : Resource) -bidPrice : Price -resourceReqs : TreeSet ResourceBid #ResourceFuture(in n : Node, in d : Document) #buildNode() -schedule : Schedule ResourceFuture Figure 4.3 Task Related Classes

PAGE 62

52 upon individually. As with the other classes previously mentioned, the Task related classes provide access to their data model. For example the following code shows how to create a TaskDescription and add it to a TaskGroupDescription JobReqsDocjrd=newJobReqsDoc(); TaskGroupDescriptiontgd= jrd.createTaskGroupDescription(); TaskDescriptiontd=jrd.createTaskDescription(); tgd.addTaskDescription(td); The last group to be examined is the Price group. Price is an abstract class, with concrete implementations corresponding to the three types of prices that may be specified in the schemas: FlatPrice TimeDependentPrice and FlatPlusTDPrice A UML class diagram of these components is given in Figure 4.4. The price classes are not overly complex; for the most part an amount and a #buildNode() -amount : float -currency : String Price #buildNode() +getRootNode() : Node -rootNode : Node -doc : Document OCEANDocNode #FlatPrice(in n : Node, in d : Document) #buildNode() FlatPrice #TimeDependentPrice(in n : Node, in d : Document) #buildNode() -tSpan : Timespan TimeDependentPrice #FlatPlusTDPrice(in n : Node, in d : Document) #buildNode() -flatPrice : FlatPrice -tdPrice : TimeDependentPrice FlatPlusTDPrice Figure 4.4 Price Classes

PAGE 63

53 currency define them. However, a TimeDependendentPrice object requires an additional piece of information: a Timespan object that expresses the time span that this price covers. For example 1 USD dollar per 1 minute. This should not be a surprise; it is very similar to the specification established by the price schema. Having examined each of the major groups of API classes, it is useful to assemble a concrete example to illustrate its proper use. The following sample creates a saleable unit with a CPU, Main memory, and Stable Storage Unit, sets a price on the unit, and adds the unit to a seller document. importocean.doc.*; try { OCEANResDocresDoc=newOCEANResDoc(); SaleableUnitsu=resDoc.createSaleableUnit(); //x86machine,Linuxversion2.4,1.2GHzclockspeed CPUcpu=resDoc.createCPU ("x86","Linux",1.2f,CPU.UNITS_GHZ); //toString()identifiestheresourcewithinanauction cpu.setID(cpu.toString()); su.addResource(cpu); //128MBofRAM Memorymem= resDoc.createMemory(128.0f,Memory.UNITS_MB); mem.setID(mem.toString()); su.addResource(mem); //200MBavailable StableStoragestable= resDoc.createStableStorage (resDoc.createMemory(200.0f,Memory.UNITS_MB)); stable.setID(stable.toString()); su.addResource(stable);

PAGE 64

54 //oneminute,0seconds TimespantSpan=resDoc.createTimespan(1,0f); TimeDependentPricetdp= resDoc.createTimeDependentPrice (1.0f,"USD",tSpan); su.setPrice(tdp); resDoc.addSaleableUnit(su); System.out.println(resDoc.getStringContent()); } catch(OCEANDocExceptionode) { //dosomethingusefulwiththeexception } The execution of this sample produced the following document. ocean.doc.CPU@7ae3c6 ocean.doc.Memory@7d13b5

PAGE 65

55 ocean.doc.StableStorage@18f375 PT1M 127.0.0.1:ocean.doc.SaleableUnit@67d940


PAGE 66

56 CHAPTER 5 AUCTIONING 5.1 Introduction In order for any type of market to be successful, it must provide a forum in which traders can meet one another, exchange information, and agree to trade. The OCEAN system is no different in this respect. However, the properties of an automated computational market present some unique problems regarding market operation that must be resolved. For reasons discussed in section 2.2.1, the OCEAN system design is a distributed peer-to-peer architecture. This architecture does provide advantages, but difficulties arise in coordinating actions among market participants. For one, the trading forum is not a well-defined marketplace. A client-server architecture, in which the marketplace runs as a server process and market participants are clients, would be an example of a well-defined marketplace. Instead, the OCEAN marketplace is defined by a set of active nodes, where each node communicates with a subset of other nodes in a collaborative effort to implement the functionality of the market. Trade occurs in the market through distributed auctions. The auction type that is currently supported is a double auction [8, 23]. The reason for this classification is that both buyers and sellers submit bids and offers that are ranked from lowest to highest [23]. However, the Auctioning system implements the Factory Method design pattern [11] so

PAGE 67

57 that a different type of auction may be used in a pluggable fashion. This is examined further in section 5.3. 5.2 Proposal Propagation With the formation of trade proposals having been discussed at great length, it is now necessary to examine how those proposals are used within the context of the Auctioning system. Any node has the ability to hold an auction at a given time. Thus the auctioning process actually consists of many small auctions. Alternatively, the process could operate as one large auction, with all participating nodes communicating with one another to coordinate their actions. In such a system, traders are likely to find optimal and near-optimal trading partners. However, in a system like OCEAN, where the potential number of participants is staggering, this type of solution is impractical because of the communication and coordination involved. The key for OCEAN traders is to enter their proposals in a limited number of auctions while still finding optimal or near-optimal trading partners. This thesis is concerned with the implementation of auctions at the node level, and the propagation of trade proposals from one node to another. It should be noted that the optimal propagation of trade proposals requires the use of another software component, the PLUM (Peer List Update Manager), which is still being defined at the time of this writing. The PLUM determines the peer nodes with which a node communicates, known as the known node list In the context of the Auctioning system, the PLUM determines to which auctions a trade proposal will be submitted. Although the PLUM is not fully implemented, trade proposal dissemination does occur properly. However, the known node list must be randomized or determined manually.

PAGE 68

58 There is a tradeoff involved in the design of the trade proposal submission process. On one hand, the proposal cannot be submitted to an exorbitant number of auctions. On the other hand, the proposal must be submitted to a sufficient number of auctions to allow traders a chance to find the best possible price. The propagation algorithm is as follows. Each propagation step is referred to as a hop and the maximum number of propagation steps is the maximum hops The maximum hops are configurable by traders and node operators. For every propagation, the current number of hops, the hop count is sent along with the trade proposal. Initially, the hop count is equal to the maximum hops. The hop count gets decremented, and if it is at least zero, the proposal and the hop count are sent to all of the nodes in the known node list. The same process is repeated at all Auction Auction Auction Auction Auction Auction Auction Auction Auction Auction Auction Auction Auction Auction Auction hop count = 3 hop count = 2 hop count = 1Figure 5.1 Trade Proposal Propagation

PAGE 69

59 receiving nodes. In effect, the receiving node is informed of the number of hops that remain to be propagated. When the number received is zero, the proposal will not propagate further from that node. This process is illustrated in Figure 5.1, for maximum hops equal to 3, and each node with two nodes in its known node list. Note that the uniformity in known node count does not have to be the case (and rarely would be). Whenever a node receives a trade proposal, the proposal is entered in the node’s auction, if one is in progress. Note that it is possible for a node to receive a redundant proposal, one that it is currently trying to match. These proposals do not get entered in an auction and are not propagated, but the node does receive them. Traders in an auction are matched based on their willingness to trade and the compatibility between resource requests and available resources. The willingness to trade is determined by prices; the most willing buyer is bidding at the highest price while the most willing seller is bidding at the lowest price. The two most willing traders in an auction may have very incompatible trading requests, because their resource requests and resource capabilities differ a great deal. Resolving this issue is examined later in this chapter. To prevent trade proposals from lingering in auctions for indeterminate amounts of time, each proposal operates on a timeout mechanism. The length of the timeout is determined by the trader who submits the proposal, or by the default value at the point of submission. When a trade proposal exceeds its timeout, it is removed from the auction. This prevents mature trade proposals from occupying the resources used by the auctioning node for attempting to process matches for traders that are more likely to find partners.

PAGE 70

60 5.3 Auctioning Subsystem Design and Implementation 5.3.1 Submitting a Proposal Recall from Chapter 2 the major software components of the OCEAN Node architecture and their relationships. The external APIs give human users the capability to interact with the OCEAN system. From the standpoint of a market participant, the only software component they interact with is the node itself, which is implemented by the OCEANNode class. When a trader submits a proposal to the market, they do so through an OCEANNode object. Similarly, users submit or accept computing tasks through OCEANNode objects as well. Also, auctions are started by a method call to an OCEANNode object. In a sense, the OCEANNode class serves as the user’s gateway to the rest of the OCEAN proper. As described in Chapter 4, traders use the Trade Proposal API to generate trade proposal documents. A trade proposal document gets submitted to an OCEANNode object via a call to its SubmitTradeProposal(OCEANDoc) method. However, the node must first be holding an auction to which the proposal is submitted. The following example illustrates the method calls. OCEANDocdoc; OCEANNodenode=newOCEANNode(); node.HoldAuction(millis); node.SubmitTradeProposal(doc); In the above sample code, the parameter millis in the HoldAuction() method causes the OCEANNode object to keep an auction active for millis milliseconds. These two methods are the key interactions between a user and a node. It must be noted, however, that in the future and auctions will run indefinitely. This can be done by implementing the auction as a daemon (UNIX) process or as a service

PAGE 71

61 (Windows). There are also some other interactions that affect the operation of a node. These are setting the maximum hop count and adding a node to the known node list. Setting the maximum hop count is considered part of the Node Configuration API while adding a known node will be implemented as a PLUM feature in the future. Although the user interaction with the OCEAN node is fairly limited, the resulting actions become rather involved. This is due mainly to the fact that trade proposals can be complex; to process them effectively requires many components to interact appropriately. Once a proposal is submitted to an OCEANNode object by calling its SubmitTradeProposal(OCEANDoc) method, the proposal document must be parsed. This process is initiated by the Agent interface. The purpose of the Agent interface is to decouple the interaction between the Auctioning system and the OCEAN +HoldAuction(in millis : long) +changeAuction(in af : AuctionFactory) +changeAgentFactory(in af : AgentFactory) +addKnownNode(in node : OCEANNodeName) +SubmitTradeProposal(in doc : OCEANDoc) OCEANNode +SubmitTradeProposal(in doc : OCEANDoc, in timer : TimerThread) +removeTradeProposal(in tp : TradeProposal) +setSpread(in s : Spread) +endAuction() interface Auction +SubmitProposalToAuction(in auc : Auction, in doc : OCEANDoc, in timeout : long) +createOCEANDoc(in docContent : String) : OCEANDoc interface Agent Figure 5.2 Node, Agent, and Auction Classes

PAGE 72

62 node. Thus the Agent interface represents the role of the Trader component in the interaction between a user and an auction. A UML diagram of the class and interfaces involved is given in Figure 5.2. The Agent interface accomplishes this decoupling by providing the method SubmitTradeProposalToAuction(Auction,OCEANDoc,long) in its contract. An OCEANNode initiates this call in the SubmitTradeProposal() method. Part of the contract of the Auction interface is the implementation of the SubmitTradeProposal(TradeProposal,TimerThread) method. Therefore it is the responsibility of the Agent to process a trade proposal document to produce implementations of the TradeProposal abstract class, thereby submitting them to the instance of the Auction object received in the SubmitTradeProposalToAuction() call. The following sequence summarizes the process. 1.) A trader process obtains an OCEANNode object, and submits a trade proposal document: OCEANNodenode; OCEANDocdoc; Node.SubmitTradeProposal(doc); 2.) The OCEANNode submits the proposals contained in the OCEANDoc object via a call to the SubmitTradeProposalToAuction() method of the Agent interface: Agentagent; Auctionauction; Longtimeout; agent.SubmitTradeProposalToAuction (auction,doc,timeout);

PAGE 73

63 3.) An implementation of the Agent interface submits a TradeProposal object to an auction: TradeProposaltp; TimerThread timer; auction.SubmitTradeProposal(tp,timer); It must be noted that Agent Auction and TradeProposal cannot be instantiated; this is explored in the next two sections. 5.3.2 Agent and Auction Instantiation By design, the Agent and Auction interfaces do not specify how the processing and submission process is to occur. If the software changes (more accurately, when the software changes) the implementation of the OCEANNode class does not have to change in accordance because it keeps references to interfaces rather than specific implementations. This also contributes to the openness property of OCEAN, described in section 2.1. Namely, that anyone may extend the software protocols for specific purposes. To be more specific, the Agent and Auction interfaces define the protocols that the OCEANNode uses to start trade proposal submission and matching. Anyone may implement these protocols to suit their specific needs. Due to the fact that an OCEANNode object deals only with the Agent and Auction interfaces, an important design issue is the instantiation of objects that implement these interfaces. The OCEAN system implements the Factory Method design pattern, described by Gamma et al. [11], to facilitate the creation of these objects. As an added bonus, this design pattern allows different implementations of the interfaces to be plugged in to the OCEANNode class dynamically, thus circumventing the necessity for recompilation when substituting implementations.

PAGE 74

64 An OCEANNode object keeps references to objects of type AuctionBuilder and AgentBuilder The methodology for auction creation is discussed; agent creation is very similar. The purpose of the AuctionBuilder is to create an Auction using its getAuction() method. An AuctionBuilder keeps a reference to an AuctionFactory The single method of the AuctionFactory interface, createAuction() returns an appropriate Auction implementation. Thus when an OCEANNode needs a reference to an Auction implementation, it calls the AuctionBuilder.getAuction() method, which in turn calls the AuctionFactory.createAuction() method. Figure 5.3 illustrates this structure in a UML diagram. +ChangeAuction(in af : AuctionFactory) -ab : AuctionBuilder -auction : Auction OCEANNode +getAuction() : Auction +setAuctionFactory(in af : AuctionFactory) AuctionBuilder +createAuction() : DoubleAuction DoubleAuctionFactory DoubleAuction +creates return af.createAuction(); ab.setAuctionFactory(af); Figure 5.3 Auction Creation Classes +createAuction() : Auction interface AuctionFactory interface Auction

PAGE 75

65 In this thesis, the DoubleAuction class implements the Auction interface and the DoubleAuctionFactory class implements the AuctionFactory interface. The DoubleAuctionFactory returns a DoubleAuction object in its createAuction() method. When an OCEANNode object is created, the default AuctionFactory implementation is DoubleAucitonFactory However, this can be set via the changeAuction(AuctionFactory) method, and there is also a constructor which accepts an AuctionFactory interface. The Auction implementation used by the OCEANNode can be switched dynamically by calling its changeAuction(AuctionFactory) method, passing an implementation of the AuctionFactory interface. This sets the reference that the AuctionBuilder keeps to its AuctionFactory attribute. To plug in a different implementation of the Auction interface, one must first implement AuctionFactory so that its createAuction() method returns the desired Auction implementation. For example, suppose there are classes NewAuctionImpl and NewAuctionImplFactory that implement the Auction and AuctionFactory interfaces, respectively. Then the following code will cause an OCEANNode object to use NewAuctionImpl as its auctioning class. OCEANNodenode; node.ChangeAuction(newNewAuctionImplFactory()); Note that the above sample assumes that the createAuction() method of NewAuctionImplFactory returns an object of type NewAuctionImpl Agent creation is nearly the same process. The OCEANNode keeps a reference to an AgentBuilder which in turn keeps a reference to an AgentFactory instance.

PAGE 76

66 The difference in implementation is that the getAgent() method of AgentBuilder requires a parameter of type OCEANDoc This parameter is in turn passed on to the createAgent() method of the AgentFactory for use in creating the Agent implementation. Exactly what the Agent does with the OCEANDoc is unspecified, but the framework dictates that an Agent implementation processes the OCEANDoc to form TradeProposal implementations to be submitted to an Auction This is examined in the next section. 5.3.3 Formation of Proposals In this thesis, the two implementations of the Agent interface, BuyersAgent and SellersAgent initiate the creation of TradeProposal implementations. Two +CheckPriceCompatibility(in tp : TradeProposal, in s : Spread) : boolean +compareTo(in o : Object) : int #p : Price #tpID : String TradeProposal +Bid(in n : Node, in doc : Document) +CheckPriceCompatibility(in tp : TradeProposal, in s : Spread) : boolean +compareTo(in o : Object) : int +CheckResourceCompatibility(in o : Offer) : boolean #bi : BidItem Bid +Offer(in su : SaleableUnit) +CheckPriceCompatibility(in tp : TradeProposal, in s : Spread) : boolean +compareTo(in o : Object) : int #su : SaleableUnit Offer Figure 5.4 Trade Proposal Classes

PAGE 77

67 implementations of TradeProposal are provided, Bid and Offer A diagram of these classes appears in Figure 5.4. Future implementations are free to implement Agent and TradeProposal as needed. An OCEANDoc may describe many trade proposals. The agent classes initiate the parsing of JobReqsDoc or OCEANResDoc instances to produce collections of Bid or Offer objects, respectively. A Bid or an Offer is created for each BidItemType or SaleableUnit element encountered in the document. Upon completion of this process, each proposal in the collection is submitted to an Auction The formation of proposals is actually performed by many classes. The bulk of the processing is performed by the classes in the Trade Proposal Document API. Each class in the API wraps a construct in the schema, which collectively form the basis for trade in the market. Thus the Trade Proposal API classes provide software representations of all market entities that the auctioning system requires. The classes of the trade proposal API provide the necessary framework for the auctioning system; the key is to create these objects. To this end, every class in the API provides a constructor that accepts a DOM Node as a parameter, as can be seen in Figures 4.2 – 4.4. The Node is then parsed at object construction time, setting all class attributes based on the information contained in the node tree. In order to form an implementation of a trade proposal is the node tree of the entity that defines the proposal must be traversed, creating all objects contained in the proposal during traversal. The process is best illustrated with an example. The simpler case, formation of an Offer is examined.

PAGE 78

68 A SaleableUnit defines an Offer so passing a SaleableUnit to its constructor as follows will create it. SaleableUnitsu; Offe ro=newOffer(su); The price can be extracted from the SaleableUnit node. But how is the SaleableUnit created? Recall that all schema construct classes can be created from legal node trees, so the BuyersAgent uses the OCEANResDoc instance passed to it to create the unit with a call to the code below. OCEANResDocresDoc; SaleableUnitsu=resDoc.createSaleableUnit(suNode); suNode is the root node of a SaleableUnit element. When the SaleableUnit(Node) constructor is invoked, the node tree is traversed, and for each Resource node encountered, a Resource object is created from that node, and added to the unit. Thus the SaleableUnit is formed. 5.3.4 Matching Trade Proposals The Auction interface provides methods to submit proposals, but does not specify exactly how trading partners are matched. For this thesis, the DoubleAuction class implements this functionality. The price of a bid must be higher than the price of an offer in order for the two to be a potential match. It is proposed that the auction take the difference between the two as revenue. This revenue can cover the cost of the auction’s operation and possibly earn a profit. The spread is the minimum difference between two prices that an auction permits. Because an auction may earn revenue, node operators have an incentive to forgo propagating proposals. However, in the future, it is proposed to employ a “kickback” system whereby the nodes in the proposal propagation chain

PAGE 79

69 share the profits earned by the matching node. Then, auctions that receive proposals still have an incentive to propagate proposals. The DoubleAuction class makes use of the Java™ standard data structure TreeMap to hold active TradeProposal objects. The TreeMap class is useful because it is a type of priority queue, remaining sorted regardless of the operations performed. These data structures are sorted according to price. There are two of them, one for holding active bids, the other for holding active offers. The offer queue is sorted in ascending order according to price, while the bid queue is sorted in descending order. In the Java™ data structures framework, sorting is accomplished by implementing the Comparable interface. The matching algorithm is decomposed as follows. Explained is the case where a bid is entered; the offer case is analogous. 1.) A Bid is formed and submitted to an Auction as described previously. 2.) The TreeMap that contains waiting Offer objects is traversed, in order, until an Offer is found such that the two prices are compatible. Two prices are compatible if (bid price – offer price) >= spread. If no such Offer is found, the Bid gets entered in the active bid queue. 3.) Assuming price compatibility between a bid and an offer, the resource compatibility must be checked. In other words, the Offer must contain all resources requested by the Bid with each resource rated at or above the specifications indicated in the Bid If that is the case, the two are potential trading partners, and the Offer is removed from the waiting queue. If the two trade proposals are incompatible in terms of resources, return to step 2.), beginning with the next proposal in the queue.

PAGE 80

70 5.3.5 Checking Resource Compatibility The process to check resource compatibility is dependent upon the TreeSet class. Like the TreeMap class, TreeSet is also a priority queue. The Bid and Offer classes each provide a method to obtain a TreeSet of Resource objects, containing their resource requirements and resources, respectively. As with TradeProposal s, Resource objects are also required to implement the Java Comparable interface, so that they can be entered in a TreeSet The Comparable implementation for Resource sorts according to the following criteria: 1.) Each Resource keeps a String data member, resourceType The value of this String is the name of the class. Effectively, this groups resources of the same type. Figure 5.5 shows an example. 2.) Metrics specific to the resource type. For example, assume Memory objects m1 and m2 use the same units of measurement. m1 is greater than m2 if its memory amount is greater than that of m2 3.) If two resources are deemed equal in terms of metrics, the object ids, as returned by the Object.toString() method determine order. This method returns the object CPU NetworkConnection StableStorage Figure 5.5 A TreeSet of Resources

PAGE 81

71 name, concatenated with its address in memory, and is unique among objects operating in the same JVM. With the resources associated with a Bid and an Offer sorted in a TreeSet the resources from the differing TradeProposal implementations can be compared efficiently. Observe that every resource request must be satisfied, and that the seller may provide more resources than required. Thus when one resource request will remain unfulfilled, the proposals are incompatible. For every requested Resource r in the queue, it must be determined if r has a compatible resource in the offer resource queue. The following algorithm determines if r has a compatible resource in the offer queue. 1.) The offer queue is iterated until the current resource is of the same type as r or until the resource type in the seller queue is greater than the resource type of r. The latter case indicates there are no more, or that there never were, resources of the same type as r in the seller queue. If this is the case, the trade proposals are incompatible. 2.) Now suppose that the current buyer resource r and the current seller resource, call it s are of the same type. The seller resource queue is iterated beginning with s with each resource in the iteration being checked for compatibility with r The definition of compatible varies from resource to resource. For example, assume r and s are objects of type Memory. Then they are compatible if and only if s has a memory measurement greater than that of r The iteration ends when one of three situations occurs. The iteration has no elements left. Or, the iteration reaches a seller resource that is not of the same type as r Either of the aforementioned situations indicate that r has no resources with which it is compatible. Alternatively, the current seller

PAGE 82

72 resource is compatible with r Then the compatible resource s is marked as reserved for r Note that s is the lowest rated resource that is compatible with r When the next buyer resource is evaluated for compatibility, the evaluated seller resources start with the resource immediately following s See Figure 5.6. The correctness of the algorithm relies on the fact that the resource queues are sorted according to their performance metrics. When the algorithm determines a buyer resource r is compatible with a seller resource s it is impossible that any resource sorted after r (i.e. has a higher performance rating) is compatible with any resource sorted before s (i.e. has a lower performance rating). That is because s is the lowest rated resource that is compatible with r See Figure 5.7. R1RN SKSM Figure 5.7 Compatibility Correctness r s Figure 5.6 Resource Compatibility like resources

PAGE 83

73 In the figure above, assume that R1, RN, SK and SM are all of the same resource type, and that R1 and SM have been found to be compatible. Also assume that iteration of the seller queue began with SK or at a previous resource, so that R1 and SK are known to be incompatible. It is impossible for some resource RN rated higher than R1, to be compatible with SK, a resource rated lower than SM. If it were possible, R1 would be compatible with SK, because R1 is rated lower than RN.

PAGE 84

74 CHAPTER 6 DISTRIBUTED AUCTION SIMULATION AND RESULTS 6.1 Simulation as a Testing Tool As has been mentioned at varying lengths, this thesis represents the first major implementation effort of the OCEAN system, in its current incarnation. Furthermore, at the time of this writing, there are no users registered with the system, and there are no OCEAN-aware extant applications. These circumstances lead to the necessity to test the auctioning system through simulation. Realistically, even if the software components existed for internode communication, security, Task Spawning, etc., it would still be wise to test extensively through simulation of the user population to ensure proper interaction between components before real human users exchange actual monetary funds. However, the absence of well-defined components implies the need to go beyond simulating a user pool. Some essential functions were implemented in order to test the auction system performance. The most notable functionality to be developed is limited support of internode communication. In order to understand what kinds of data the Auctioning simulator provides, it is useful to examine the developed components and how the Auctioning simulator models the operation of the market. To recap, trade proposals can be generated by the Trade Proposal API. The Auctioning system consumes these trade proposals, extracting all relevant trading information, and submitting trade proposals to nodes on the Network, thereby providing a forum for traders to meet and agree to trade. In a fully deployed

PAGE 85

75 system, human users, or programmed agents acting on behalf of human users, will be submitting trade proposals via the Trade Proposal API. Similarly, auctions will be started and held for periods of time by human operators, or programmed agents acting on behalf of human operators. Often auctions will remain active indefinitely. However, node operators will have the ability to enable or disable auctions. This leads to the purpose of the simulator—it is a programmed agent that simulates the activities of random users and node operators. With this in mind, the simulator provides a set of tools to generate random trade proposals, and submit them to auctions. The Auctioning component of each node tabulates performance data during the course of its operation. The simulator also provides a script that analyzes the performance data files of a set of related auctions, producing vital statistics regarding the market as a whole. 6.2 Simulator Implementation The core of the simulator functionality is to randomize the generation of trade proposals and auction operation. A set of classes that produce randomized schema constructs via the Trade Proposal API accomplished this. Below is a description of each class, and what it produces. JobDocSim. This class has one public method, randomJobDoc() that returns a randomized buyer document. JobDocSim provides this functionality by adding a random number of Bid Items, each of which is generated in a randomized fashion. The Bid Item type is selected at random. The maximum number of bid items, the maximum number of Tasks, and the maximum number of resource requests are read from a configuration file. A randomized Resource Bid or Task simply adds a random

PAGE 86

76 number of randomized resource requests, bound by the maximum resource request value. Each Task is required to request a CPU, to keep the scenarios somewhat realistic. Task Lists and Task Groups add a random number of randomized Tasks, bound by the maximum number of Tasks. ResDocSim. Like the JobDocSim class, the single public method, randomResDoc() returns a randomized seller document. This is accomplished by generating a random number of randomized Saleable Units. The maximum number of units and the maximum number of resources per unit are read from a configuration file. A randomized price is assigned to a unit. Also a random number of randomized resources, bound by the maximum value, are added to the unit. That is how randomization of a Saleable Unit is accomplished. Each Saleable Unit must include a CPU, to keep the scenarios realistic. PriceSim. The PriceSim class generates a randomized price between two values. For simplicity, it only generates time dependent prices. ResSim. The responsibility of the ResSim class is to produce a randomized resource description that will be used in either a buyer or a seller document. The randomization of a resource is resource dependent. For example, a randomized CPU selects a clock speed between 100 and 1800 MHz, running Windows NT on an x86 architecture. NodeSim. The NodeSim class randomizes the operation of a node. The main purpose of this class is to allow an auction to be held at a node for a randomized amount of time. Recall that in the future, an auction can be held for an indefinite amount of time.

PAGE 87

77 However, node operators will have the option to disable auctions. Thus the simulator models this functionality by letting auctions occur for a random amount of time. While the simulator uses the above classes extensively, the command-line interface program aucsim allows the user to start auctions and submit proposals, varying all relevant parameters of the Auctioning system. Listed below are all parameters that can be configured by the simulator, and a brief description of each. timeout – specify the timeout period for submitted trade proposals. number of buyer documents – the number of buyer documents that are submitted to the auction. number of seller documents – the number of seller documents submitted to the auction. minimum/maximum auction time – auctions can be held for a random length of time, between the minimum and maximum. number of known nodes – the number of nodes to put in the known node list of the auction. maximum hops – the maximum number of propagation hops that a proposal undergoes. Once all parameters are input, the simulator holds an auction for a randomized length of time, configuring the auction accordingly via an instance of the NodeSim class. The specified number of randomized proposal documents are generated by the ResDocSim and JobDocSim classes and entered according to the input parameters. The simulator reports important auctioning statistics throughout the course of a simulation run. The vital statistics are number of incoming proposals, the number of

PAGE 88

78 matched proposals, and the number of redundant proposals. Each node keeps track of these values for its own auction. A simple script reads the data dumped by each auction to compile results for the distributed auction as a whole. 6.3 The Simulation Scenarios Simulations were performed on machines in the network of the Computer and Information Science and Engineering department at the University of Florida. Two of the machines were multiprocessor servers and the other 8 were single processor workstations. One server was a Sun Ultra 80 with 4 CPUs rated at 450 MHz and 4.0 GB of main memory. The other server was a Sun Enterprise 450 with 2 CPUs rated at 400 MHz and 2.0 GB of main memory. The other computers were each Sun Blade 100 workstations, with a 500 MHz CPU and 256 MB of main memory. Eighty-eight simulations were performed in total. Each simulation represents a different configuration scenario. The configuration parameters were varied as given below. Table 6.1 shows the exact configuration of each scenario. Number of auctioning nodes: 5 nodes and 10 nodes. Number of buyer, seller documents: all combinations of 3 buyer, 6 buyer, 3 seller and 6 seller documents. The buyer and seller documents were generated before running the scenarios. Timeout: 10 s, 20s. Maximum hops: 2, 4 Number of known nodes: 2, 4 Validating proposals: true, false.

PAGE 89

79 As can be seen from Table 6.1, each scenario was given an identifier, named according to its parameter configuration. For example, n10b3s3t10h2k2vN indicates an auction of 10 nodes (n), where 3 buyer documents and 3 seller (b,s) documents are to be submitted, with a timeout of 10 seconds (t), maximum hops of 2 (h), number of known nodes 2 (k), and XML document validation is disabled (“v” for validation and “N” for no). This nomenclature is used in reporting data throughout this section. There were eight major groups of scenarios. First, there was a group of scenarios with 10 auction nodes, and a group with 5 auction nodes. Each of these groups was further divided into a group with all combinations of 3 or 6 buyer documents and 3 or 6 seller documents. In each major group, the timeout, maximum hops, number of known nodes, and document validation parameters are varied. Table 6.1 Configurations of Simulation Scenarios simulation ID nodes b docss docs timeout (s)hops# knownvalidating n5b3s3t10h2k2vY 5 331022Y n5b3s3t10h2k2vN 5 331022N n5b3s3t10h4k2vN 5 331042N n5b3s3t10h4k2vY 5 331042Y n5b3s3t10h2k4vN 5 331024N n5b3s3t10h4k4vN 5 331044N n5b3s3t20h2k2vN 5 332022N n5b3s3t20h4k2vN 5 332042N n5b3s3t20h2k4vN 5 332024N n5b3s3t20h4k4vN 5 332044N n5b3s3t20h4k4vY 5 332044Y n5b3s6t10h2k2vY 5 361022Y n5b3s6t10h2k2vN 5 361022N n5b3s6t10h4k2vN 5 361042N n5b3s6t10h4k2vY 5 361042Y n5b3s6t10h2k4vN 5 361024N n5b3s6t10h4k4vN 5 361044N n5b3s6t20h2k2vN 5 362022N n5b3s6t20h4k2vN 5 362042N n5b3s6t20h2k4vN 5 362024N n5b3s6t20h4k4vN 5 362044N n5b3s6t20h4k4vY 5 362044Y

PAGE 90

80 Table 6.1 – continued simulation ID nodes b docss docs timeout (s)hops# knownvalidating n5b6s3t10h2k2vY 5 631022Y n5b6s3t10h2k2vN 5 631022N n5b6s3t10h4k2vN 5 631042N n5b6s3t10h4k2vY 5 631042Y n5b6s3t10h2k4vN 5 631024N n5b6s3t10h4k4vN 5 631044N n5b6s3t20h2k2vN 5 632022N n5b6s3t20h4k2vN 5 632042N n5b6s3t20h2k4vN 5 632024N n5b6s3t20h4k4vN 5 632044N n5b6s3t20h4k4vY 5 632044Y n5b6s6t10h2k2vY 5 661022Y n5b6s6t10h2k2vN 5 661022N n5b6s6t10h4k2vN 5 661042N n5b6s6t10h4k2vY 5 661042Y n5b6s6t10h2k4vN 5 661024N n5b6s6t10h4k4vN 5 661044N n5b6s6t20h2k2vN 5 662022N n5b6s6t20h4k2vN 5 662042N n5b6s6t20h2k4vN 5 662024N n5b6s6t20h4k4vN 5 662044N n5b6s6t20h4k4vY 5 662044Y n10b3s3t10h2k2vY 10 331022Y n10b3s3t10h2k2vN 10 331022N n10b3s3t10h4k2vN 10 331042N n10b3s3t10h4k2vY 10 331042Y n10b3s3t10h2k4vN 10 331024N n10b3s3t10h4k4vN 10 331044N n10b3s3t20h2k2vN 10 332022N n10b3s3t20h4k2vN 10 332042N n10b3s3t20h2k4vN 10 332024N n10b3s3t20h4k4vN 10 332044N n10b3s3t20h4k4vY 10 332044Y n10b3s6t10h2k2vY 10 361022Y n10b3s6t10h2k2vN 10 361022N n10b3s6t10h4k2vN 10 361042N n10b3s6t10h4k2vY 10 361042Y n10b3s6t10h2k4vN 10 361024N n10b3s6t10h4k4vN 10 361044N n10b3s6t20h2k2vN 10 362022N n10b3s6t20h4k2vN 10 362042N n10b3s6t20h2k4vN 10 362024N n10b3s6t20h4k4vN 10 362044N n10b3s6t20h4k4vY 10 362044Y n10b6s3t10h2k2vY 10 631022Y

PAGE 91

81 Table 6.1 – continued simulation ID nodes b docss docs Timeout (s)hops# knownvalidating n10b6s3t10h2k2vN 10 631022N n10b6s3t10h4k2vN 10 631042N n10b6s3t10h4k2vY 10 631042Y n10b6s3t10h2k4vN 10 631024N n10b6s3t10h4k4vN 10 631044N n10b6s3t20h2k2vN 10 632022N n10b6s3t20h4k2vN 10 632042N n10b6s3t20h2k4vN 10 632024N n10b6s3t20h4k4vN 10 632044N n10b6s3t20h4k4vY 10 632044Y n10b6s6t10h2k2vY 10 661022Y n10b6s6t10h2k2vN 10 661022N n10b6s6t10h4k2vN 10 661042N n10b6s6t10h4k2vY 10 661042Y n10b6s6t10h2k4vN 10 661024N n10b6s6t10h4k4vN 10 661044N n10b6s6t20h2k2vN 10 662022N n10b6s6t20h4k2vN 10 662042N n10b6s6t20h2k4vN 10 662024N n10b6s6t20h4k4vN 10 662044N n10b6s6t20h4k4vY 10 662044Y Notice that there are 24 scenarios in which XML document validation is enabled, and 64 scenarios in which validation is disabled. The 24 validating scenarios are identical to 24 non-validating scenarios, save for the difference in the validation parameter. This is done to compare performance between the two scenario types. The validation tests were performed with the most heavily loaded, the least loaded, and an average load scenario for each major scenario group. The results returned for each scenario were the total number of submitted buyer and seller proposals, and the number of these that found at least one match. The number of submitted seller and buyer proposals is constant within the major scenario groups, because each scenario group inputs an identical set of documents. To judge the effectiveness of the auctioning algorithms, it is necessary to establish a performance

PAGE 92

82 baseline. In order to evaluate the effectiveness of the Auctioning system, it must be known how many proposals actually have a match in the simulation. The proposals that do not have an existing match are ignored in judging the Auction system’s effectiveness. Note that the number of proposals that have a match is dependent only upon the number of buyer and seller documents submitted, not on the other parameters. Thus, there is one baseline measure for each major scenario group. By varying the other parameters and comparing the results, it is determined which of these have the greatest influence on the performance of the auctioning system. However, the baseline gives an upper bound on the possible success rate in matching proposals. Table 6.2 shows the baseline measurements for the eight scenario groups. Note that the nomenclature for the baseline ID follows that of Table 6.1. Table 6.2 Baseline Measurements of Main Scenario Groups The eight scenario groups were partitioned into two main groups. Four of them submit equal numbers of buyer and seller documents to each auction. These groups were used to test the auctioning system with respect to timeout, maximum hops, and known node configurations. The other four scenario groups submit unequal numbers of buyer and seller documents to auctions to examine the capabilities of the auctioning system under those circumstances. totalwith matchtotalwith match n5b3s35332825442247 n5b3s65366360442787 n5b6s35632828843866 n5b6s656663638448111 n10b3s310335853784598 n10b3s610361231187856174 n10b6s31063585715682139 n10b6s61066123122156100222 offersbids total matches base IDnodesb docss docs

PAGE 93

83 Figures 6.1 through 6.4 show the number of bids and offers matched for the configurations in each of the scenario groups in which equal numbers of buyer and seller documents are submitted. Note that each graph uses the nomenclature described previously to indicate a scenario’s configuration. Figure 6.1 Matches for 5 Node Auctions, 3 Buyer and 3 Seller Documents matches for 5 node auctions, b=3,s=30 5 10 15 20 25 30h2 k 2t 1 0 h4k2t1 0 h2 k 4t 1 0 h 4 k4 t 1 0 h2k2t 2 0 h4 k 2t 2 0 h 2 k4 t 2 0 h4k4t 2 0 baselin e configurationmatches offers bids

PAGE 94

84 Figure 6.2 Matches for 5 Node Auctions, 6 Buyer and 6 Seller Documents Figure 6.3 Matches for 10 Node Auctions, 3 Buyer and 3 Seller Documents matches for 5 node auctions, b=6,s=60 10 20 30 40 50 60 70h 2 k 2t10 h4k2t10 h 2k4t10 h4k 4 t 1 0 h 2k2t20 h 4k2t20 h2k 4 t 2 0 h 4k4t20 baselineconfigurationmatches offers bids matches for 10 node auctions, s=3,b=30 10 20 30 40 50 60h2k 2t10 h4k2t10 h2k 4t 10 h4k 4t 10 h2k2t20 h4k2t20 h2k 4t 20 h4k 4t 20 baselineconfigurationmatches offers bids

PAGE 95

85 Figure 6.4 Matches for 10 Node Auctions, 6 Buyer and 6 Seller Documents Figures 6.5 through 6.8 show the number of bids and offers matched for the configurations in each of the scenario groups in which unequal numbers of buyer and seller documents are submitted. Figure 6.5 Matches for 5 Node Auctions, 3 Buyer and 6 Seller Documents matches for 5 node auctions, b=3,s=60 10 20 30 40 50 60 70h2k 2t10 h4k 2t1 0 h2k4t10 h 4k 4t10 h2k 2 t20 h4k2t20 h2k4t20 h4k 4t20 bas el i neconfigurationmatches offers bids matches, 10 nodes, b=6,s=60 20 40 60 80 100 120 140h 2 k2 t1 0 h4k2 t1 0 h2k4t 1 0 h4k4t10 h2k2t20 h 4 k 2t20 h 2 k4 t20 h 4 k4 t2 0 baselineconfigurationmatches offers bids

PAGE 96

86 Figure 6.6 Matches for 5 Node Auctions, 6 Buyer and 3 Seller Documents Figure 6.7 Matches for 10 Node Auctions, 3 Buyer and 6 Seller Documents matches for 10 node auctions, b=3 s=60 20 40 60 80 100 120 140h2k 2t10 h4k 2t10 h2k4t10 h4k4t10 h2k2t20 h4k2t20 h2k4t20 h4k 4 t20 b as el i neconfigurationmatches offers bids matches for 5 node auctions, b=6,s=30 5 10 15 20 25 30 35 40h2k2t1 0 h 4 k 2t1 0 h2k4 t 10 h4k4t10 h 2 k2 t2 0 h 4 k2 t2 0 h 2 k4 t 20 h4k4t20 b a se l i n econfigurationmatches offers bids

PAGE 97

87 Figure 6.8 Matches for 10 Node Auctions, 6 Buyer and 3 Seller Documents Compare Figure 6.1 with Figures 6.5 and 6.6. Similarly, compare Figure 6.3 with Figures 6.7 and 6.8. In making these comparisons, a trend can be identified. When the number of seller documents remains constant and the number of buyer documents is increased, the number of offers matched approaches the seller baseline with closer proximity than when equal numbers of buyer and seller documents are submitted. A similar trend is witnessed for buyer documents. This is especially evident for the 10 node auctions. This makes economic sense. When a seller is presented with many bids, they are more likely to find a trading partner. This is an important observation for the future. When a trader, for example a buyer, is to submit a bid to an auction, the PLUM should refer the trader to an auction that contains (or is known to contain) an excessive number of offers to ensure the best chances of matching the bid. 10 node auctions, b=6 s=30 10 20 30 40 50 60 70 80 90h2 k 2 t10 h4 k 2 t1 0 h 2 k4t10 h 4 k 4 t10 h2 k 2 t2 0 h4k2 t 20 h2k4t20 h4 k 4 t20 b asel i neconfigurationmatches offers bids

PAGE 98

88 Figure 6.9 Timeout Effect on Matches for maximum hops = 2, known nodes = 2 Figure 6.10 Timeout Effect on Matches for maximum hops = 4, known nodes = 4 timeout effect on matches, h=2,k=20 50 100 150 200 250 n5b3s3n5b6s6n10b3s3n10b6s6 scenario groupmatches t = 10 t = 20 baseline timeout effect on matches, h=4,k=40 50 100 150 200 250 n5b3s3n5b6s6n10b3s3n10b6s6 scenario groupmatches t = 10 t = 20 baseline

PAGE 99

89 Figure 6.11 Timeout Effect on CPU Usage Figures 6.9 and 6.10 show two differing cases of how varying timeout length affects the ability of the auctioning system to match proposals. The data is reported for each scenario group with equal numbers of buyer and seller documents. The graphs show total number of matches, i.e. bids and offers together. Maximum hops and known node count are kept constant. These graphs indicate that increasing the timeout length increases the chance that a proposal will be matched. As can be seen in Figure 6.11, increasing the timeout period can incur a performance penalty. Thus, node operators should take care when determining the timeout lengths allowed. It would be prudent to disallow exorbitant timeout periods. In the future, node operators should be able to remove trade proposals that exceed the maximum timeout allowed by the node. Figures 6.12 and 6.13 show two cases of the effects that varying the maximum hops has on the matching capability of the Auctioning system. As can be seen from the timeout effect on CPU usage, n=10,b=6,s=60.0% 2.0% 4.0% 6.0% 8.0% 10.0% 12.0% 14.0% 16.0% 18.0% h2k2h4k2h2k4h4k4 max hops, known nodesCPU usage t=10 t=20

PAGE 100

90 graphs, increasing the maximum hops does not significantly affect the capabilities of the auctioning system to match proposals. Figure 6.12 Maximum Hops Effect on Matching, 2 known nodes, 10s timeout Figure 6.13 Maximum Hops Effect on Matching, 4 known nodes, 20s timeout max hops effect on matches, k=2, t=100 50 100 150 200 250 n5b3s3n5b6s6n10b3s3n10b6s6 scenario groupmatches h = 2 h = 4 baseline max hops effect on matches, k=4,t=200 50 100 150 200 250 n5b3s3n5b6s6n10b3s3n10b6s6 scenario groupmatches h = 2 h = 4 baseline

PAGE 101

91 Figure 6.14 Known Node Effect on Matching, 2 maximum hops, 10s timeout Figure 6.15 Known Node Effect on Matching, 4 maximum hops, 20s timeout known node effect on matches, h=2, t=100 50 100 150 200 250 n5b3s3n5b6s6n10b3s3n10b6s6 scenario groupmatches k = 2 k = 4 baseline known node effect on matches, h=4,t=200 50 100 150 200 250 n5b3s3n5b6s6n10b3s3n10b6s6 scenario groupmatches k = 2 k = 4 baseline

PAGE 102

92 Figures 6.14 and 6.15 show two differing cases of the effects of increasing the known node count on matching probabilities. Like the maximum hops property, increasing the known node count did not have a significant effect on matching trade proposals for these scenarios. This is somewhat unexpected; it is logical to assume that increasing the number of propagations will influence the probability that a proposal is matched. An explanation is offered in the next section. Figure 6.16 CPU Usage of Validating vs. Non-validating Scenarios The OCEANNode class allows a node operator to enable or disable validation of trade proposal documents. The trade proposal API throws exceptions when an attempt is made to produce an invalid document. However, should the schemas be extended, validation is useful to ensure that legal documents are generated and parsed. In addition, CPU usage validating vs. non-validating0.0% 5.0% 10.0% 15.0% 20.0% 25.0% 30.0% 35.0%n 5 b 3 s3t 1 0h 2 k2 n5b3 s3 t2 0 h4k4 n5b6 s6 t1 0 h2k2 n5 b 6 s6 t2 0 h4k 4 n 1 0b 3 s3 t1 0 h 2k2 n10b 3 s3t 2 0h4k4 n10b 6 s6t 1 0h2k2 n 1 0 b6 s6 t2 0 h 4 k4configurationCPU usage validating non-validating

PAGE 103

93 node operators may desire to validate all incoming documents in an effort to ensure a document has not been altered en route. McLaughlin notes [13] that validation can be costly, because it requires the parser to process significant amounts of data. Thus it is necessary to compare the performance of the auctioning system when validation is enabled versus disabled. The results are depicted in Figure 6.16, for some of the validating, non-validating scenario pairs. These results reflect the observations made by McLaughlin. Though validation of documents is useful, it should be done sparingly when performance is an issue. 6.4 Notes On Results While the rates at which proposals are matched seem modest, it is important to put the scenarios in perspective. The scenarios represent small snapshots of a deployed system. As such, trade proposals are propagated only to a small number of nodes. This is likely the explanation for the lack of influence maximum hops and known node count had in the simulations. Since there are few nodes in the simulations, in general any proposal is “saturated” in the system—in other words it is propagated to all or most of the nodes. Then other properties of the auctioning system—most notably timeouts and the removal of matched proposals from an auction’s waiting queue—limit the number of proposals that are matched. In the deployed system, there will likely be vast numbers of auctions to which trade proposals are sent. Maximum hops and known node count should exert more influence on matching probabilities in a large system.

PAGE 104

94 CHAPTER 7 CONCLUSIONS AND FUTURE WORK 7.1 Conclusions The results of simulating distributed auctions in the OCEAN system are encouraging. While it may seem that the rates at which trade proposals are matched is not impressive, it is important to realize the limits in which the system was tested. To truly test this system would require more hardware (or revolutionary software tools) than is at the disposal of the OCEAN research group. A truly significant effort was required to implement all of the functionality contained within this thesis. Each piece of the puzzle represented a serious undertaking, that when comprised as a whole, signifies a unique contribution to the areas of distributed computing and automated markets. In Chapter 3 the data description languages that form the foundation for trade in the market were explored. The schemas are very important, because they give market participants a convenient way to transmit platform-independent proposals. Of course, they also benefit from some of the other properties of XML Schemas. That is, they are extensible. Therefore, it should be noted that although these languages form the basis for trade, their fullest capacity would be achieved through extension of the schemas. Ideas regarding schema extensions are examined in the next section. Chapter 4 explained the Trade Proposal API that relieves much of the hassle in creating OCEAN trade proposals. The API is essential for the success of the market. To

PAGE 105

95 require users to create proposals in raw XML would be a travesty. The tedium involved with this process would be severely detrimental to the success of the market. Similarly, using the DOM to create documents that conform to defined schemas would prove to be error prone from a validation standpoint. Also, though not as tedious as producing raw XML, producing OCEAN trade proposals with the DOM alone would prove to be an unpleasant process. Chapter 5 detailed the design of the Auctioning framework of the OCEAN system. Understanding the framework is important when extending the OCEAN Auctioning system. Recall that the OCEAN software system is to be a set of welldefined standards and protocols. To that end, the Auctioning system is designed with the knowledge that the implementation will change. The implementation described in this thesis serves as a reference implementation for the Auctioning system. It implements a market, but does have some shortcomings as exposed by the simulation of its operation. The results of the simulations of the Auctioning system identified some of the important factors that determine the performance of the Auctioning system. It was found that increasing the timeout period of trade proposals had the most significant impact on the probability that a proposal will be matched. However, there is a tradeoff involved. Increasing the timeout period can impact the performance of the auction negatively. 7.2 Future Work The volume of future work that can be spawned from this thesis is astounding. In general the most prevalent design philosophy of the Auctioning system is that software change is inevitable. Therefore the software system must be able to handle it gracefully.

PAGE 106

96 To this end, the most important components make use of proven design patterns that have been used extensively in many contexts [11]. The trade proposal schemas could have many useful data types built on its defined types. For example, one very useful construct would be a cluster of computers. Certainly if new hardware is invented, a construct can be defined to represent it in the market. Future implementations could support different auction types. For example, an implementation of an auction where traders vary their prices, as described by Drexler and Miller [8], could be easily plugged in to the OCEAN system.

PAGE 107

97 APPENDIX SCHEMAS A.1 Resource Schema

PAGE 108

98


PAGE 109

99

PAGE 110

100
A.2 Price Schema

PAGE 111

101


PAGE 112

102


PAGE 113

103 A.3 Buyer Schema

PAGE 114

104


PAGE 115

105

PAGE 116

106

PAGE 117

107
A.4 Seller Schema

PAGE 118

108

PAGE 119

109

PAGE 120

110

PAGE 121

111


PAGE 122

112 REFERENCES [1] Altova, Inc., XML Spy 2001, http://www.xmlspy.com accessed: 11/04/2001. [2] Apache Software Foundation, Apache XML Project 1999-2001, http://xml.apache.org accessed: 10/7/2001. [3] Buyya, Rajkumar and Sudharshan Vazhkudai, “Compute Power Market: Towards a Market-Oriented Grid,” Proceedings of the First IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGrid 2001) Brisbane, Australia, May 16-18, 2001, pp. 574-581. [4] Chicago Board of Options Exchange, Equity Options Basics 2001, http://www.cboe.com/LearnCenter/Basics.asp accessed: 10/3/2001. [5] Chicago Board of Trade, Glossary of Terms 2001, http://www.cbot.com/cbot/www/page/0,1398,14+54,00.html accessed: 10/3/2001. [6] Coularis, George, Jean Dollimore, and Tim Kindberg, Distributed Systems: Concepts and Design Addison-Wesley, Harlow, England, 2001. [7] Distributed.net, distributed.net: Node Zero 1997-2001, http://www.distributed.net accessed: 9/21/2001. [8] Drexler, K. E. and Mark S. Miller, “Incentive Engineering for Computational Resource Management,” from The Ecology of Computation Bernardo Huberman (ed.) Elsevier Science Publishers, Amsterdam, The Netherlands, 1988, pp. 231-266. [9] Entropia, Inc., Entropia Distributed Computing 1997-2001, http://www.entropia.com accessed: 9/23/2001. [10] Fallside, David, editor, XML Schema Part 0: Primer 2001, http://www.w3.org/TR/xmlschema-0 accessed: 10/13/2001. [11] Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software Addison-Wesley, Reading MA, 1995. [12] Martin, Didier, Mark Birbeck, Michael Kay, Brian Loesgan, Jon Pinnock, Steven Livingstone, Peter Stark, Kevin Williams, Richard Anderson, Stephen Mohr, David

PAGE 123

113 Baliles, Bruce Peat, and Nikola Ozu, Professional XML Wrox Press, Birmingham, UK, 2000. [13] McLaughlin, Brett, Java and XML O’Reilly & Associates, Sebastopol, CA, 2000. [14] Megginson Technologies Ltd., SAX: The Simple API for XML 2001, http://www.megginson.com/SAX accessed: 10/11/2001. [15] Miller, Mark S. and K. E. Drexler, “Markets and Computation: Agoric Open Systems,” from The Ecology of Computation Bernardo Huberman (ed.) Elsevier Science Publishers, Amsterdam, The Netherlands, 1988, pp.133-176. [16] Napster, Inc., Napster 2001, http://www.napster.com accessed: 9/25/2001. [17] Object Management Group, Unified Modeling Language Resource Page 1997-2001, http://www.omg.org/uml accessed: 11/5/2001. [18] Open Computation Exchange and Auctioning Network, OCEAN Project 2001, http://www.cise.ufl.edu/research/ocean accessed: 10/14/2001. [19] Open Computation Exchange and Auctioning Network, ONS (OCEAN Naming System) Component Specification 2001, http://www.cise.ufl.edu/~ppadala/OCEAN/Naming.doc accessed: 11/03/2001. [20] Parabon Computation, Inc., Parabon Computation 1999-2001, http://www.parabon.com accessed: 9/23/2001. [21] Parameswaran, Manoj, Anjan Susarla, and Andrew Whinston, “P2P Networking: An Information-Sharing Alternative,” Computer vol. 34 no. 7, July 2001, pp. 31-38. [22] Porivo Technologies, Inc., Porivo 2001, http://www.porivo.com accessed: 09/23/2001. [23] Reynolds, Kate, The Double Auction 1996, http://www.agorics.com/Library/Auctions/auction6.html accessed: 11/6/2001. [24] SETI@home, SETI@home: The Search for Extraterrestrial Intelligence at Home 2001, http://setiathome.ssl.berkeley.edu accessed: 9/21/2001. [25] Shoch, John F. and Jon A. Hupp, “The ‘Worm’ Programs–Early Experience with a Distributed Computation,” Communications of the ACM vol. 25 no. 3, March 1982, pp. 172-180. [26] Sun Microsystems, Inc., Java™ Technology and XML 1995-2001, http://java.sun.com/xml accessed: 9/26/2001.

PAGE 124

114 [27] Sun Microsystems, Inc., JavaSpaces Technology 2001, http://java.sun.com/products/javaspaces/index.html accessed: 9/18/2001. [28] Sun Microsystems, Inc., JAXP Javadoc API documentation 2001, http://java.sun.com/xml/jaxp-1.1/docs/api/index.html accessed: 9/29/2001. [29] Sutherland, I. E. “A Futures Market in Computer Time,” Communications of the ACM vol. 11 no. 6, June 1968, pp. 449-451. [30] United Devices, Inc., United Devices 2001, http://www.ud.com/home.htm accessed: 9/23/2001. [31] Waldspurger, Carl A., Tad Hogg, Bernardo Huberman, Jeffrey Kephart, and W. Scott Stornetta, “Spawn: A Distributed Computational Economy,” IEEE Transactions on Software Engineering vol. 18 no. 2, February 1992, pp. 103-117. [32] World Wide Web Consortium, Document Object Model (DOM) 2001, http://www.w3.org/DOM accessed: 10/7/2001. [33] World Wide Web Consortium, Extensible Markup Language (XML) 1997-2000, http://www.w3.org/XML accessed: 10/9/2001. [34] World Wide Web Consortium, The Extensible Stylesheet Language (XSL) 2001, http://www.w3.org/Style/XSL accessed: 10/6/2001. [35] World Wide Web Consortium, World Wide Web Consortium 1994-2001, http://www.w3.org accessed: 10/12/2001. [36] World Wide Web Consortium, XML Schema 2000, http://www.w3.org/XML/Schema accessed: 10/12/2001.

PAGE 125

115 BIOGRAPHICAL SKETCH Mark J. Tobias was born in Arlington, Virginia, on July 5th, 1972, and raised in Annandale, Virginia. Mark attended Virginia Polytechnic Institute and State University, located in Blacksburg, VA, where he received a Bachelor of Science degree in mathematics in 1995. In 1997, Mark entered the computer and information science and engineering graduate program, in which he worked as a teaching assistant and attended school full time. Since 1999, Mark has worked in industry as a Software Engineer. During that time, he was completing the requirements for a Master of Science degree in computer engineering on a part time basis. His research interests include distributed systems and XML.


xml version 1.0 encoding UTF-8
METS:mets LABEL Resource and Requirement Schemas Applied to Auctioning in a Computational Market OBJID UFE0000359 TYPE monograph xmlns:METS http:www.loc.govMETS xmlns:daitss http:www.fcla.edudlsmddaitss xmlns:dc http:purl.orgdcelements1.1 xmlns:mods http:www.loc.govmodsv3 xmlns:palmm http:www.fcla.edudlsmdpalmm xmlns:rightsmd http:www.fcla.edudlsmdrightsmd xmlns:techmd http:www.fcla.edudlsmdtechmd xmlns:xlink http:www.w3.org1999xlink xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation ..E20051012_AAAABMlinks_20051012234823www.loc.govstandardsmetsmets_LOC.xsd ..E20051012_AAAABMlinks_20051012234823dublincore.orgschemasxmlssimpledc20021212_LOC.xsd ..E20051013_AAAAAKlinks_20051013064438www.loc.govstandardsmodsv3mods-3-0_LOC.xsd ..E20051012_AAAABMlinks_20051012234823www.fcla.edudlsmdtechmd_LOC.xsd ..E20060621_AAAELKlinks_20060621194313www.fcla.edudlsmdpalmm_LOC.xsd ..E20051012_AAAABMlinks_20051012234823www.fcla.edudlsmdrightsmd_LOC.xsd ..E20060502_AAACYYlinks_20060502001940www.fcla.edudlsmddaitssdaitss_LOC.xsd
METS:metsHdr CREATEDATE 2002-04-06T00:44:45Z ID LASTMODDATE 2006-09-14T16:31:34Z RECORDSTATUS NEW
METS:agent OTHERROLE MXF CREATOR ROLE OTHER ORGANIZATION
METS:name FCLA
METS:note directory=L:\Common 1\Data\UFE_2001_fall\UFE0000359\
makerules=etd
server=TD
formats=application/pdf
projects=ETD
OTHERTYPE SOFTWARE
MXFClient
INDIVIDUAL
emh
METS:dmdSec DMD1
METS:mdWrap MDTYPE MODS MIMETYPE textxml
METS:xmlData
mods:mods
mods:titleInfo
mods:title Resource and Requirement Schemas Applied to Auctioning in a Computational Market
mods:name
mods:namePart TOBIAS, MARK JOSEPH
mods:role
mods:roleTerm type text creator
Michael P. Frank
contributor
mods:originInfo
mods:publisher University of Florida
mods:dateIssued 2001
20011215
mods:language
mods:languageTerm English
mods:abstract At no other time in human history have so many people had access to powerful computing resources. And yet, many of these resources lie idle for long periods of time, simply running a screensaver, or not running at all. Conversely, there are many individuals and organizations who have intense computations to perform, but do not have access to the resources that are required to execute them. The goal of the Open Computation Exchange and Auctioning Network (OCEAN) is to provide a virtual marketplace where participants exchange the temporary use of their computational resources for economic compensation.
OCEAN, a major ongoing research effort conducted in the Computer and Information Science and Engineering Department at the University of Florida, is what is often referred to as a computational market. A computational market is a marketplace in which computational resources are the traded commodities. The focus of this thesis is on the process by which trade occurs in the market. In particular, technologies were developed that provide traders with the ability to form trade proposals and submit them to auctions, where potential trading partners have also submitted proposals.
Due to the fact that trade proposals in the market may be complex, expressive data description languages for trade proposals were developed according to the XML Schema specification. These XML-based trade proposals are generated via Application Programming Interfaces, and subsequently consumed by the Auctioning component of the OCEAN system. When a trade proposal is submitted to the Auctioning system, it finds another trader in the market that can satisfy the submitted trade request, if it is feasible to locate such a trader. A simulator was developed to test the performance of the auctioning algorithms with respect to configurable parameters.
mods:subject
mods:topic Computational Markets, Distributed Systems, XML
mods:accessCondition useAndReproduction Public
METS:amdSec
METS:rightsMD RMD1
OTHERMDTYPE RIGHTSMD
rightsmd:versionStatement Electronic version created 2002, State University Sytem of Florida.
METS:sourceMD SMD1
PALMM
palmm:entityDesc SOURCE UF
METS:digiprovMD DPMD1
DAITSS
daitss:daitss
daitss:AGREEMENT_INFO ACCOUNT PROJECT ETD
METS:fileSec
METS:fileGrp
METS:file CHECKSUM b55760bccb45fda7c922e770d35aafbc CHECKSUMTYPE MD5 CREATED 2002-03-06T13:37:32Z GROUPID GID1 FID1 applicationpdf SIZE 343308
METS:FLocat LOCTYPE OTHERLOCTYPE SYSTEM xlink:href mjtobias_th.pdf
METS:structMap
METS:div ADMID DMDID
main
file
METS:fptr FILEID


xml version 1.0 encoding ISO-8859-1
METS:mets LABEL Resource and Requirement Schemas Applied to Auctioning in a Computational Market OBJID UFE0000359 TYPE monograph xmlns:METS http:www.loc.govMETS xmlns:daitss http:www.fcla.edudlsmddaitss xmlns:dc http:purl.orgdcelements1.1 xmlns:mods http:www.loc.govmodsv3 xmlns:palmm http:www.fcla.edudlsmdpalmm xmlns:rightsmd http:www.fcla.edudlsmdrightsmd xmlns:techmd http:www.fcla.edudlsmdtechmd xmlns:xlink http:www.w3.org1999xlink xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.loc.govstandardsmetsversion14mets.xsd http:dublincore.orgschemasxmlssimpledc20021212.xsd http:www.loc.govstandardsmodsv3mods-3-0.xsd http:www.fcla.edudlsmdtechmd.xsd http:www.fcla.edudlsmdpalmm.xsd http:www.fcla.edudlsmdrightsmd.xsd http:www.fcla.edudlsmddaitssdaitss.xsd
METS:metsHdr CREATEDATE 2002-04-06T00:44:45Z ID LASTMODDATE 2006-09-14T16:31:34Z RECORDSTATUS NEW
METS:agent OTHERROLE MXF CREATOR ROLE OTHER ORGANIZATION
METS:name FCLA
METS:note directory=L:\Common 1\Data\UFE_2001_fall\UFE0000359\
makerules=etd
server=TD
formats=application/pdf
projects=ETD
OTHERTYPE SOFTWARE
MXFClient
INDIVIDUAL
emh
METS:dmdSec DMD1
METS:mdWrap MDTYPE MODS MIMETYPE textxml
METS:xmlData
mods:mods
mods:titleInfo
mods:title Resource and Requirement Schemas Applied to Auctioning in a Computational Market
mods:name
mods:namePart TOBIAS, MARK JOSEPH
mods:role
mods:roleTerm type text creator
Michael P. Frank
contributor
mods:originInfo
mods:publisher University of Florida
mods:dateIssued 2001
20011215
mods:language
mods:languageTerm English
mods:abstract At no other time in human history have so many people had access to powerful computing resources. And yet, many of these resources lie idle for long periods of time, simply running a screensaver, or not running at all. Conversely, there are many individuals and organizations who have intense computations to perform, but do not have access to the resources that are required to execute them. The goal of the Open Computation Exchange and Auctioning Network (OCEAN) is to provide a virtual marketplace where participants exchange the temporary use of their computational resources for economic compensation.
OCEAN, a major ongoing research effort conducted in the Computer and Information Science and Engineering Department at the University of Florida, is what is often referred to as a computational market. A computational market is a marketplace in which computational resources are the traded commodities. The focus of this thesis is on the process by which trade occurs in the market. In particular, technologies were developed that provide traders with the ability to form trade proposals and submit them to auctions, where potential trading partners have also submitted proposals.
Due to the fact that trade proposals in the market may be complex, expressive data description languages for trade proposals were developed according to the XML Schema specification. These XML-based trade proposals are generated via Application Programming Interfaces, and subsequently consumed by the Auctioning component of the OCEAN system. When a trade proposal is submitted to the Auctioning system, it finds another trader in the market that can satisfy the submitted trade request, if it is feasible to locate such a trader. A simulator was developed to test the performance of the auctioning algorithms with respect to configurable parameters.
mods:subject
mods:topic Computational Markets, Distributed Systems, XML
mods:accessCondition useAndReproduction Public
METS:amdSec
METS:rightsMD RMD1
OTHERMDTYPE RIGHTSMD
rightsmd:versionStatement Electronic version created 2002, State University Sytem of Florida.
METS:sourceMD SMD1
PALMM
palmm:entityDesc SOURCE UF
METS:digiprovMD DPMD1
DAITSS
daitss:daitss
daitss:AGREEMENT_INFO ACCOUNT PROJECT ETD
METS:fileSec
METS:fileGrp
METS:file CHECKSUM b55760bccb45fda7c922e770d35aafbc CHECKSUMTYPE MD5 CREATED 2002-03-06T13:37:32Z GROUPID GID1 FID1 applicationpdf SIZE 343308
METS:FLocat LOCTYPE OTHERLOCTYPE SYSTEM xlink:href mjtobias_th.pdf
METS:structMap
METS:div ADMID DMDID
main
file
METS:fptr FILEID


Permanent Link: http://ufdc.ufl.edu/UFE0000359/00001

Material Information

Title: Resource and Requirement Schemas Applied to Auctioning in a Computational Market
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000359:00001

Permanent Link: http://ufdc.ufl.edu/UFE0000359/00001

Material Information

Title: Resource and Requirement Schemas Applied to Auctioning in a Computational Market
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000359:00001


This item has the following downloads:


Full Text










RESOURCE AND REQUIREMENT SCHEMAS APPLIED TO AUCTIONING IN A
COMPUTATIONAL MARKET
















By

MARK JOSEPH TOBIAS


A THESIS PRESENTED TO THE GRADUATE SCHOOL OF
THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2001




















To Amy















ACKNOWLEDGEMENTS


I must first and foremost express my deepest appreciation to my committee chair,

Dr. Michael Frank, for presenting me with the opportunity to work on such a fascinating

project. His continuous guidance played a significant role in bringing this project to

fruition. I would also like to thank my other committee members, Drs. Jonathon

Hamilton and Joachim Hammer, for their meticulous review of this thesis.

I would also like to express my gratitude to all members, past and present, of the

OCEAN research project. Through painstaking collaboration, their contributions

produced meaningful results that appear in this thesis.

And on a personal note, I must express my most sincere thanks to my wife, Amy.

Her unending support and encouragement were a constant source of inspiration

throughout this experience.















TABLE OF CONTENTS

page

A C K N O W L E D G E M EN T S ............................................................................................. iii

L IST O F T A B L E S ....... .................................................................. .. .............. vi

LIST OF FIGURES ......... ............................ .. .. ... .... .......... vii

A B STR A C T ... ................. .................................. ...... .......... .... ix

CHAPTERS

1. IN T R O D U C T IO N ............. .......................................... .. ........ .. ........... 1

1.1. The History of Com putational M markets ............................... .......................... 1
1.2. The OCEAN Software System .................................. ............................. 4

2. OCEAN SOFTWARE ARCHITECTURE ........................................ ............. 9

2 .1. U sag e P h ilo so p h y .. .. ............................................................ .. .......... ........ 9
2.2. A architecture ....................................... ............. 10

3. TR AD E PR OPO SA L SCH EM A S ............................................................................ 20

3.1. The N eed for Standardization ........................................ ....................... 20
3.2. X M L in the A uctioning System ........................................ ........ ........ ..... 21
3.3. O CEA N Trading Schem as ................ .......................................... ............. 22

4. TRAD E PR OPO SA L API ................................................... ............. ............. 41

4.1. Introduction ............................................. .......... 41
4.2. Java and XML ....................................................... .. 42
4.3. T he D ocum ent C lasses ...................................................................... 43
4.4. Creation and Manipulation of Schema Constructs ........................................ 46

5. AUCTIONING ................... ........................ .. 56

5.1. Introduction .......................................... 56
5.2 Proposal Propagation ........................... ............................................................... 57

iv









5.3 Auctioning Subsystem Design and Implementation ....................................... 60

6. DISTRIBUTED AUCTION SIMULATION AND RESULTS ................................ 74

6.1. Sim ulation as a T testing T ool ............................................................................. 74
6.2 Sim ulator Im plem entation .................................................................................. 75
6.3. The Sim ulation Scenarios ................ ......................................................... 78
6.4. N otes O n R results ................. .... .............................. ... .............. ...... ...... .......... 93

7. CONCLUSIONS AND FUTURE WORK ......................................................... 94

7 .1 C o n clu sio n s ................................ ........................................ 9 4
7.2. Future W ork ............................................ ............ 95

APPENDIX

SCHEMAS ..................................... ...................... 97

A .1 R source Schem a .... .......................... .................... ........ .................. 97
A .2 P rice Schem a .......... ........................................................... .. .. .......... 100
A.3 Buyer Schema ....................................... ................ .. 103
A.4 Seller Schema .. ................. .................... ........ ........ .. 107

REFEREN CE S ............... .... ................................................ ................ .. .. .......... 112

BIO GRAPH ICA L SK ETCH .................................................. ............................ 115















LIST OF TABLES


Table pge

6.1 Configurations of Simulation Scenarios ........................................................... 79

6.2 Baseline Measurements of Main Scenario Groups ................................................ 82















LIST OF FIGURES


Figure pge

2.1 The O C E A N System ..................................................... ............................... 12

2.2 O CEAN N ode A architecture .............................................. ........................... 15

2.3 Intercom ponent Com m unication ........................................ ........................ 17

3.1 D iagram m ing N otation Legend ........................................... ......................... 23

3 .2 C P U Structu re ...... ........................................................................ ............ 24

3 .3 P rice Stru ctu re ........................ ................................ ............... 2 8

3.4 Schedule Structure ....................................................... .. 29

3.5 B uyer Structure ........................................ 31

3.6 T ask Structure ........................................ 33

3.7 Task List Structure .................. ......................... .......... .. 35

3.8 T ask G group Structure ..................................................... ................. ............. 36

3.9 Seller Structure ....................................... .......... ..... 39

4.1 D ocum ent C lass Structure ................................................. .............. ............. 45

4.2 Resource Classes ....................................................... .. 50

4.3 Task R elated Classes ................. ...... ................ ................................ ...... .......... 51

4.4 Price Classes ..................................................... 52

5.1 Trade Proposal Propagation .............................................. ........................... 58

5.2 N ode, A gent, and A auction Classes ........................................ ...................... 61









5.3 A auction C reaction C lasses ................................................ ............................. 64

5.4 Trade Proposal C lasses .................................................. ............................... 66

5.5 A TreeSet of R sources ........................... ........................................ ........................ 70

5.6 R source Com patibility ........................... ........................................ ........................ 72

5.7 C om patibility C orrectness ............................................... ............................. 72

6.1 Matches for 5 Node Auctions, 3 Buyer and 3 Seller Documents ......................... 83

6.2 Matches for 5 Node Auctions, 6 Buyer and 6 Seller Documents ........................... 84

6.3 Matches for 10 Node Auctions, 3 Buyer and 3 Seller Documents .......................... 84

6.4 Matches for 10 Node Auctions, 6 Buyer and 6 Seller Documents .......................... 85

6.5 Matches for 5 Node Auctions, 3 Buyer and 6 Seller Documents ........................... 85

6.6 Matches for 5 Node Auctions, 6 Buyer and 3 Seller Documents ........................... 86

6.7 Matches for 10 Node Auctions, 3 Buyer and 6 Seller Documents .......................... 86

6.8 Matches for 10 Node Auctions, 6 Buyer and 3 Seller Documents .......................... 87

6.9 Timeout Effect on Matches for maximum hops = 2, known nodes = 2 ................... 88

6.10 Timeout Effect on Matches for maximum hops = 4, known nodes = 4 ................. 88

6.11 Tim eout Effect on CPU U sage ........................................ ..................... .... 89

6.12 Maximum Hops Effect on Matching, 2 known nodes, 10s timeout ................... 90

6.13 Maximum Hops Effect on Matching, 4 known nodes, 20s timeout ................... 90

6.14 Known Node Effect on Matching, 2 maximum hops, 10s timeout .................... 91

6.15 Known Node Effect on Matching, 4 maximum hops, 20s timeout .................... 91

6.16 CPU Usage of Validating vs. Non-validating Scenarios ....................................... 92















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science

RESOURCE AND REQUIREMENT SCHEMAS APPLIED TO AUCTIONING IN A
COMPUTATIONAL MARKET

By

Mark Joseph Tobias

December, 2001


Chair: Michael P. Frank
Major Department: Computer and Information Science and Engineering

At no other time in human history have so many people had access to powerful

computing resources. And yet, many of these resources lie idle for long periods of time,

simply running a screensaver, or not running at all. Conversely, there are many

individuals and organizations who have intense computations to perform, but do not have

access to the resources that are required to execute them. The goal of the Open

Computation Exchange and Auctioning Network (OCEAN) is to provide a virtual

marketplace where participants exchange the temporary use of their computational

resources for economic compensation.

OCEAN, a major ongoing research effort conducted in the Computer and

Information Science and Engineering Department at the University of Florida, is what is

often referred to as a computational market. A computational market is a marketplace in

which computational resources are the traded commodities. The focus of this thesis is on









the process by which trade occurs in the market. In particular, technologies were

developed that provide traders with the ability to form trade proposals and submit them to

auctions, where potential trading partners have also submitted proposals.

Due to the fact that trade proposals in the market may be complex, expressive

data description languages for trade proposals were developed according to the XML

Schema specification. These XML-based trade proposals are generated via Application

Programming Interfaces, and subsequently consumed by the Auctioning component of

the OCEAN system. When a trade proposal is submitted to the Auctioning system, it

finds another trader in the market that can satisfy the submitted trade request, if it is

feasible to locate such a trader. A simulator was developed to test the performance of the

auctioning algorithms with respect to configurable parameters.















CHAPTER 1
INTRODUCTION


1.1 The History of Computational Markets

The commodification of computing resources is not a novel concept. Indeed,

systems that can be described as computational markets have been implemented as early

as 1968. Sutherland demonstrated how auction methods were used to allocate time to

users of the PDP-1 computer in the Aiken Computation Laboratory at Harvard University

[29]. The hours of the day were divided into regular time slots. Users were assigned

different amounts of currency based on their project's importance. Then, the users would

submit bids for time slots. For a given time slot, the user who submitted the highest bid

would have use of the computer. By using the auction methods described, a monetary

value was associated with computation time, which is a basic feature of computational

markets. This paper is important because it may be the first application of economic

principles to the problem of computer resource allocation.

Another major research effort was the Agoric Papers [8, 15]. Although there is no

implementation associated with these publications, they established important

groundwork for modeling distributed computation in economic terms. Although

Sutherland's work [29] was important for using economic principles to solve resource

allocation problems, it did not address the problem in distributed systems. Drexler and

Miller approached this problem by describing auction mechanisms for allocating

distributed resources. In one of their solutions, a seller auctions off resources to

1









competing buyers. Escalator algorithms are used in such a way that buyers only submit

an initial bid. Bids increase at a constant rate until the highest bid is determined. The

highest bidder obtains the seller's resources.

Drexler and Miller continued, describing initial market strategies, and how they

achieve stable pricing mechanisms. Later work [31] has proven Drexler and Miller's

algorithms to be effective for achieving this goal. The Agoric Papers made two important

contributions to computational markets. First, they provided market-based mechanisms to

allocate distributed resources. And second, they addressed the issue of how pricing

stability can be achieved in computational markets. These are essential for a successful

computational economy.

A more recent research effort is the Compute Power Market project [3]. This

project has designed a decentralized, market based architecture that is highly dependent

on agents. The decentralized architecture is similar in some respects to the architecture of

the OCEAN system. This is discussed further in section 2.2.1. Buyya and Vazhkudai

have also made the same observation that drives this thesis. Namely, that the information

resource providers and consumers convey to the market can be complex [3]. In addition,

capabilities must exist whereby potential trading partners must be checked for resource

compatibility before a trade is allowed to proceed.

Like the commodification of computing resources, the engagement of idle

computers to perform useful tasks is also not a new concept [3]. Possibly the first such

implementation to exhibit this behavior was developed by Shoch and Hupp, which they

named a "worm" [25]. The worm was characterized by two very important traits. First,

it was parallelizable-able to be broken into discrete segments, each segment running on









a different host. Second, the worm was able to sniff out idle machines on the network.

Although this project was not concerned with the economics of computation, it still

represented a significant step toward fully functional computational markets. This

observation lies in the fact that the worm's traits are important features of programs used

in computational markets. For one, idle machines in a network must be located. Also,

users of programs that can be parallelized stand to benefit most from computational

markets, because they achieve the highest utilization of available resources.

More recently, implementations of systems that successfully run programs on idle

computers have been developed. The two systems that have received much attention are

the SETI@home project and Distributed.net [24, 7]. While each of these projects has had

success in parallelizing computations and running them on otherwise inactive machines,

neither qualifies as a computational market. Both of these projects rely on the altruism of

their participants; users donate CPU cycles in a concerted effort to solve some

computationally intense problem. In the case of SETI@home, users analyze radio

telescope data to search for extraterrestrial life. Distributed.net participants engage in a

variety of collaborative efforts, such as breaking encryption ciphers.

There are several commercial ventures that are attempting to extend the concepts

of a computational market to business advantage. Some of these include United Devices,

Entropia Distributed Computing, Parabon Computation, and Porivo [30, 9, 20, 22]. In

each of these ventures, organizations that have intense computations to perform become

partners with the venture. The types of programs vary; they include web application

performance testing, bioinformatics analyses, and engineering applications. Idle









processors of individuals or organizations are recruited to perform the computations.

Often, the idle processor owners are compensated for their services.

None of these systems, however, share the OCEAN philosophy of maintaining an

open market. In no case are participants able to meet and negotiate independent of the

business entity. The computation performers have no influence as to the price they

charge for services rendered. Effectively they must accept whatever payment is

disbursed, or donate services charitably. The provision of a fully functional market,

where traders are able to meet, exchange information, and negotiate contracts, is one of

the unique aspects of the OCEAN research project.



1.2 The OCEAN Software System

1.2.1 Overview

The aim of the OCEAN project is to provide an infrastructure to support

automated purchasing and selling of distributed computing resources over the Internet

[18]. Any individual or organization with unused or idle computing resources can offer

them as an OCEAN server, thereby renting their facilities for profit. Conversely, any

individual or organization with a computing task to perform, but who does not have

direct access to the resources required to carry out the task, may rent as many OCEAN

servers as they can afford in exchange for each server performing a part of their

computing task. There is an obvious advantage for each party involved. The resource

provider is compensated for the use of their otherwise stagnant resources, thereby

offsetting the cost, and possibly generating a profit, for the purchase of said resources.

The resource purchaser is able to perform their computing tasks while forgoing the

purchase of expensive hardware.









Most commonly, a developer will have a computation that is by nature highly

parallel, and they deploy the application on as many OCEAN servers as they can afford

to purchase. The basic process for such a scenario is as follows. A developer must first

have programming libraries at their disposal, which allow him or her to develop an

OCEAN-aware application. The developer indicates, either statically or dynamically, the

resource requirements of his or her application, and the maximum price they will pay for

the computation to be performed. The resource requirements, coupled with maximum

price, form a bid in the market. Anyone who submits a bid is referred to as a buyer.

When the administrator of an OCEAN server has resources that are ready to go idle, he or

she becomes a seller by forming an offer based on the minimum price they will accept for

the use of their resources. Bids and offers are entered into the OCEAN distributed

auctioning system. The auctioning system matches potential buyers with sellers, and vice

versa. When the auctioning process produces a potential trading match, all parties

involved are notified of the match. The negotiation process then allows traders to

determine the actual prices at which trade will occur. Once prices are agreed upon, the

developer's application is deployed by the task spawning and migration system, and the

computation is executed on the remote OCEAN servers. When each OCEAN server is

finished performing its work, they can be paid for services rendered. See Chapter 2,

OCEAN Software Architecture, for a more detailed discussion of OCEAN and its

components.

It should be noted that, even though the above process is the most common

OCEAN transaction, this is not the only scenario possible. The auctioning and

negotiation processes remain the same, but the types of resources requested and provided









do not necessarily have to be related to a computation. For example, a buyer may

purchase space on a large data store (possibly the result of an OCEAN computation) for

some period of time. Also, a buyer may be purchasing a resource future, the right to

resources at some time in the future. The OCEAN trading framework is designed to

accommodate such interactions. See Chapter 3, Trade Proposal Schemas, for more

information regarding the format of trade proposals.

That which begins as a simple, straightforward concept becomes complex in a

very short amount of time. The two basic ideas behind OCEAN are simple ones. First,

allow individuals to profit from the use of their otherwise idle computing facilities.

Second, provide a cost effective way for individuals to perform their computing tasks.

However, to provide the infrastructure to support these interactions is not an easy task.

An OCEAN transaction requires that the following events must occur.

First, the traders involved in a transaction must locate one another, and agree on

the terms of a contract. Once resources have been negotiated for, the buyer's computation

can be deployed over the OCEAN servers in a secure fashion, if that is part of the

contract terms. Each OCEAN server will return the results of its computation, if that is

part of the contract, and payment can be exchanged. This process occurs with as little

human intervention as possible, and requires the cooperation of many complex software

components. See the next chapter for a more in-depth discussion of the OCEAN

software architecture.

1.2.2 The Auctioning System

The focus of this thesis is the Auctioning system of the OCEAN project. The

main purpose of the auctioning process is to match traders with the best possible trading









partners. For buyers this means finding sellers who not only offer the best prices, but

also provide the resources that the buyer is requesting. For sellers, the Auctioning system

is responsible for finding the highest paying buyers, without exceeding the resource

capabilities of the seller.

However, this is not a trivial task. Buyya and Vazhkudai make the observation

that resource requirements of buyers can be complex [3]. The buyer may have strict

requirements regarding hardware and software resources that must be satisfied. For

example, a buyer may require a secure environment to protect sensitive data. Or, they

may require a high-speed network connection because a large volume of data is to be

transmitted with a task. A buyer may also need certain hardware, a sophisticated

graphics board, for example. Similarly, sellers may offer many differing types of

services; they may have a vast array of hardware, software and data resources at their

disposal.

In order to handle the complexity of trade proposals, expressive data description

languages were developed in the Extensible Markup Language, or XML. These

languages were developed according to the XML Schema specification [36], defining the

format that trade proposals assume. Application Programming Interfaces (APIs) were

developed for the JavaTM programming language that allow OCEAN traders to define the

resources they request or provide. In addition, the APIs allow traders to express the

prices at which they are willing to trade. In XML vernacular, these APIs generate the

XML content that defines a trade proposal. Chapter 3 examines the trade proposal

languages in depth. Chapter 4 covers the Trade Proposal API.









The auctioning system is the component that consumes the XML-based trade

proposals. It parses all relevant trading information for each incoming proposal, and

attempts to find a matching traderss. Distributed algorithms were implemented to

perform this function. The auctioning process occurs in a distributed, peer-to-peer

framework among many nodes in the OCEAN system. Potential trading partners, before

being matched, must have their resource descriptions checked to verify that the traders

are compatible in terms of resource request and provision. Chapter 5 explores auctioning

in the OCEAN system.

Finally, a simulator was developed to test the performance of the auctioning

system relative to configurable parameters. The OCEAN system is still in development.

At the time of this writing, no other components of the system are mature enough to test

with the auctioning system. Thus all testing of the auctioning system must be performed

through simulation. Chapter 6, Distributed Auction Simulation and Results, discusses the

testing simulator and the results of its operation.















CHAPTER 2
OCEAN SOFTWARE ARCHITECTURE


2.1 Usage Philosophy

The Open Computation Exchange and Auctioning Network is a system in which

anyone may participate. Any individual or organization with a computer can download

the OCEAN software system and participate in the Exchange and Auctioning Network,

heretofore referred to as the Network for brevity. In this sense, it is "open," i.e. open for

anyone to join.

But OCEAN is meant to be "open" in other senses as well. Miller and Drexler

[15, p. 135] define an open system as one where "software spread across a distributed

computer system serves different owners pursuing different goals." This is one of the

main goals of the project: to provide an environment where participants obtain useful

services through their interactions with one another.

Coularis et al. [6] describe an open system as one that can be extended and

implemented in new ways without disturbing its existing functionality. One of the keys

to providing this openness is to ensure software interfaces of the components are

specified and documented. This is one of the most pervasive philosophies of the OCEAN

research group. That is, the software system will define a set of standards, including

software interfaces and communication protocols that anyone is free to extend and

implement. As long as the interfaces and standards established are adhered to, the

functionality of the system will not be compromised.

9









Among other things, this thesis defines and documents the software interfaces to

the auctioning system, along with the format to which trade proposals must conform.

Using these standards, anyone is free to use and extend the APIs and trade proposal

schemas to participate in the Network. By providing a set of extensible APIs and trading

formats, the auctioning system follows the philosophy that the Network should be open.


2.2 Architecture

2.2.1 Architecture of the Deployed System

Coularis et al. [6, p. 2] define a distributed system as "one in which hardware or

software components located at networked computers communicate and coordinate their

actions only by passing messages." The OCEAN software system fits this description.

The most common type of architecture for a distributed system is the client-server model

[6].

A client-server type of architecture for OCEAN would employ a server process,

or many processes to handle all auctioning, negotiation and accounting between buyers

and sellers (clients). The potential volume of users that are able to participate in the

Network is enormous; anyone with a computer may join. Thus, the likelihood of

encountering scalability problems is a huge factor in the system design. A system is

described as scalable if its effectiveness is not compromised upon significant increases in

the number of resources and the number of users [6]. The client-server model can present

scalability problems for two reasons. One, the server may be a bottleneck when the user

volume is large. Two, a server can act as a single point of failure. For these reasons, a

client-server type of architecture is unsuitable for the OCEAN system.









Buyya and Vazhkudai propose a decentralized architecture for the Compute

Power Market that is based on mobile agents [3]. This is important, because the

decentralized architecture improves the fault-tolerant capabilities of the system. Their

architecture relies on a distributed network of market servers to implement the market

mechanisms.

While the Compute Power Market approach improves fault tolerance over a

client-server approach, it does not achieve maximum scalability. The fact that there are a

finite number of market servers has implications-if the number of users increased

dramatically, it is possible that there are not enough market servers to keep the market

operating efficiently.

The OCEAN system attempts to improve scalability by implementing a

distributed, peer-to-peer based architecture. The OCEAN software system, developed in

the JavaTM programming language, is packaged as a single unit, and can be installed on

any computer with a JavaTM Virtual Machine (JVM), thereby causing the machine to

become a node in the Network. Any node can perform any function in the Network.

Thus any node can hold an auction, execute a buyer's computation, serve as an

application development environment, or an application launch point. The high level

interactions among nodes is depicted in Figure 2.1.

As can be seen from Figure 2.1, all nodes are connected to one another in one of

two ways. Either they are connected directly via the Internet, or indirectly through a

node that operates as a gateway to other nodes in an intranet behind a firewall. Note that

specific types of node indicate the role that each one is playing at a given point in time.

For example, a node that is acting as an auction server at some point in time can act as a











server performing a computation at another time. The only exception to the completely


distributed nature of the OCEAN system is the presence of a centralized accounting


system.


Auction node


Server node


Server node


Application
Launch point


Public Internet


Auction
node


Firewall/
OCEAN Proxy
node





Private
Intranet






Application
launch point


Cenral Accounting
System


Server node


Financial
Networks


Auction node


Figure 2.1 The OCEAN System

The main responsibilities of the accounting system are to log transaction


information to stable storage, to disseminate payments to resource providers and extract


payments from buyers. In general, the prices at which resources are bought and sold are


may not be very large. For example, an individual's desktop PC may be rented for only a


few minutes. An account is kept for every trader. This is similar to a conventional bank









account, but micropayments accrue to or are deducted from the trader account when a

transaction is completed. The accounting system must interact with existing financial

institutions to make withdrawals or deposits on behalf of its users. When the balance in

the account of a resource provider reaches some threshold, they can be sent their

payments. If a buyer does not have sufficient funds in their account to compensate a

provider, a proposed transaction is not allowed to commence.

Although a centralized accounting server might serve as a single point of failure,

it presents some advantages to market participants. For one, it simplifies the financial

operations of the OCEAN system. If this function were distributed across the nodes of

the Network, transaction histories could get cumbersome for nodes that make extensive

use of the market. Logging all transaction histories would consume precious computing

resources, thereby hindering the earning capacity and productivity of a node. Also, there

is the issue of trust between the financial networks and the OCEAN participants. When

the financial operations are governed by a single entity, the financial markets only have

to trust that entity. In a decentralized model, financial institutions are required to trust all

market participants. This would present some hassle to the users of the OCEAN system.

Furthermore, there is no requirement that there is a single accounting server. Note that

administrative control over accounting operations are centralized, not that the accounting

system runs on a single server machine. Suitable fault-tolerance can be achieved by

distributing the accounting system operation among many servers, much like Buyya and

Vazhkudai propose for the distributed market system of the Compute Power Market.

This approach works toward achieving maximum scalability, openness and

flexibility. Because any node has the ability to hold an auction, scalability issues









associated with market servers are alleviated. Dramatic increases in the number of

traders in the Network are not a problem, because at any given time, possibly every node

in the network is holding an auction. The architecture provides Network participants

with maximum flexibility by allowing them to assume any role at any time, even multiple

roles at once. For example, a node may be holding an auction, and executing a buyer's

task simultaneously. Another advantage of the peer-to-peer approach is the proliferation

of the Network. It has been noted that P2P communities form by themselves [21], and

further evidence of this has been seen in the past, with the rapid growth of the Napster

online music exchange network [16].

However, the peer-to-peer approach has potential design issues. Parameswaran et

al. notes the problem of inefficient directory lookup operations [21]. The OCEAN system

encounters a similar issue. To be more specific, it is impractical for a node to

communicate with all other nodes in the Network. A node should only interact with a

subset of the Network when internode communication is required. However, determining

to whom a node communicates with is a difficult problem. For example, say a trader is to

enter a proposal to an auction. In order to improve the trader's chance of finding a

trading partner, a successful auction, i.e. one with a high rate of success for matching

proposals, must be located. In that case, a well-defined rating system must exist for an

auction. This problem is not addressed in this thesis.

2.2.2 Node Architecture

In order to gain a more clear understanding of the auctioning capability of the

OCEAN system, it is necessary to examine the architecture at the node level. The major

software components of an OCEAN node are depicted in Figure 2.2.












Trade Proposal API App. Programmer API Node Configuration & Operation


Node


Central Accounting
System


Figure 2.2 OCEAN Node Architecture



There are three external APIs: the Trade Proposal API, the Application

Programmer API and the Node Configuration and Operation API. These provide human

traders the mechanisms necessary to interact with the OCEAN node software and with

the system as a whole. Each is examined further.









Trade Proposal API. The Trade Proposal API allows traders to specify all of

their trading information. This includes the resources they provide/request, the prices at

which they would like to trade them, and so on. This API is examined extensively in

Chapter 4, Trade Proposal API.

Application Programmer API. The Application Programmer API contains all

of the libraries that a programmer requires to create an OCEAN-enabled application. The

API consists of a set of JavaTM classes. Thus, the system only supports programs written

in JavaTM. However, a major goal of the project is to eventually support applications

written in other programming languages.

Node Configuration and Operation API. This simple API allows a node

operator to configure or dynamically change parameters that affect the operation of the

node. In general, some of these parameters affect the auctioning process. This API is

examined in greater depth in Chapters 5 and 6.

Within an OCEAN node, there are several major software components. For

brevity, not all components are described here, only the most significant ones. Each one

is described below, along with their interactions with other components.

Trader. This component acts as an interface between the human participants and

the rest of the node components. Note that human interaction is accomplished through

use of the external APIs. In effect, the Trader subsystem acts on behalf of the human

users to allow them to communicate with the Negotiation, Auctioning, and Task

Spawning and Migration subsystems.

Auctioning. The Auctioning subsystem provides a forum in which traders meet

to exchange price and resource information. Its operation is examined extensively










throughout this thesis. The Trader subsystem must provide information to the auctioning

subsystem so that trade proposals are entered in auctions. When the auctioning system

needs to communicate with the auctioning systems of other nodes, it does so with

assistance from the Peer List Update Manager (PLUM) and Security components.

PLUM. The main purpose of the PLUM is to ameliorate the problem of directory

lookup operations mentioned by Parameswaran et al. [21]. More specifically, it is

impractical for nodes to communicate with one another in a broadcast fashion. Instead,

they must communicate with a select few peer nodes. It is the responsibility of the

PLUM component to determine a list of peer nodes with which a node will communicate.

Security. The Security component plays an integral part in all communication

performed between nodes. When one node communicates with another, the Security

system must verify that the communication is legal. Furthermore, the Security

component must protect sensitive user data when it gets transferred over the network.


Node Node

Auctioning -- -------------------- Auctioning



Security Security



Communication Communication





Figure 2.3 Intercomponent Communication



Communication. The Communication component has the responsibility of

handling all low-level communication between nodes. It interacts with the Security









subsystem to accomplish communication among components on different nodes. For

example, when a trade proposal is propagated from one auction to another, the proposal

must pass through the Security and Communication layers of each node en route to the

receiving auction. This relationship is depicted in Figure 2.3.

Naming. The Naming system is responsible for name resolution in the Network.

The Communication system relies heavily on this component. It is undesirable for

components to refer to OCEAN nodes strictly by their IP addresses. The reason for this is

that IP addresses can change, not to mention that they can be obscured by firewalls. In

addition, it is desirable to not only locate computers in the Network, but it is also

necessary to identify other entities so that they may be located. These entities include

computing tasks, data, and resources. The Naming and Communication subsystems

provide this functionality: locating any OCEAN entity on the Network.

Negotiation. The Negotiation component allows traders to automate the process

of negotiation. The Auctioning system determines who are potential trading partners.

However, the Negotiation system provides the means for traders to agree on the terms of

a contract. This includes resolving conflicts that arise when a trader has many potential

trading partners.

Task Spawning and Migration. The Task Spawning and Migration (TSM)

component is responsible for the proper dissemination and execution of computing tasks

in the Network. When a contract for the execution of a computation is successfully

negotiated the TSM subsystem will migrate computing tasks to remote servers through

the Security and Communication layers at each node. When the server receives the









task(s) it is to execute, they must be started and run to completion, or until some

negotiated time limit has elapsed. Also, that task may spawn new tasks and so on.

Local Accounting. Each node uses the Local Accounting component to

communicate with the centralized accounting system. When contracts are successfully

negotiated and subsequently honored (or not) the Local Accounting subsystem will

ensure that the transaction is logged to the Central Accounting system.

This thesis is mainly concerned with four parts of the node architecture: the Trade

Proposal API (Chapter 4), the Node Configuration and Operation API (Chapters 5 and 6),

Trader component (Chapter 5) and the Auctioning component (Chapter 5). It should be

noted that at the time of this writing all other software components, and the Trader

component to a lesser extent, remain in the design phase of the software life cycle. In

fact, this thesis represents the first implementation of components of the OCEAN

software system, save for a simple prototype developed with the JavaSpaces technology

[27]. The interested reader is encouraged to consult the OCEAN web site [18] for

ongoing developments.















CHAPTER 3
TRADE PROPOSAL SCHEMAS


3.1 The Need for Standardization

In order for trade to occur in the market, it must be possible for traders to express

their proposals in formats that all OCEAN nodes can understand. In the case of resource

providers, this includes information describing all of the resources at their disposal and

the prices at which they will be offered. In the case of buyers, they must express their

resource requirements and the prices at which they will bid for their computations to be

performed. However, this is not a trivial problem, because the requirements buyers

impose on providers may be complex. For example, a buyer may require sophisticated

graphics hardware, a high-bandwidth network connection, or strict security protocols.

Similarly, there may be many hardware and software resources that a provider makes

available, and they may only be available according to predefined schedules.

Thus it becomes necessary to express OCEAN trade proposals in a standardized

format. By using structured trade proposal representations, any OCEAN node can parse

relevant trading information from a proposal description and submit the proposal to its

auction. In addition, with relative ease, tools can be developed that generate trade

proposals from Graphical User Interface input, or programmatically from an API.

Another benefit of standardizing trade proposal formats is realized when the OCEAN

market can find no trader to honor the submitting trader's request. The trade proposal can

be submitted to a competing market, in hopes that it can find a suitable match for the

20









trader. Because the proposal is expressed in a standard format, the referred market would

be able to parse all relevant information contained in the proposal, and attempt to find a

suitable trading partner. In this case, the referring market could charge a "finder's fee," or

employ a similar compensation vehicle, so that it does not give referrals on a completely

altruistic basis.


3.2 XML in the Auctioning System

Having established a need for the standardization of trade proposal formats, it is

necessary to examine how these format schemas are constructed and used. The

Extensible Markup Language, XML [33] was chosen as the framework for expressing

trade proposals and their formats. This choice was motivated by two of the greatest

benefits of XML. That is, XML provides a way to convey metadata, or data that

describes data. Often this is called self-described data [12]. This is significant because a

trade proposal document is self-descriptive. In other words, all trading data plus

information describing the trading data is contained in one document. Also, because

XML is entirely text-based, it is platform independent. This is important to the OCEAN

system because it is to be deployed on many platforms.

The subset of the XML family of technologies that is most relevant to this thesis

is XML Schema [36]. At the time of this writing, this is a newly approved

recommendation of the governing body of the XML standard, the World Wide Web

Consortium, or W3C [35]. The schema recommendation is a replacement for the older

Document Type Definition (DTD) specification, and enhances the expressive power of

data description languages [12].









The XML Schema specification defines the format taken by an XML schema.

XML schemas define the legal structure of a set of XML documents. An XML document

that conforms to an XML schema is said to be valid [12] with respect to the schema.

From an application development standpoint, the major benefit of using a schema to

define the structure of a class of documents is that applications which depend on the data

contained in valid instance documents have a well-established set of rules to follow when

generating or parsing the XML content.

Another benefit of the Schema specification is that schemas are easily extensible;

anyone may extend the schemas to suit their needs [10]. This feature contributes to the

openness property of OCEAN. If any of the trade proposal schemas are extended, the

new schemas can be used in place of the originals. This is because a valid instance of the

new schema is technically a valid instance of the extended schema [10]. At the time of

this writing, administration of the trading schema formats is controlled by the OCEAN

project. However, in the future if the OCEAN project is successful, it would be desirable

to relinquish administrative control of the schemas to a non-profit standards body such as

the World Wide Web Consortium [35]. In that case, parts of the standard set of protocols

that define OCEAN are administered by a non-partisan organization.


3.3 OCEAN Trading Schemas

XML schemas were developed to provide languages for expressing trade

proposals in the OCEAN system. These schemas establish the constructs that are

required to describe a trade proposal in a computational market. This includes formats

for expressing computing resources, prices, schedules, and other entities. There are four

separate, though not necessarily independent, schema documents. Taken together, the









schemas form a data model for conducting trade in the market. All of the complete

schemas are printed in the Appendix.

Note on Graphical Notation. The following sections contain figures that were

generated with the XML Spy Integrated Development Environment [1]. Figure 3.1

shows a legend for some of the diagramming components used.


i---------,
o- -optional Optional Element


required Required Element


Begin a choice among elements


SBegin a sequence of elements




Figure 3.1 Diagramming Notation Legend

3.3.1 Resource Schema

The resource schema, listed in section A.1 of the Appendix, defines constructs for

commonly used resources in any computational market. In many cases, describing a

resource is in part dependent upon the notion of a measurement. In the OCEAN

schemas, a measurement is an element with attributes for the scalar measurement

quantity and its associated units, according to recommendations given by Martin et al.

[12]. The attribute "value" is of decimal type, and "units" is a string. In general an

instance of a measurement appears in the following form.











Following are the defined resource constructs and descriptions of the data types

that define them. A description of the data model for each data type is given where

necessary. Examples of valid instances of data types are given where relevant.

CPU. CPUType is the data type for describing CPUs. The data contained in a

CPUType are an optional Platform element and an optional ClockSpeed

measurement element. ClockSpeed is a measurement with units of"GHz" or "MHz".

Platform is an element that contains an Operating System and an Architecture

construct. Useful extensions of the data type could include cache size and benchmark

ratings. Figure 3.2 shows a diagram of the structure.



--; Architecture
SPlatform
CPUType ..-- ..
-------------
--c ClockSpeed


Figure 3.2 CPU Structure

Operating System. OSType is the data type for describing an Operating

System. This type contains an attribute "value" that identifies the Operating System.

Legal values for "value" are "Windows," "Solaris," and "Linux." The type also contains

an optional attribute, "version," for specifying the Operating System version. Useful

extensions to this type would include more operating systems, and define the legal strings

for Operating System version.

Architecture. ArchType is the data type for describing CPU architecture. This

type contains an attribute "value" identifying the hardware architecture. Legal values for

"value" are "x86" and "Sparc". Useful extensions to this type would include more









hardware architectures, such as PowerPC, MIPS, and so on. An example of an element

of type CPUType follows.









Memory. MemoryType is the data type for describing a measurement of

memory. The "units" attribute must be one of "TB," "GB," "MB," or "KB." Note that a

MemoryType does not have to imply main memory, only a memory measurement. An

example element of type MemoryType appears as follows.



Graphics Hardware. Graphic sHWType is the data type for describing

graphics hardware. This type contains one element, VideoMemory, of type

MemoryType. Below is an example of an element that conforms to type

GraphicsHWType. A useful extension of the type could include manufacturer and

product number.





Network Connection. NetworkConnectionType is the data type for

describing a network connection. It contains one element, of type BWType. The

BWType data type describes network bandwidth. It is a measurement, with legal "units"

attribute values of "Mbps" and "Kbps". This data type does not distinguish between

bandwidth to the network backbone or to the Local Area Network; a useful extension









would include such definitions. The example below depicts an element of type

NetworkConnectionType.





Data Object. A Data Object is a general-purpose description for a collection of

data. DataObj ectType is the data type for describing a Data Object. It contains a

DataObj ectID element, which has a string value. The string value of

DataObj ect ID contains an OCEAN data object name, which identifies it uniquely on

the Network. At the time of this writing, its proposed format is described in [19]. A

DataObj ectType also has an optional Size element, which is of type

MemoryType. Below is an element of type DataObj ectType.



ocean://www.oceani.com/@oceanappl/dataobj1




3.3.2 Price Schema

The price schema, listed in section A.2 of the Appendix, defines the constructs

that traders use to specify the prices of commodities in the market. Following are the

data types and descriptions of data models for each price construct. Legal examples are

provided where relevant.

Currency Amount. A Currency Amount is commonly used by price constructs,

and is defined by the CurrencyAmountType. A Currency Amount is a quantity of

some currency. For example, 2 US Dollars (USD), or 1 British Pound (GBP). This is

similar to a measurement as described in Section 3.3.1, but instead of an attribute named









"units," it has an attribute named "Currency" to identify the currency used. At the time of

this writing, the "Currency" attribute is a string type, but in the future will be restricted to

recognized 3-letter currency codes. An element of type CurrencyAmountType

appears below.



Flat Price. A Flat Price, described by the FlatPriceType data type,

represents a time independent price in the market. This is distinct from a time dependent

price, which is a price per unit time. It should be noted that a Flat Price only makes sense

by itself if some time value is associated with the price. For example, a seller indicates a

time limit on the use of its resources if specifying a Flat Price. This would ensure that a

buyer's computation does not take over a seller's resources for an exorbitant amount of

time. This should be a future extension of the type. A flat price has one child element,

CurrencyAmount, of type CurrencyAmountType. An example of a

FlatPriceType appears below.





Time Dependent Price. Described by the TimeDependentPriceType data

type, this is a time dependent price in the market. A time dependent price is a currency

amount per some span of time. For example, 0.01 USD per 1 second is a time dependent

price. The data type has two child elements. One is a CurrencyAmount, of type

CurrencyAmountType. The second is a Timespan element, of type duration.

The duration type is a standard XML Schema data type that defines a span of time.










ISO 8601 Date and Time Formats [10], specifies its structure. Below is an element of

type TimeDependentPriceType.



PT1.OS






FlatPrice CurrencyAmoun




Prpnceslf~ B __ CurrencyAmount
TimeDependentPrice u-recmon
Timespan


FlatPlusTimeDependentCombo



Figure 3.3 Price Structure

Price. The data type Price defines the Price construct. A diagram of the

elements and types involved with the construct is given in Figure 3.3. The data type has

one of three possible child elements. The child can be FlatPrice, of type

FlatPriceType. Also the element can be a TimeDependentPrice, of type

TimeDependentPriceType. Or, the element can be a combination of the other two

price descriptions, a FlatPlusTimeDependentCombo. It has two elements, one of

type FlatPriceType and one ofTimeDependentPriceType. A

FlatPlusTimeDependentCombo element would be useful in specifying a price that

consists of an initial fee, plus rental fees. Defining the Price data type gives a uniform

way for dependent schemas and dependent applications to access one Price element










without being concerned with the underlying price type. An interesting extension to the

Price construct could include a definition of a payment plan. For example payment may

be required up-front, or upon completion of a computation. Below is an element of type

Price.







Schedule. The Schedule construct also has a data type that shares its name. Its

purpose to define an availability or reservation schedule. This data type consists of a

collection of ScheduleItem elements, explained below. The structure of the two

constructs is shown in Figure 3.4.


-slariTime
Schedule Scheduleltem -Times---


endTime


Figure 3.4 Schedule Structure

Schedule Item. The Schedule Item construct is described by a ScheduleItem

element. This element contains a start time plus a choice between an end time or time

span. Taken together, the two elements describe the starting time and the duration of a

schedule item. The startTime element is of type dateTime. Like the duration

type, dateTime is specified by ISO 8601 [10]. The Timespan element is of type

duration. The endTime element is of type dateTime, as startTime is. When

endTime is used, the duration is simply the difference between startTime and










endTime. Following is an example element of type Schedule, with two elements of

type ScheduleItem.


+getAuction() : Auction


Figure 5.3 Auction Creation Classes









In this thesis, the DoubleAuct ion class implements the Auc t ion interface

and the DoubleAuctionFactory class implements the AuctionFactory

interface. The DoubleAuctionFactory returns a DoubleAuction object in its

createAuction () method. When an OCEANNode object is created, the default

AuctionFactory implementation is DoubleAucitonFactory. However, this

can be set via the changeAuction (AuctionFactory) method, and there is also a

constructor which accepts an AuctionFactory interface.

The Auc t ion implementation used by the OCEANNode can be switched

dynamically by calling its changeAuction (AuctionFactory) method, passing an

implementation of the AuctionFactory interface. This sets the reference that the

AuctionBuilder keeps to its AuctionFactory attribute. To plug in a different

implementation of the Auc t ion interface, one must first implement

AuctionFactory so that its createAuction () method returns the desired

Auction implementation. For example, suppose there are classes NewAuctionImpl

and NewAuctionImplFactory that implement the Auction and

AuctionFactory interfaces, respectively. Then the following code will cause an

OCEANNode object to use NewAuctionImpl as its auctioning class.

OCEANNode node;
node.ChangeAuction(new NewAuctionImplFactory());

Note that the above sample assumes that the createAuction () method of

NewAuctionImplFactory returns an object of type NewAuctionImpl.

Agent creation is nearly the same process. The OCEANNode keeps a reference

to an AgentBuilder, which in turn keeps a reference to an AgentFactory instance.











The difference in implementation is that the getAgent () method of AgentBuilder

requires a parameter of type OCEANDoc. This parameter is in turn passed on to the

createAgent () method of the AgentFactory, for use in creating the Agent

implementation. Exactly what the Agent does with the OCEANDoc is unspecified, but


the framework dictates that an Agent implementation processes the OCEANDoc to form

TradeProposal implementations to be submitted to an Auction. This is examined

in the next section.

5.3.3 Formation of Proposals


TradeProposal
#p: Price
#tplD : String
+CheckPriceCompatibility(in tp : TradeProposal, in s: Spread) : boolean
+compareTo(in o: Object) :int


Offer
#su :SaleableUnit
+Offer(in su : SaleableUnit)
+CheckPriceCompatibility(in tp : TradeProposal, in s : Spread) : boolean
+compareTo(in o : Object) : int


Figure 5.4 Trade Proposal Classes




In this thesis, the two implementations of the Agent interface, BuyersAgent

and SellersAgent, initiate the creation of TradeProposal implementations. Two


#bi: Bidltem
+Bid(in n : Node, in doc : Document)
+CheckPriceCompatibility(in tp : TradeProposal, in s : Spread) : boolean
+compareTo(in o : Object) : int
+CheckResourceCompatibility(in o : Offer) : boolean









implementations of TradeProposal are provided, Bid and Offer. A diagram of

these classes appears in Figure 5.4. Future implementations are free to implement

Agent and TradeProposal as needed.

An OCEANDoc may describe many trade proposals. The agent classes initiate the

parsing of JobReqsDoc or OCEANResDoc instances to produce collections of Bid or

Offer objects, respectively. A Bid or an Offer is created for each BidItemType or

SaleableUnit element encountered in the document. Upon completion of this

process, each proposal in the collection is submitted to an Auction.

The formation of proposals is actually performed by many classes. The bulk of

the processing is performed by the classes in the Trade Proposal Document API. Each

class in the API wraps a construct in the schema, which collectively form the basis for

trade in the market. Thus the Trade Proposal API classes provide software

representations of all market entities that the auctioning system requires. The classes of

the trade proposal API provide the necessary framework for the auctioning system; the

key is to create these objects. To this end, every class in the API provides a constructor

that accepts a DOM Node as a parameter, as can be seen in Figures 4.2 4.4. The Node

is then parsed at object construction time, setting all class attributes based on the

information contained in the node tree.

In order to form an implementation of a trade proposal is the node tree of the

entity that defines the proposal must be traversed, creating all objects contained in the

proposal during traversal. The process is best illustrated with an example. The simpler

case, formation of an Of fer is examined.









A SaleableUnit defines an Offer, so passing a SaleableUnit to its

constructor as follows will create it.

SaleableUnit su;
Offer o = new Offer(su);

The price can be extracted from the SaleableUnit node. But how is the

SaleableUnit created? Recall that all schema construct classes can be created from

legal node trees, so the BuyersAgent uses the OCEANResDoc instance passed to it to

create the unit with a call to the code below.

OCEANResDoc resDoc;
SaleableUnit su = resDoc.createSaleableUnit(suNode);

suNode is the root node of a SaleableUnit element. When the

SaleableUnit (Node) constructor is invoked, the node tree is traversed, and for each

Resource node encountered, a Resource object is created from that node, and added

to the unit. Thus the SaleableUnit is formed.

5.3.4 Matching Trade Proposals

The Auc t ion interface provides methods to submit proposals, but does not

specify exactly how trading partners are matched. For this thesis, the DoubleAuct ion

class implements this functionality. The price of a bid must be higher than the price of an

offer in order for the two to be a potential match. It is proposed that the auction take the

difference between the two as revenue. This revenue can cover the cost of the auction's

operation and possibly earn a profit. The spread is the minimum difference between two

prices that an auction permits. Because an auction may earn revenue, node operators

have an incentive to forgo propagating proposals. However, in the future, it is proposed

to employ a "kickback" system whereby the nodes in the proposal propagation chain









share the profits earned by the matching node. Then, auctions that receive proposals still

have an incentive to propagate proposals.

The DoubleAuction class makes use of the JavaTM standard data structure

TreeMap to hold active TradeProposal objects. The TreeMap class is useful

because it is a type of priority queue, remaining sorted regardless of the operations

performed. These data structures are sorted according to price. There are two of them,

one for holding active bids, the other for holding active offers. The offer queue is sorted

in ascending order according to price, while the bid queue is sorted in descending order.

In the JavaTM data structures framework, sorting is accomplished by implementing the

Comparable interface.

The matching algorithm is decomposed as follows. Explained is the case where a

bid is entered; the offer case is analogous.

1.) A Bid is formed and submitted to an Auction as described previously.

2.) The TreeMap that contains waiting Offer objects is traversed, in order, until an

Of fer is found such that the two prices are compatible. Two prices are compatible if

(bid price offer price) >= spread. If no such Offer is found, the Bid gets entered

in the active bid queue.

3.) Assuming price compatibility between a bid and an offer, the resource compatibility

must be checked. In other words, the Of fer must contain all resources requested by

the Bid, with each resource rated at or above the specifications indicated in the Bid.

If that is the case, the two are potential trading partners, and the Of fer is removed

from the waiting queue. If the two trade proposals are incompatible in terms of

resources, return to step 2.), beginning with the next proposal in the queue.









5.3.5 Checking Resource Compatibility

The process to check resource compatibility is dependent upon the TreeSet

class. Like the TreeMap class, TreeSet is also a priority queue. The Bid and

Offer classes each provide a method to obtain a TreeSet of Resource objects,

containing their resource requirements and resources, respectively. As with

TradeProposals, Resource objects are also required to implement the Java

Comparable interface, so that they can be entered in a TreeSet. The Comparable

implementation for Resource sorts according to the following criteria:

1.) Each Resource keeps a String data member, resourceType. The value of this

String is the name of the class. Effectively, this groups resources of the same type.

Figure 5.5 shows an example.



NetworkConnection
CPU
CU StableStorage









Figure 5.5 A TreeSet of Resources


2.) Metrics specific to the resource type. For example, assume Memory objects ml and

m2 use the same units of measurement. ml is greater than m2 if its memory amount

is greater than that of m2.

3.) If two resources are deemed equal in terms of metrics, the object ids, as returned by

the Obj ect. toString () method determine order. This method returns the object









name, concatenated with its address in memory, and is unique among objects

operating in the same JVM.

With the resources associated with a Bid and an Offer sorted in a TreeSet,

the resources from the differing TradeProposal implementations can be compared

efficiently. Observe that every resource request must be satisfied, and that the seller may

provide more resources than required. Thus when one resource request will remain

unfulfilled, the proposals are incompatible.

For every requested Resource r in the queue, it must be determined if r has a

compatible resource in the offer resource queue. The following algorithm determines if r

has a compatible resource in the offer queue.

1.) The offer queue is iterated until the current resource is of the same type as r, or until

the resource type in the seller queue is greater than the resource type of r. The latter

case indicates there are no more, or that there never were, resources of the same type

as r in the seller queue. If this is the case, the trade proposals are incompatible.

2.) Now suppose that the current buyer resource r and the current seller resource, call it

s, are of the same type. The seller resource queue is iterated beginning with s, with

each resource in the iteration being checked for compatibility with r. The definition

of compatible varies from resource to resource. For example, assume r and s are

objects of type Memory. Then they are compatible if and only if s has a memory

measurement greater than that of r. The iteration ends when one of three situations

occurs. The iteration has no elements left. Or, the iteration reaches a seller resource

that is not of the same type as r. Either of the aforementioned situations indicate that

r has no resources with which it is compatible. Alternatively, the current seller










resource is compatible with r. Then the compatible resource s is marked as reserved

for r. Note that s is the lowest rated resource that is compatible with r. When the

next buyer resource is evaluated for compatibility, the evaluated seller resources start

with the resource immediately following s. See Figure 5.6.


like resources




s

Figure 5.6 Resource Compatibility

The correctness of the algorithm relies on the fact that the resource queues are

sorted according to their performance metrics. When the algorithm determines a buyer

resource r is compatible with a seller resource s, it is impossible that any resource sorted

after r (i.e. has a higher performance rating) is compatible with any resource sorted

before s (i.e. has a lower performance rating). That is because s is the lowest rated

resource that is compatible with r. See Figure 5.7.


R1 RN









SK SM

Figure 5.7 Compatibility Correctness






73


In the figure above, assume that R1, RN, SK and SM are all of the same resource

type, and that R1 and SM have been found to be compatible. Also assume that iteration

of the seller queue began with SK or at a previous resource, so that R1 and SK are known

to be incompatible. It is impossible for some resource RN rated higher than R1, to be

compatible with SK, a resource rated lower than SM. If it were possible, R1 would be

compatible with SK, because R1 is rated lower than RN.















CHAPTER 6
DISTRIBUTED AUCTION SIMULATION AND RESULTS


6.1 Simulation as a Testing Tool

As has been mentioned at varying lengths, this thesis represents the first major

implementation effort of the OCEAN system, in its current incarnation. Furthermore, at

the time of this writing, there are no users registered with the system, and there are no

OCEAN-aware extant applications. These circumstances lead to the necessity to test the

auctioning system through simulation. Realistically, even if the software components

existed for internode communication, security, Task Spawning, etc., it would still be wise

to test extensively through simulation of the user population to ensure proper interaction

between components before real human users exchange actual monetary funds.

However, the absence of well-defined components implies the need to go beyond

simulating a user pool. Some essential functions were implemented in order to test the

auction system performance. The most notable functionality to be developed is limited

support of internode communication.

In order to understand what kinds of data the Auctioning simulator provides, it is

useful to examine the developed components and how the Auctioning simulator models

the operation of the market. To recap, trade proposals can be generated by the Trade

Proposal API. The Auctioning system consumes these trade proposals, extracting all

relevant trading information, and submitting trade proposals to nodes on the Network,

thereby providing a forum for traders to meet and agree to trade. In a fully deployed

74









system, human users, or programmed agents acting on behalf of human users, will be

submitting trade proposals via the Trade Proposal API. Similarly, auctions will be started

and held for periods of time by human operators, or programmed agents acting on behalf

of human operators. Often auctions will remain active indefinitely. However, node

operators will have the ability to enable or disable auctions. This leads to the purpose of

the simulator-it is a programmed agent that simulates the activities of random users and

node operators.

With this in mind, the simulator provides a set of tools to generate random trade

proposals, and submit them to auctions. The Auctioning component of each node

tabulates performance data during the course of its operation. The simulator also

provides a script that analyzes the performance data files of a set of related auctions,

producing vital statistics regarding the market as a whole.


6.2 Simulator Implementation

The core of the simulator functionality is to randomize the generation of trade

proposals and auction operation. A set of classes that produce randomized schema

constructs via the Trade Proposal API accomplished this. Below is a description of each

class, and what it produces.

JobDocSim. This class has one public method, randomJobDoc (), that

returns a randomized buyer document. JobDocSim provides this functionality by

adding a random number of Bid Items, each of which is generated in a randomized

fashion. The Bid Item type is selected at random. The maximum number of bid items,

the maximum number of Tasks, and the maximum number of resource requests are read

from a configuration file. A randomized Resource Bid or Task simply adds a random









number of randomized resource requests, bound by the maximum resource request value.

Each Task is required to request a CPU, to keep the scenarios somewhat realistic. Task

Lists and Task Groups add a random number of randomized Tasks, bound by the

maximum number of Tasks.

ResDocSim. Like the JobDocSim class, the single public method,

randomResDoc () returns a randomized seller document. This is accomplished by

generating a random number of randomized Saleable Units. The maximum number of

units and the maximum number of resources per unit are read from a configuration file.

A randomized price is assigned to a unit. Also a random number of randomized

resources, bound by the maximum value, are added to the unit. That is how

randomization of a Saleable Unit is accomplished. Each Saleable Unit must include a

CPU, to keep the scenarios realistic.

PriceSim. The PriceSim class generates a randomized price between two

values. For simplicity, it only generates time dependent prices.

ResSim. The responsibility of the ResSim class is to produce a randomized

resource description that will be used in either a buyer or a seller document. The

randomization of a resource is resource dependent. For example, a randomized CPU

selects a clock speed between 100 and 1800 MHz, running Windows NT on an x86

architecture.

NodeSim. The NodeSim class randomizes the operation of a node. The main

purpose of this class is to allow an auction to be held at a node for a randomized amount

of time. Recall that in the future, an auction can be held for an indefinite amount of time.









However, node operators will have the option to disable auctions. Thus the simulator

models this functionality by letting auctions occur for a random amount of time.

While the simulator uses the above classes extensively, the command-line

interface program auc s im allows the user to start auctions and submit proposals,

varying all relevant parameters of the Auctioning system. Listed below are all

parameters that can be configured by the simulator, and a brief description of each.

* timeout specify the timeout period for submitted trade proposals.

* number of buyer documents the number of buyer documents that are submitted to

the auction.

* number of seller documents the number of seller documents submitted to the

auction.

* minimum/maximum auction time auctions can be held for a random length of time,

between the minimum and maximum.

* number of known nodes the number of nodes to put in the known node list of the

auction.

* maximum hops the maximum number of propagation hops that a proposal

undergoes.

Once all parameters are input, the simulator holds an auction for a randomized

length of time, configuring the auction accordingly via an instance of the NodeSim

class. The specified number of randomized proposal documents are generated by the

ResDocSim and JobDocSim classes and entered according to the input parameters.

The simulator reports important auctioning statistics throughout the course of a

simulation run. The vital statistics are number of incoming proposals, the number of









matched proposals, and the number of redundant proposals. Each node keeps track of

these values for its own auction. A simple script reads the data dumped by each auction

to compile results for the distributed auction as a whole.


6.3 The Simulation Scenarios

Simulations were performed on machines in the network of the Computer and

Information Science and Engineering department at the University of Florida.

Two of the machines were multiprocessor servers and the other 8 were single processor

workstations. One server was a Sun Ultra 80 with 4 CPUs rated at 450 MHz and 4.0 GB

of main memory. The other server was a Sun Enterprise 450 with 2 CPUs rated at 400

MHz and 2.0 GB of main memory. The other computers were each Sun Blade 100

workstations, with a 500 MHz CPU and 256 MB of main memory.

Eighty-eight simulations were performed in total. Each simulation represents a

different configuration scenario. The configuration parameters were varied as given

below. Table 6.1 shows the exact configuration of each scenario.

* Number of auctioning nodes: 5 nodes and 10 nodes.

* Number of buyer, seller documents: all combinations of 3 buyer, 6 buyer, 3 seller and

6 seller documents. The buyer and seller documents were generated before running

the scenarios.

* Timeout: 10 s, 20s.

* Maximum hops: 2, 4

* Number of known nodes: 2, 4

* Validating proposals: true, false.










As can be seen from Table 6.1, each scenario was given an identifier, named

according to its parameter configuration. For example, n10b3s3tlOh2k2vN indicates an

auction of 10 nodes (n), where 3 buyer documents and 3 seller (b,s) documents are to be

submitted, with a timeout of 10 seconds (t), maximum hops of 2 (h), number of known

nodes 2 (k), and XML document validation is disabled ("v" for validation and "N" for

no). This nomenclature is used in reporting data throughout this section. There were

eight major groups of scenarios. First, there was a group of scenarios with 10 auction

nodes, and a group with 5 auction nodes. Each of these groups was further divided into a

group with all combinations of 3 or 6 buyer documents and 3 or 6 seller documents. In

each major group, the timeout, maximum hops, number of known nodes, and document

validation parameters are varied.

Table 6.1 Configurations of Simulation Scenarios

simulation ID nodes b docs s docs timeout (s) hops # known validating
n5b3s3t10h2k2vY 5 3 3 10 2 2 Y
n5b3s3tl0h2k2vN 5 3 3 10 2 2 N
n5b3s3tl0h4k2vN 5 3 3 10 4 2 N
n5b3s3t10h4k2vY 5 3 3 10 4 2 Y
n5b3s3tl0h2k4vN 5 3 3 10 2 4 N
n5b3s3tl0h4k4vN 5 3 3 10 4 4 N
n5b3s3t20h2k2vN 5 3 3 20 2 2 N
n5b3s3t20h4k2vN 5 3 3 20 4 2 N
n5b3s3t20h2k4vN 5 3 3 20 2 4 N
n5b3s3t20h4k4vN 5 3 3 20 4 4 N
n5b3s3t20h4k4vY 5 3 3 20 4 4 Y
n5b3s6tl0h2k2vY 5 3 6 10 2 2 Y
n5b3s6tl0h2k2vN 5 3 6 10 2 2 N
n5b3s6tl0h4k2vN 5 3 6 10 4 2 N
n5b3s6tl0h4k2vY 5 3 6 10 4 2 Y
n5b3s6tl0h2k4vN 5 3 6 10 2 4 N
n5b3s6tl0h4k4vN 5 3 6 10 4 4 N
n5b3s6t20h2k2vN 5 3 6 20 2 2 N
n5b3s6t20h4k2vN 5 3 6 20 4 2 N
n5b3s6t20h2k4vN 5 3 6 20 2 4 N
n5b3s6t20h4k4vN 5 3 6 20 4 4 N
n5b3s6t20h4k4vY 5 3 6 20 4 4 Y










Table 6.1 continued


simulation ID nodes b docs s docs timeout (s) hops # known validating
n5b6s3t10h2k2vY 5 6 3 10 2 2 Y
n5b6s3tl0h2k2vN 5 6 3 10 2 2 N
n5b6s3tl0h4k2vN 5 6 3 10 4 2 N
n5b6s3t10h4k2vY 5 6 3 10 4 2 Y
n5b6s3tl0h2k4vN 5 6 3 10 2 4 N
n5b6s3tl0h4k4vN 5 6 3 10 4 4 N
n5b6s3t20h2k2vN 5 6 3 20 2 2 N
n5b6s3t20h4k2vN 5 6 3 20 4 2 N
n5b6s3t20h2k4vN 5 6 3 20 2 4 N
n5b6s3t20h4k4vN 5 6 3 20 4 4 N
n5b6s3t20h4k4vY 5 6 3 20 4 4 Y
n5b6s6tl0h2k2vY 5 6 6 10 2 2 Y
n5b6s6tl0h2k2vN 5 6 6 10 2 2 N
n5b6s6tl0h4k2vN 5 6 6 10 4 2 N
n5b6s6tl0h4k2vY 5 6 6 10 4 2 Y
n5b6s6tl0h2k4vN 5 6 6 10 2 4 N
n5b6s6tl0h4k4vN 5 6 6 10 4 4 N
n5b6s6t20h2k2vN 5 6 6 20 2 2 N
n5b6s6t20h4k2vN 5 6 6 20 4 2 N
n5b6s6t20h2k4vN 5 6 6 20 2 4 N
n5b6s6t20h4k4vN 5 6 6 20 4 4 N
n5b6s6t20h4k4vY 5 6 6 20 4 4 Y
n10b3s3tl0h2k2vY 10 3 3 10 2 2 Y
n10b3s3tl 0h2k2vN 10 3 3 10 2 2 N
n10b3s3tl 0h4k2vN 10 3 3 10 4 2 N
n10b3s3tl0h4k2vY 10 3 3 10 4 2 Y
n10b3s3tl 0h2k4vN 10 3 3 10 2 4 N
n10b3s3tl 0h4k4vN 10 3 3 10 4 4 N
n10b3s3t20h2k2vN 10 3 3 20 2 2 N
n10b3s3t20h4k2vN 10 3 3 20 4 2 N
n10b3s3t20h2k4vN 10 3 3 20 2 4 N
n10b3s3t20h4k4vN 10 3 3 20 4 4 N
n10b3s3t20h4k4vY 10 3 3 20 4 4 Y
n10b3s6tl0h2k2vY 10 3 6 10 2 2 Y
n10b3s6tl0h2k2vN 10 3 6 10 2 2 N
n10b3s6tl0h4k2vN 10 3 6 10 4 2 N
n10b3s6tl0h4k2vY 10 3 6 10 4 2 Y
n10b3s6tl0h2k4vN 10 3 6 10 2 4 N
n10b3s6tl0h4k4vN 10 3 6 10 4 4 N
n10b3s6t20h2k2vN 10 3 6 20 2 2 N
n10b3s6t20h4k2vN 10 3 6 20 4 2 N
n10b3s6t20h2k4vN 10 3 6 20 2 4 N
n10b3s6t20h4k4vN 10 3 6 20 4 4 N
n10b3s6t20h4k4vY 10 3 6 20 4 4 Y
n10b6s3tl0h2k2vY 10 6 3 10 2 2 Y










Table 6.1 continued

simulation ID nodes b docs s docs Timeout (s) hops # known validating
n10b6s3tl 0h2k2vN 10 6 3 10 2 2 N
n10b6s3tl 0h4k2vN 10 6 3 10 4 2 N
n10b6s3tl0h4k2vY 10 6 3 10 4 2 Y
n10b6s3tl 0h2k4vN 10 6 3 10 2 4 N
n10b6s3tl 0h4k4vN 10 6 3 10 4 4 N
n10b6s3t20h2k2vN 10 6 3 20 2 2 N
n10b6s3t20h4k2vN 10 6 3 20 4 2 N
n10b6s3t20h2k4vN 10 6 3 20 2 4 N
n10b6s3t20h4k4vN 10 6 3 20 4 4 N
n10b6s3t20h4k4vY 10 6 3 20 4 4 Y
n10b6s6tl0h2k2vY 10 6 6 10 2 2 Y
n10b6s6tl0h2k2vN 10 6 6 10 2 2 N
n10b6s6tl0h4k2vN 10 6 6 10 4 2 N
n10b6s6tl0h4k2vY 10 6 6 10 4 2 Y
n10b6s6tl0h2k4vN 10 6 6 10 2 4 N
n10b6s6tl0h4k4vN 10 6 6 10 4 4 N
n10b6s6t20h2k2vN 10 6 6 20 2 2 N
n10b6s6t20h4k2vN 10 6 6 20 4 2 N
n10b6s6t20h2k4vN 10 6 6 20 2 4 N
n10b6s6t20h4k4vN 10 6 6 20 4 4 N
n10b6s6t20h4k4vY 10 6 6 20 4 4 Y


Notice that there are 24 scenarios in which XML document validation is enabled,

and 64 scenarios in which validation is disabled. The 24 validating scenarios are

identical to 24 non-validating scenarios, save for the difference in the validation

parameter. This is done to compare performance between the two scenario types. The

validation tests were performed with the most heavily loaded, the least loaded, and an

average load scenario for each major scenario group.

The results returned for each scenario were the total number of submitted buyer

and seller proposals, and the number of these that found at least one match. The number

of submitted seller and buyer proposals is constant within the major scenario groups,

because each scenario group inputs an identical set of documents. To judge the

effectiveness of the auctioning algorithms, it is necessary to establish a performance









baseline. In order to evaluate the effectiveness of the Auctioning system, it must be

known how many proposals actually have a match in the simulation. The proposals that

do not have an existing match are ignored in judging the Auction system's effectiveness.

Note that the number of proposals that have a match is dependent only upon the number

of buyer and seller documents submitted, not on the other parameters. Thus, there is one

baseline measure for each major scenario group. By varying the other parameters and

comparing the results, it is determined which of these have the greatest influence on the

performance of the auctioning system. However, the baseline gives an upper bound on

the possible success rate in matching proposals. Table 6.2 shows the baseline

measurements for the eight scenario groups. Note that the nomenclature for the baseline

ID follows that of Table 6.1.

Table 6.2 Baseline Measurements of Main Scenario Groups

offers bids
base ID nodes b docs s docs total with match total with match total matches
n5b3s3 5 3 3 28 25 44 22 47
n5b3s6 5 3 6 63 60 44 27 87
n5b6s3 5 6 3 28 28 84 38 66
n5b6s6 5 6 6 63 63 84 48 111
n10b3s3 10 3 3 58 53 78 45 98
n10b3s6 10 3 6 123 118 78 56 174
n10b6s3 10 6 3 58 57 156 82 139
n10b6s6 10 6 6 123 122 156 100 222


The eight scenario groups were partitioned into two main groups. Four of them

submit equal numbers of buyer and seller documents to each auction. These groups were

used to test the auctioning system with respect to timeout, maximum hops, and known

node configurations. The other four scenario groups submit unequal numbers of buyer

and seller documents to auctions to examine the capabilities of the auctioning system

under those circumstances.









Figures 6.1 through 6.4 show the number of bids and offers matched for the

configurations in each of the scenario groups in which equal numbers of buyer and seller

documents are submitted. Note that each graph uses the nomenclature described

previously to indicate a scenario's configuration.









matches for 5 node auctions, b=3,s=3


configuration


* offers
* bids


"z Q '


Figure 6.1 Matches for 5 Node Auctions, 3 Buyer and 3 Seller Documents


o

CL~V
c\













matches for 5 node auctions, b=6,s=6


70
60
a 50
S40O
W 30
E 20
10
0


configuration




Figure 6.2 Matches for 5 Node Auctions, 6 Buyer and 6 Seller Documents






matches for 10 node auctions, s=3,b=3


60
50
u 40
4 30
E 20
10
0




configuration


Figure 6.3 Matches for 10 Node Auctions, 3 Buyer and 3 Seller Documents


Offers
Sbids


* offers
* bids











matches, 10 nodes, b=6,s=6

140
120
100
S80 offers
S 60 *1 l 1 1 bids
E 40
20
0

0 I Ip Iy d- 1- 11 1 1

configuration


Figure 6.4 Matches for 10 Node Auctions, 6 Buyer and 6 Seller Documents

Figures 6.5 through 6.8 show the number of bids and offers matched for the

configurations in each of the scenario groups in which unequal numbers of buyer and

seller documents are submitted.



matches for 5 node auctions, b=3,s=6

70
60
S50
u 40 offers
S30 bids
E 20
10
00


N Z" N T "C r

configuration


Figure 6.5 Matches for 5 Node Auctions, 3 Buyer and 6 Seller Documents












matches for 5 node auctions, b=6,s=3


40
35
30
w 25
S20
15
10
5
0


configuration




Figure 6.6 Matches for 5 Node Auctions, 6 Buyer and 3 Seller Documents






matches for 10 node auctions, b=3 s=6


140
120
, 100
80 -
.o

E 40
20
0


nOg uroL L
INNr N "T "T "


configuration


Figure 6.7 Matches for 10 Node Auctions, 3 Buyer and 6 Seller Documents


* offers
Sbids


* offers
Sbids












10 node auctions, b=6 s=3

90
80
70
u 60 -
50 offers
40 bids
E 30
20
0




configuration




Figure 6.8 Matches for 10 Node Auctions, 6 Buyer and 3 Seller Documents



Compare Figure 6.1 with Figures 6.5 and 6.6. Similarly, compare Figure 6.3 with

Figures 6.7 and 6.8. In making these comparisons, a trend can be identified. When the

number of seller documents remains constant and the number of buyer documents is

increased, the number of offers matched approaches the seller baseline with closer

proximity than when equal numbers of buyer and seller documents are submitted. A

similar trend is witnessed for buyer documents. This is especially evident for the 10 node

auctions. This makes economic sense. When a seller is presented with many bids, they

are more likely to find a trading partner. This is an important observation for the future.

When a trader, for example a buyer, is to submit a bid to an auction, the PLUM should

refer the trader to an auction that contains (or is known to contain) an excessive number

of offers to ensure the best chances of matching the bid.





88



timeout effect on matches, h=2,k=2


AL
n5b6s6 n10b3s3
scenario group


Figure 6.9 Timeout Effect on Matches for maximum hops = 2, known nodes = 2



timeout effect on matches, h=4,k=4


iL
n5b6s6 n10b3s3
scenario group


Figure 6.10 Timeout Effect on Matches for maximum hops = 4, known nodes = 4


250


200
w 150
' e-
E 100
50
0


*t = 10
Ot = 20
O baseline


n5b3s3


n10b6s6


250
200
150
100


*t = 10
Ot = 20
E baseline


n5b3s3


n10b6s6











timeout effect on CPU usage, n=10,b=6,s=6

18.0%
16.0%
14.0%
12.0%
2 10.0% -t=10
8.0% *t=20
6.0%
4.0%
2.0%
0.0%
h2k2 h4k2 h2k4 h4k4
max hops, known nodes




Figure 6.11 Timeout Effect on CPU Usage



Figures 6.9 and 6.10 show two differing cases of how varying timeout

length affects the ability of the auctioning system to match proposals. The data is

reported for each scenario group with equal numbers of buyer and seller documents. The

graphs show total number of matches, i.e. bids and offers together. Maximum hops and

known node count are kept constant. These graphs indicate that increasing the timeout

length increases the chance that a proposal will be matched. As can be seen in Figure

6.11, increasing the timeout period can incur a performance penalty. Thus, node

operators should take care when determining the timeout lengths allowed. It would be

prudent to disallow exorbitant timeout periods. In the future, node operators should be

able to remove trade proposals that exceed the maximum timeout allowed by the node.

Figures 6.12 and 6.13 show two cases of the effects that varying the maximum

hops has on the matching capability of the Auctioning system. As can be seen from the








graphs, increasing the maximum hops does not significantly affect the capabilities of the

auctioning system to match proposals.


max hops effect on matches, k=2, t=10


n5b3s3


n5b6s6 n10b3s3
scenario group


*h=2
*h= 4
n baseline


n10b6s6


Figure 6.12 Maximum Hops Effect on Matching, 2 known nodes, 10s timeout


max hops effect on matches, k=4,t=20


n5b3s3


i1Ml
n5b6s6 n10b3s3
scenario group


*h= 2
*h= 4
O baseline


n10b6s6


Figure 6.13 Maximum Hops Effect on Matching, 4 known nodes, 20s timeout


250

200

150

100

50

0