140 likes | 219 Views
Distributed Trading System SWE 622. Charles Beach Sharita Green Scott Jones James Wolfe. Agenda. Prototype Design Exchange/Trader Communication High Level Implementation Details Clock Calculations Experiment Calculations. System Design. Evaluator. Trader1. TraderX. Logs.
E N D
Distributed Trading SystemSWE 622 Charles Beach Sharita Green Scott Jones James Wolfe
Agenda Prototype Design Exchange/Trader Communication High Level Implementation Details Clock Calculations Experiment Calculations
System Design Evaluator Trader1 . . . TraderX Logs network Exchange1 . . . ExchangeX
Exchange Design Exchange Exec <main> GUI Goods Map<good, price> ExchangeEngine TraderClient Buy/Sell <RMI> Echo Pub/Sub network Trader
Trader Design Trader Exec <main> TraderEngine GUI ConfigFile ExchangeInterface Buy/Sell <RMI> Receive Echoes <Pub/Sub> network Exchange
Communication • Traders communicate with Exchanges via RMI • Register • Buy • Sell • Exchanges echo transactions to Traders via Pub/Sub.
Trader Registration <Configuration File> Trader1 Exchange1 IP RMI-Port Topic Name Exchange2 IP RMI-Port Topic Name TraderEngine ExchangeInterface <Exchange1> ExchangeInterface <Exchange2> network RMI: register() ExchangeEngine ExchangeEngine Exchange2 Exchange1 TraderClient <Trader1> TraderClient <Trader1>
Exchange Transaction Echoes RMI: buy/sell TraderX Exchange network Pub/Sub ExchangeInterface ExchangeInterface Trader1 TraderEngine TraderEngine TraderN TraderGUI TraderGUI
Publish/Subscribe • To send out updates about what products have been bought or sold we will be using Topic structure to publish messages to registered traders from the various exchanges. • Example Trader 1 registers with Exchange 1 and Trader 2 registers with Exchange 1 and Exchange 2. When Exchange 1 receives a buy or sell request it will send a message to the posted queue of Trader 1 and Trader 2. When Exchange 2 receives a buy or sell request it will send a message to Trader 2 queue.
Publish/Subscribe • An asynchronous messaging paradigm where senders (publishers) of messages are not programmed to send their messages to specific receivers (subscribers). Rather, published messages are characterized into classes, without knowledge of what (if any) subscribers there may be. Subscribers express interest in one or more classes, and only receive messages that are of interest, without knowledge of what (if any) publishers there are. This decoupling of publishers and subscribers can allow for greater scalability and a more dynamic network topology. Wikipedia (http://en.wikipedia.org/wiki/Publish/subscribe)
Clock Calculations • Traders are responsible for calculating the clock differences between themselves and the Exchanges. • Exchange timestamp passed back as part of the Trader registration. • Timestamp is used to calculate the “time offset” relevant to its own clock. • Data Staleness • Each transaction is time-stamped by the Exchange • Trader applies its saved “time offset” for the given Exchange to determine the age of the data with respect to its own clock. • Staleness = Tt(now) – (Et(data) + offset) • Traders must invoke the Exchange RMI “register” method every 60 seconds. • Time offset is re-calculated to keep up with the “clock skew” between the clocks.
Offset Calculation Trader Exchange Tt1 RMI register Et Tte (ET) Tt2 Trader Calculations Tte = (Tt1 + Tt2) / 2 Offset = Et - Tte
Experiments • The Traders/Exchanges will output time stamped information to a log file. • Exchanges • Requests from Traders for buying/selling goods. • Trader registrations • Processed Transactions • Detection of Trader failures • Traders • Received transaction events from Exchanges • Requests to buy/sell goods • Time offsets between clock and Exchange clocks. • A stand-alone application will be responsible for performing the Experiments. • Process all of the log files • Make latency calculations. • Processed Orders • Detection of failures (Traders/Exchange crashes) • Clock calculations • Clock Skew between Trader/Exchange clocks. • Network Latency
Planning the Implementation • Initial prototype implementation has been completed • RMI and Pub/Sub communications. • Needs to be implemented • Formalize the prototype. • Time calculations to detect data staleness. • Logging capability. • Stand Alone application to perform experiment calculations.