Distributed Trading SWE 622 Spring 2009.

Slides:



Advertisements
Similar presentations
IT253: Computer Organization
Advertisements

Global States.
Leader Election Let G = (V,E) define the network topology. Each process i has a variable L(i) that defines the leader.  i,j  V  i,j are non-faulty.
SWE 622 Final Project Presentation – Team 1 Yanyan Zhu Virat Kadaru Koji Hashimoto Stephanie Buchner.
Network Administration Procedures Tools –Ping –SNMP –Ethereal –Graphs 10 commandments for PC security.
Scuola Superiore Sant’Anna Project Assignments Operating Systems.
Benefits of Early Cache Miss Determination Memik G., Reinman G., Mangione-Smith, W.H. Proceedings of High Performance Computer Architecture Pages: 307.
Io package as Java’s basic I/O system continue’d.
Distributed Transactions March 15, Transactions What is a Distributed Transaction?  A transaction that involves more than one server  Network.
School of Engineering and Computer Science Victoria University of Wellington Copyright: Peter Andreae david streader, VUW Echo Networking COMP
SWE 622- Distributed Systems Project Phase III Eric Barnes, David Chang, David Nelson Fisayo Oluwadiya, Xiang Shen.
NFD Permanent Face Junxiao Shi, Outline what is a permanent face necessity and benefit of having permanent faces guarantees provided by.
School of Engineering and Computer Science Victoria University of Wellington Copyright: Peter Andreae david streader, VUW Networking and Concurrency COMP.
The Complexity of Distributed Algorithms. Common measures Space complexity How much space is needed per process to run an algorithm? (measured in terms.
Distributed Trading SWE 622 Spring Group Members  Dave Johnson  Akhil Pathania  Sohrab Rezvan  Nick Ton.
Communication & Synchronization Why do processes communicate in DS? –To exchange messages –To synchronize processes Why do processes synchronize in DS?
Distributed Trading System SWE 622 Charles Beach James Wolfe Scott Jones Sharita Green.
Lecture 40: Review Session #2 Reminders –Final exam, Thursday 3:10pm Sloan 150 –Course evaluation (Blue Course Evaluation) Access through.
CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Global States Steve Ko Computer Sciences and Engineering University at Buffalo.
SWE 622- Distributed Systems Project Phase I Eric Barnes, David Chang, David Nelson Fisayo Oluwadiya, Xiang Shen.
Internet and Intranet Protocols and Applications The Internet: Delay, Errors, Detection February, 2002 Joseph Conron Computer Science Department New York.
CSE 486/586 CSE 486/586 Distributed Systems Global States Steve Ko Computer Sciences and Engineering University at Buffalo.
1 Chapter 11 Global Properties (Distributed Termination)
Mutual Exclusion Algorithms. Topics r Defining mutual exclusion r A centralized approach r A distributed approach r An approach assuming an organization.
SWE 622 Exchange Project Team 1 Design Review Spring 2009 Yanyan Zhu Virat Kadaru Koji Hashimoto Stephanie Buchner.
Computer Networking Lecture 16 – Reliable Transport.
GL TRADE Internal Use Only GL Stream Server Module Notification Sequence Diagram December 12th, 2007.
Introduction to Omnet++ By: Mahsa Soheil Shamaee.
School of Engineering and Computer Science Victoria University of Wellington Copyright: Peter Andreae david streader, VUW Echo Networking COMP
PROTOCOL BASICS. 2 Introduction In chapter 3: Circuits and techniques can be employed to transmit a frame of information between 2 DTEs Error detection.
LAN Bridge Spanning Tree Animation Simon Arlott. Broadcast Networks ● In a broadcast LAN, all packets are sent to all hosts – even if they are not the.
Process Management Deadlocks.
Chapter 19: Network Management
TCP - Part II.
Echo Networking COMP
User-Written Functions
Troubleshooting Tools
Chapter 23 Introduction To Transport Layer
Module 10: Managing and Monitoring Network Access
Object-Oriented Network Communication (OOMI)
CMPT 371 Data Communications and Networking
EEC 688/788 Secure and Dependable Computing
Chapter 6: Transport Layer (Part I)
CSE 486/586 Distributed Systems Global States
Lecture 9: Asynchronous Network Algorithms
Chapter 3: Windows7 Part 2.
Advanced Operating Systems
Leader Election (if we ignore the failure detection part)
Overview Jaringan Komputer (2)
Alternating Bit Protocol
Distributed Consensus
EECS 498 Introduction to Distributed Systems Fall 2017
Remote Procedure Call (RPC)
Chapter 3: Windows7 Part 2.
湖南大学-信息科学与工程学院-计算机与科学系
EEC 688/788 Secure and Dependable Computing
Distributed Trading System SWE 622
Android Topics Asynchronous Callsbacks
Persistence: hard disk drive
EEC 688/788 Secure and Dependable Computing
Outline System architecture Current work Experiments Next Steps
CSE 486/586 Distributed Systems Global States
Message Passing Systems Version 2
CSE 486/586 Distributed Systems Reliable Multicast --- 2
Performance Evaluation of a Communication Round over the Internet
Introduction Communication Modes Transmission Modes
Evaluating the Running Time of a Communication Round over the Internet
Message Passing Systems
Presentation transcript:

Distributed Trading SWE 622 Spring 2009

Group Members Dave Johnson Akhil Pathania Sohrab Rezvan Nick Ton

Overview System Design Experiments and Measurements

Peer to Peer Technology, Asynchronous Messaging System Design Peer to Peer Technology, Asynchronous Messaging

Message Types Registration Ping: heartbeat to check for connectivity Ping Acknowledge Time: used to calculate offset Buy Sell

Trader/Exchange Heartbeat Reason To check if Trader or Exchange goes down Also use to check if Trader or Exchange come back up Benefits Timely notification of when a Trader or Exchange goes down Consequence Ping messages are queued there; is currently no way to flush the queue of backlog messages More network traffic

/** * Sends Ping message to all exchange. This reduces thread overhead. */ private void sendPing() { StringBuffer ping = new StringBuffer(); ping.append(MessageType.PING); ping.append(","); ping.append(System.currentTimeMillis()); ping.append(this.traderIP); ping.append(this.traderPort); ping.append(this.traderName); Enumeration<String> en = connectionMap.keys(); while (en.hasMoreElements()) { ExchangeInfo exInfo = connectionMap.get(en.nextElement()); send(ping.toString(), exInfo.exchangeAddress, Integer .parseInt(exInfo.exchangePort)); } private void sendPingEcho(ExchangePingMessage epm){ ping.append(MessageType.PINGACK); send(ping.toString(), epm.getExchangeIP(), epm.getExchangePort());

Time Between Trade and Other Activity (Sell 21)

In JFrameTraderGUI.java public void actionPerformed(ActionEvent e) { final String request = e.getActionCommand(); . else if(request == IOperationsConsole.__SELL21){ String exchange = _exchange.getSelectedItem().toString(); String product = _product.getText(); String price = _price.getText(); String qt = _qt.getText(); LOGGER.info("<====EXPERIMENT:1 START>"); LOGGER.info("<====EXPERIMENT:1 capture trades 2 - 21 elapsed time>"); long elapsedTime = 0; long time = 0; long curTime = 0; for(int i=1; i<=21;i++){ _trader.sell(exchange, product, price, qt); curTime = System.currentTimeMillis(); elapsedTime = curTime - time; time = curTime; LOGGER.info("<====Experiment:1 Trade:" + i + ":ms since last trade. " + elapsedTime ); } LOGGER.info("<====EXPERIMENT:1 END>");

Exchange: Parse Incoming Messages

public void receive(String message) { String mType = MessageType.getMessageType(message); boolean stale = false; if (mType.equals(MessageType.REGISTRATION)) { RegistrationMessage rm = new RegistrationMessage(message); addRemoteEndpoint(rm.getTraderIP(), Integer.parseInt(rm.getTraderListenPort())); sendRegistrationAck(rm); } else if(mType.equals(MessageType.TRADE)){ TradeMessage tm = new TradeMessage(message); if (tm.getOperation().equals(MessageType.BUY)){ if (productList.contains(tm.getProduct()) == true){ gui.logOperation(tm.getTraderName(), tm.getEchoNumber(), tm.getOperation(), tm.getProduct(), tm.getPrice(), tm.getQt(), stale); sendTradeEcho(tm); }else{ tm.rollback(); //decrements the echo number counter }else if (tm.getOperation().equals(MessageType.SELL)){ if (!productList.contains(tm.getProduct())){ productList.add(tm.getProduct()); }else if (mType.equals(MessageType.PING)){ TraderPingMessage tpm = new TraderPingMessage(message); sendPingEcho(tpm); }else if(mType.equals(MessageType.PINGACK)){

}else if(mType.equals(MessageType.TIME)){ TimeAckMessage ttm = new TimeAckMessage(message); Calendar cal = Calendar.getInstance(); String startTime = Long.toString(cal.getTimeInMillis() + cal.getTimeZone().getOffset(cal.getTimeInMillis())); send(new String(ttm.getOperation() + "," + startTime + "," + (cal.getTimeInMillis() + cal.getTimeZone().getOffset(cal.getTimeInMillis())) + ",” + exchangeName + "," + ttm.getId()), ttm.getTraderIp(), Integer.parseInt(ttm.getTraderPort())); }

Exchange: Sending Error

public void errorSending(String message, String remoteHost, int remotePort, IOException exception) { Calendar cal = Calendar.getInstance(); System.out.println("Error sending " + message); System.out.println("Removing remote host " + remoteHost); removeRemoteEndpoint(remoteHost, remotePort); iTraderCount-=1; bUpdateTraderInfo = true; if(iTraderCount==0) gui.updateTraderInfo(iTraderCount, 0); LOGGER.info(remoteHost + " was removed at :" + (cal.getTimeInMillis() + cal.getTimeZone().getOffset(cal.getTimeInMillis()))); }

Exchange-Trader Offset Calculation The calculation is based on the method described in “Distributed Systems: Principles & Paradigms” by Andrew S. Tanenbaum. Figure 1, shows a similar Exchange-Trader arrangement, where: T1 is the time when the request leaves the Trader. T2 is the time when Exchange receives the request. T3 is the time when Exchange sends the response back to the Trader. T4 is the time when Trader receives Exchange response.

Figure 2 Figure 1

Prototype Requirements Traders receive information about all correctly processed orders, and only about those. All traders should display the orders processed by each exchange in the exact same (processing) order, regardless of the possible reordering of messages by the network. Traders should receive information on orders no later than 10 seconds after an exchange processes them, and the sooner, the better. Information received after 10 seconds needs to be marked as stale. Traders should be able to determine automatically how long ago an order was processed. Note: traders may not assume that the local timer is synchronized with the one on the exchange, unless your prototype takes definitive measures to make that happen. In case a trader crashes, all other components should be able to continue operation. Exchanges should recognize the failure and stop echoing processed orders to the trader. Upon restart, and re-register, the trader should be readmitted to the system. In case an exchange crashes, all other components should be able to continue operation. Traders should recognize the failure and send orders only to the surviving exchanges. Recovery mechanisms don’t need to be provided for exchange crashes.

Experiments and Measurements Dave

Experiment 1 Latency between starting to send an order and proceeding with other activities, averaged over at least 20 orders Average latency: 2.68 ms (3 sets of 21 trades) Maximum latency: 11 ms Created a button on the GUI to initiate a sequence of 21 sells Since our messages are sent from the trader asynchronously, we expected the latency to be very low Dave trader – initiate trade Nick trader Akhil exchange Sohrab exchange

Experiment 2 Latency between issuing an order and the last trader receiving it’s echo, averaged over at least 20 orders Average latency: 473 ms Tested with 1 exchange and 3 traders 1 trader sent all 21 trades Captured time message was sent and each message was received, factoring in offsets Dave trader – initiate trade Nick trader Akhil exchange Sohrab exchange – swap echos

Experiment 3 Latency between a trader failure and the last exchange stopping echoing orders, averaged over at least 5 failures Average latency: 18 secs Tested with 3 exchanges, 1 trader Time of trader closing is written to the log file When exchange detects failure (exception raised from message failure), time is recorded Dave trader Nick trader – close window Akhil exchange Sohrab exchange

Experiment 4a: Skew Average and max observed during operation Clock skew Average: 13.5 sec Max: 1 min 14 sec Each trader calculates the offset with every exchange to which it is connected by “time” messages sent at startup Configuration file includes parameter for number of hours to wait before calculating offset again

Experiment 4a: Offset

Experiment 4b: Latency Average and max observed during operation network latency Average: 189 ms (124 trades, 1 direction) Max: 470 ms (124 trades, 1 direction) On both exchange and trader, checkbox and spinner control allow for the simulation of network latency (on/off, 1 - 15 sec) “…assume the propagation delays from A to B is roughly the same as B to A…” Dave trader – initiates trades Nick trader Akhil exchange Sohrab exchange – network latency of 5 then 13 seconds

Experiment 5 Storage footprint on each exchange required to echo orders to traders, as a function of the number of traders (use empirical and/or analytical methods) Storage footprint of Exchange: 1.61 MB Storage footprint on Exchange per Trader: 59 KB x = memory utilized by an idle exchange y = memory used by exchange to communicate with each trader connected n = number of traders connected to exchange z = total memory used by exchange z = x + ny y = (z – x) / n

Experiment 5: Memory Usage

Development Measurements 1: Lines of Code

Development Measurements 2: Level of Effort

Measurement 3 Network traffic: 1 Exchange, 1 Trader, approximately 5 min 37 sec 1 Registration 1 RegistrationAck 10 Time 10 TimeAck 34 Ping (trader) 34 PingAck (exch) 23 Ping (exch) 23 PingAck (trader) = 136 Messages