1 / 13

SWE 622 Exchange Project Team 1 Design Review Spring 2009 Yanyan Zhu Virat Kadaru Koji Hashimoto

SWE 622 Exchange Project Team 1 Design Review Spring 2009 Yanyan Zhu Virat Kadaru Koji Hashimoto Stephanie Buchner. Agenda. Project Design Overview Design Issues/Questions Planned Experiments Implementation Plan. Project Design Overview. Design Modules: Middleware

truong
Télécharger la présentation

SWE 622 Exchange Project Team 1 Design Review Spring 2009 Yanyan Zhu Virat Kadaru Koji Hashimoto

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SWE 622 Exchange Project Team 1 Design Review Spring 2009 Yanyan Zhu Virat Kadaru Koji Hashimoto Stephanie Buchner

  2. Agenda • Project Design Overview • Design Issues/Questions • Planned Experiments • Implementation Plan

  3. Project Design Overview • Design Modules: • Middleware • Only job is to connect, send and receive messages. • Does not care about type of message being sent. • Has threads for sending, receiving, detecting connection failure etc. • Notifies trader/exchange of connection or delivery failure • Trader • Each Trader is an Independent process • Has a reference to its own Middleware instance. • Maintains a list of Order echo’s received. • Exchange • Each Exchange is an Independent process. • Has a reference to its own Middleware instance. • Maintains a list of Goods currently sold being sold and previous orders processed. • Messages • Many types of messages (order, echo, offset, etc) • Contains a super class ‘Message’ which acts as a header • Each message type (order, echo, etc) is a sub class of Message

  4. Project Design Overview Exchange List of Traders List of Goods Trader List of Exchanges List of Orders ConnectionFailed(callback) Send(async.) Receive(callback) Middleware ProcessingThread : rmi/p2p : msg HeartbeatThread SendingThread ReceivingThread RMI PToP ConnectionThread

  5. Project Design Overview • OrderGenerator • Generates orders automatically at a desired frequency • Can be stopped or started at anytime • Configuration • Contains information about the exchanges • Type of communication (RMI/PToP) • Other information like IP and port of RMI registry etc.

  6. Design Issues/Solutions • Absence of global clock • Order of echos/late echos

  7. Design Issues/Solutions • Absence of global clock • Which one has the correct time or which one to follow? • All nodes do not communicate with each other • Solution • Each trader maintains an offset relative to each exchange that it is connected to • Actual communication begins only after the offset is applied • Other issues • How many samples of the offset should be taken? • Should they be averaged? • What about max and min values?

  8. Design Issue Trader’s List of Order Echoes – Verify Requirement: • Display all order echoes in the order they were processed. • Some echoes may be outstanding (late) and may not appear on the list. (A later order may appear, an earlier order is not on the list yet.) • When a late echo appears, place in correct order. Mark as stale if > 10 seconds late.

  9. Performance Evaluation Tools used in evaluation - AspectJ • - Systems will communicate over a VPN Dependent variable • Change configuration files at client side

  10. Performance Evaluation Issue 1 • Measure the latency between issuing an order • and the last trader receiving its echo • Conduct this evaluation at client application level • Assumption: Trader Ti issues an order to Exchange Ey • Get Ti’s time t(Ti) before issuing order • Get last Offset value (Oxy) between Tx(Trader x) and Ey (Exchange y) before t(Ti) with (1<=x<=n), n:=trader number • Get each Tx’s time t(Tx) after receiving echo for Ti’s order A • The latency := Max( t(Tx) - Oxy) 1<=x<=n

  11. Performance Evaluation Issue 2 • Measure the latency between trader’s failure • and the last exchange stopping order echoes • Conduct this evaluation at client application level • Both Trader and Exchange applications register listeners to the Middleware, and middleware heartbeat each other • Assumption: Trader Ti goes down • Get last Offset value (Oiy) between Ti and Ey with(1<=y<=m), m:= exchange number • Manually record Ti’s failure time ft(Ti) • Get the time st(Ey) when Ey decides to stop echoing to Ti • The latency := Max(st(Ey)-Oiy) 1<=y<=m

  12. Performance Evaluation Issue 3 • Calculate Clock Skew • Not using Global Network Protocol. • Trader and Exchange send offset messages periodically • Get all Offset values (Oxyτ) between Tx and Eyat τ time unit • Average Clock skew := AVG (Oxyτ – Oxyτ +1) • Maximum Clock skew := MAX (Oxyτ – Oxyτ +1) • The frequency of calculation is not decided yet.

  13. Implementation Plan • Development Timeline 3/22 3/29 4/5 4/12 4/19 4/26 4/30 Coding Testing Prj2 Prototype Implementation Coding Experiment Presentation Evaluation Experiment Prj3 • Roles and Responsibilities Trader – Virat and Stephanie Exchange – Koji Middleware – Koji, all Experiments – Yanyan, all

More Related