6.2 Auction Protocol Implementation
6.3.1 AuctionComposer Applications
AuctionComposer consists of three applications: an auction resource provider, an auction test manager and the composer application. Each application is able to run on a different host as communication runs through Remote Method Invocation (RMI) [61]. The resource provider generates auction resources based on predefined resource definitions provided when the ap-plication is started. The test manager reads test definition files and sub-mits tests to the AuctionComposer application which runs and controls simulations.
AuctionComposer
The AuctionComposer application runs auction simulations, playing the part of the auction owner. It maintains a pool of resources which it has been informed of and pending test simulations which have been requested by an auction test manager. When the application is started, several auc-tion threads are created which monitor the pools of tests and resources, each running an auction at a time. The threads cycle through the pool of simulations attempting to run each test. If there are not enough resources of the required type to run a simulation then the simulation is added back to the pool and attempted at a later point.
For each protocol the composer must support a corresponding test run-ner which is provided by the protocol class. Test runrun-ners are implemented to interact with a protocol specific subclass of auction test which is used to create auction settings. In addition, the test runner interacts with the auction resources to run the auction as required by the protocol.
An auction thread when running an auction starts three services: the aforementioned test runner and two listeners, one listens for auction statis-tics, the other logging auction events. In order to retrieve auction statisstatis-tics, a protocol must be set up to publish events of a GAF auction statistic type.
The listeners record the events to a file specified within the auction test
6.3. AUCTIONCOMPOSER DESIGN AND IMPLEMENTATION 115 definition.
Resource Provider
When the resource provider application is started it is passed as arguments the IP address and port that the auction composer has opened for connec-tions and a file location of XML resource definiconnec-tions. Resource definiconnec-tions specify a list of protocol resource types with the corresponding number the provider can maintain simultaneously. When the application starts it reads this file but only instantiates resources as required to the limit con-figured in the test definition.
Once the resource provider has started it connects to the AuctionCom-poser application, informing it of the resource types the provider supports.
When the composer requests a resource it is instantiated and passed to the composer. The composer will inform the resource provider to deallocate the resource at the end of the auction, at which point the provider can instantiate another when requested.
Auction Test Manager
An auction test manager reads XML auction test scenarios and submits them to an AuctionComposer for simulation. Scenarios are are read by a corresponding protocol specific parser which is included within the test manager and instantiated using reflection on the class name from an at-tribute in the test file. A snippet of an example test file showing the def-inition of a polynomial test auction scenario is given in Figure 6.6, where the different attributes are:
• parser: the protocol specific test parser class which parses the XML file. An initial reader will read this before instantiating it using re-flection. The remainder of the file is parsed by this protocol specific test reader.
• timeout: A timeout after which the auction is disbanded with the resources being requested to be deallocated.
• biddingPhase: A timeout after which the auctioneer closes the bid-ding phase and the auction is evaluated.
• maxBidders: The maximum number of bidders to wait for if used in conjunction with the wait for maximum bidders tag.
• waitForMax: A flag which if set informs the auctioneer to close bid-ding once the maximum number of bidders have placed their bid.
This is useful when testing in order to not have to wait for the bid-ding phase to end as a set number of bidders are expected.
• numEvaluators: The evaluator group size, i.e. the number of evalu-ators for each node.
• numMaskPublishers: The number of mask publishers to use.
• threshold: The threshold number of evaluators required to decrypt bids.
• constant: The constant value for weight resolution.
• maxCoefficient: The maximum coefficient which can be used for a random polynomial.
• toLog: A flag which indicates that events should be logged to a log file.
• logDir: The directory containing event logs.
• log: The filename of the log.
• requiresStatistics: A flag which indicates whether to log statistics.
• statsDir: The directory containing statistics logs.
6.3. AUCTIONCOMPOSER DESIGN AND IMPLEMENTATION 117
• statsLog: The filename of the statistics log.
<t e s t s>
<p a r s e r>
nz . ac . vuw . mcs . dsrg . a u c t i o n p r o t o c o l s . s e c u r e . polynomial . t e s t i n g . XMLPolynomialTestParser
</ p a r s e r>
<a u c t i o n timeout=” 900000 ” biddingPhase=” 105000 ” maxBidders=” 30 ” waitForMax=” t r u e ” numEvaluators=” 21 ” numMaskPublishers=” 2 ” t h r e s h o l d =” 1 ” c o n s t a n t =” 5 ” m a x C o e f f i c i e n t =” 10 ” toLog=” f a l s e ” l o g D i r =” ˜/
polynomial/ r e s u l t s /” l o g=” b i d d e r s 3−l o g . t x t ” r e q u i r e s S t a t i s t i c s =” t r u e ” s t a t s D i r =” ˜/ a u c t i o n / polynomial/ r e s u l t s ” s t a t s l o g =” b i d d e r s 3 . t x t ”>
<t i t l e>Polynomial−bidders −3, R1</ t i t l e>
<goods> polynomial . t e s t i n g . PolynomialBidBehaviour ” >
<v a l u a t i o n value=” 1 ” goods=” 0 ”/>
Figure 6.6: Snippet from sample test definition file.
Chapter 7 Evaluation
This chapter empirically evaluates GAF and the three protocols which have been implemented directly within it. Having implemented three pro-tocols in GAF within a testing application allows self-reflection to be made on the framework usability, from both a protocol developer’s and an ap-plication developer’s perspective. The primary objective of this chapter is to determine whether the framework adds overhead to auction protocols and if so, by how much. This evaluation provides a test case of the frame-work and can be built on for a more detailed auction protocol analysis.
Section 7.1 provides the framework evaluation, section 7.2 evaluates each of the different protocols, and section 7.3 concludes the chapter by comparing the three protocols.