1. A Dependable Auction System: Architecture and an Implementation Framework Graham.Morgan@ncl.ac.uk

2. Introduction Approaches –Centralized, Decentralized Architecture –Auctions and Servers, Messages, Fault tolerance Implementation –Servers, Components Conclusions

3. Internet Based Auctions – User Domains Large – Popular auction sites may run in excess of 1 million auctions at any one time. Geographically Distributed – Internet based customers from all over the world may interact. Expanding – Continually expanding into diverse products, increasing customer numbers and customer interaction. International Markets – Different national markets employ their own rules and procedures.

4. Centralised Approach Approach commonly used. Client requests are sent (over the Internet) to systems located in a central place for processing. Market regulations and procedures reflect the host nation of the Auction or specified by users (e.g., currency). clients Centralized processing

5. Problems with Centralized Approach Fairness - A customer (client) located geographically close to the central server may have faster server access than a remote client. Responsiveness - As the number of simultaneously arriving client requests increases, the server load increases. Availability - An unreplicated (central) server also constitutes a single point of failure. International Trading – Difficult to exhibit national regulations and procedures. CPU load 100%

6. Decentralised Approach Consists of many, geographically apart subsystems. –Each subsystem provides services to those users who are in its geographical domain, –while frequently coordinating its activities with other subsystems so that the services it provides are also correct and consistent at the system level. clients System wide data

7. Opportunities of a Decentralized Approach Fairness - Clients serviced by a “geographical local” server. This reduces the possibility of great differences in server access times between clients. Responsiveness - Processing load to be shared amongst a number of servers. Availability - Correctly functioning server may assume the responsibility of satisfying the client requests of a failed server. International Trading – Effectively deal with with the autonomy of local markets. CPU load 50%

8. Auctions and Servers Local Auction - Each server provides auctions for local users. Distributed Auction – Auctions may be replicated across a number of servers. Perception – Local and distributed auctions are indistinguishable from each other by a user. Auction A Auction B Auction C Internet Client request (e.g., bid) Summary auction data

9. Distributing Client Requests Initial client request – Satisfied by local server. Summary auction data – Periodically a server combines a number of client requests into a single message and multicasts this message to every other server in the system. These messages are called episode messages. Request history – The contents of episode messages are used by each server to form a history of client requests accepted so far. m2 m1 E(m1, m2)

10. Two key problems to be solved Message Exchange - Multicasting episode messages periodically to all servers is not a scalable way to build the system. –Sensible structuring of the system is needed. System Shrinkage - There may be no need for a server to collaborate with other servers to satisfy client requests. –Better for such a server to reduce its processing load by leaving the global system.

11. Efficient Message Exchange Hierarchical Structure – Partition system into sub-groups Membership - A group consists of one parent and all its children. Each parent may be a member of two groups: –Down-Tree - The group that contains its children. –Up-Tree - For a non-root server, the group that contains its parent. Down-tree of S11 Up-tree of S9

12. Distributing Episode Messages Up the tree – Non-root multicasts aggregated episode message in its up-tree group. Down the tree – Multicasts aggregated episode message in its down-tree group. The root server periodically multicasts only its own episode message in its down-tree group. –Any given client request (sent to any server in the global system) is represented exactly once in the global history computed by every server. M1M2 M1,M3 M4 M5 M4, M5 Up-Tree Down-Tree

13. A Fault-Tolerant Server Passive replication strategy. Only considered crash failure scenario. An implementation of passive replication is achieved via the following services: –A reliable FIFO multicast service - All functioning replicas or none of them receives multicast. –A group membership service Informs the functioning replicas of replica crashes.

14. Implementation - Server MySQL Database Auction Replication Distribution Replication Distribution Auction Router Client requests or episode messages

15. Implementation - Component Provides auction interface.Interface Carries out message processing associated with component. Provides total ordered message delivery, failure detection and reliable multicast. Component implemented via three CORBA objects Message flow Interface Logical processing (distribution or replication) NewTOP Object Group Service Java & ORBacus used

16. Conclusion Allowing a user to bid at any one of the servers is our principle way of achieving scalability. Replication techniques provide increased server reliability. Attractive scenario for conducting auctions on a global scale, as it enables a federation of auction houses to cooperate. A modular approach to deployment. Place a bid? - www.nolah.cs.ncl.ac.uk