SWE 622- Distributed Systems Project Phase I Eric Barnes, David Chang, David Nelson Fisayo Oluwadiya, Xiang Shen.

Slides:



Advertisements
Similar presentations
High Speed Total Order for SAN infrastructure Tal Anker, Danny Dolev, Gregory Greenman, Ilya Shnaiderman School of Engineering and Computer Science The.
Advertisements

Message Queues COMP3017 Advanced Databases Dr Nicholas Gibbins –
Chapter 7 – Transport Layer Protocols
Multiple Processor Systems
Design and Implementation of HTTP-Gnutella Gateway Baoning Wu (baw4) Wei Zhang (wez5) CSE Department Lehigh University.
Network synchronization of Online Games Li, Zetan.
1 Cheriton School of Computer Science 2 Department of Computer Science RemusDB: Transparent High Availability for Database Systems Umar Farooq Minhas 1,
Computer Science Lecture 12, page 1 CS677: Distributed OS Last Class Distributed Snapshots –Termination detection Election algorithms –Bully –Ring.
CS 582 / CMPE 481 Distributed Systems
Distributed Systems Fall 2009 Replication Fall 20095DV0203 Outline Group communication Fault-tolerant services –Passive and active replication Highly.
Distributed Information Systems - The Client server model
© Lethbridge/Laganière 2001 Chap. 3: Basing Development on Reusable Technology 1 Let’s get started. Let’s start by selecting an architecture from among.
Wide-area cooperative storage with CFS
Peer-to-peer Multimedia Streaming and Caching Service by Won J. Jeon and Klara Nahrstedt University of Illinois at Urbana-Champaign, Urbana, USA.
Lecture 12 Synchronization. EECE 411: Design of Distributed Software Applications Summary so far … A distributed system is: a collection of independent.
 Proxy Servers are software that act as intermediaries between client and servers on the Internet.  They help users on private networks get information.
Fundamentals of Python: From First Programs Through Data Structures
Alexander Potapov.  Authentication definition  Protocol architectures  Cryptographic properties  Freshness  Types of attack on protocols  Two-way.
Presenter: Chi-Hung Lu 1. Problems Distributed applications are hard to validate Distribution of application state across many distinct execution environments.
Sun NFS Distributed File System Presentation by Jeff Graham and David Larsen.
Distributed Data Stores – Facebook Presented by Ben Gooding University of Arkansas – April 21, 2015.
A Security Analysis of the Network Time Protocol (NTP) Presentation by Tianen Liu.
WORKFLOW IN MOBILE ENVIRONMENT. WHAT IS WORKFLOW ?  WORKFLOW IS A COLLECTION OF TASKS ORGANIZED TO ACCOMPLISH SOME BUSINESS PROCESS.  EXAMPLE: Patient.
Chapter 2 Applying Practical Automation Speaker : Chuang-Hung Shih Date :
PA3: Router Junxian (Jim) Huang EECS 489 W11 /
INTERNET DATA FLOW Created by David Whitchurch for ISDS 4120 Louisiana State University.
Copyright ®xSpring Pte Ltd, All rights reserved Versions DateVersionDescriptionAuthor May First version. Modified from Enterprise edition.NBL.
LSC Segment Database Duncan Brown Caltech LIGO-G Z.
Distributed Transactions March 15, Transactions What is a Distributed Transaction?  A transaction that involves more than one server  Network.
Remote Access Chapter 4. Learning Objectives Understand implications of IEEE 802.1x and how it is used Understand VPN technology and its uses for securing.
SuccessFactors: Phase 2 Annual Review Process Presented by: Patricia Kelly / VeLonda Dantzler Human Resources Management.
Cloud computing for internet emulator. Professor Muthucumaru Maheswaran Team Members Mia Hochar Simon Foucher David El Achkar David El Achkar Marc Atie.
Client – Server Architecture. Client Server Architecture A network architecture in which each computer or process on the network is either a client or.
How computer’s are linked together.
Some Design Notes Iteration - 2 Method - 1 Extractor main program Runs from an external VM Listens for RabbitMQ messages Starts a light database engine.
SOA-based Collaborative Authoring Andrew Roczniak Multimedia Research Lab University of Ottawa.
SWE 622- Distributed Systems Project Phase III Eric Barnes, David Chang, David Nelson Fisayo Oluwadiya, Xiang Shen.
Practical Byzantine Fault Tolerance
Quality of System requirements 1 Performance The performance of a Web service and therefore Solution 2 involves the speed that a request can be processed.
Server to Server Communication Redis as an enabler Orion Free
Distributed Trading SWE 622 Spring Group Members  Dave Johnson  Akhil Pathania  Sohrab Rezvan  Nick Ton.
The Intranet.
Distributed Trading System SWE 622 Charles Beach James Wolfe Scott Jones Sharita Green.
Fault Tolerant Services
Marcelo R.N. Mendes. What is FINCoS? A set of tools for data generation, load submission, and performance measurement of CEP systems; Main Characteristics:
Computer Science Lecture 3, page 1 CS677: Distributed OS Last Class: Communication in Distributed Systems Structured or unstructured? Addressing? Blocking/non-blocking?
E2E piPEfitters Eric L. Boyd. 2 Agenda NLANR / DAST Advisor Jim Ferguson John Estabrook OWAMP Jeff Boote SONAR Prototype Deployment Eric Boyd.
Client – Server Architecture A Basic Introduction 1.
Antidio Viguria Ann Krueger A Nonblocking Quorum Consensus Protocol for Replicated Data Divyakant Agrawal and Arthur J. Bernstein Paper Presentation: Dependable.
EJB Enterprise Java Beans JAVA Enterprise Edition
SWE 622 Exchange Project Team 1 Design Review Spring 2009 Yanyan Zhu Virat Kadaru Koji Hashimoto Stephanie Buchner.
Connectathon 2009 Gazelle: HL7 V2 EVS, PIX Tests Agents, Automated Testing Project plans for Connectathon 2009 (February 23 rd -27 th 2009 ) November 14.
Javier Argomedo (ESO/DoE/CSE) - Instrument Control Systems 2014 E-ELT M1 Local Control System Network and LCU Prototyping Motivation Requirements Design.
The Intranet.
WWW and HTTP King Fahd University of Petroleum & Minerals
Introduction to Networking , Instructor: Prof. Yan Chen
Internet and Intranet.
Originally by Yu Yang and Lilly Wang Modified by T. A. Yang
Internet and Intranet.
EECS 498 Introduction to Distributed Systems Fall 2017
Computer communications
Internet and Intranet.
Distributed Trading System SWE 622
Specialized Cloud Architectures
Distributed Trading SWE 622 Spring 2009.
Chapter 5 멀티스레드 u-Network Design Lab 4.
Internet and Intranet.
Last Class: Communication in Distributed Systems
Transport Layer 9/22/2019.
Presentation transcript:

SWE 622- Distributed Systems Project Phase I Eric Barnes, David Chang, David Nelson Fisayo Oluwadiya, Xiang Shen

Architecture

Message Format I For business transactions, the messages are line based and each field is separated by a colon. The format is: Op:exchangeName:traderName:product:quantity:price:timeStamp: For example: Trader Messages: sell:Exchange1:Trader2:product_one:0:43.53:0: buy:Exchange2:Trader1:product_two:34:0:0: Exchange Messages: sell:Exchange1:Trader2:product_one:0:123.45: buy:Exchange1:Trader2:product_one:756:123.45:

Message Format II For clock synchronization, the messages are line based and each field is separated by a colon as well. The format is: Time request from trader to exchange: time:exchangeName:traderName:time Time response from exchange to trader: time:time For example: Trader Messages: time:E1:T2: Exchange Messages: time:

Synchronization Problem: Traders (clients) need to determine the age of a message from Exchanges (servers). –Clocks are not guaranteed to be synchronized. –There may be non-trivial latency in the network –A solution is needed to determine clock-skew and network latency to compensate.

Synchronization Clients will query Servers for timestamps. 1.Client will take a timestamp, and send a message to server for server time. 2.Server will take a timestamp upon receipt and immediately send it back to and the original client. 3.Client takes another timestamp upon receipt of the server response. 4.Client will calculate the network latency and clock skew. 1.Network latency will be one half of the difference between the two client timestamps. 2.Clock Skew will be the difference between the average of the two client timestamps and the server timestamp. 5.Client will maintain the clock skews for the Servers it receives messages from and use those values to determine message age.

Synchronization Mechanism t1t2t3 After acknowledgement message has been received from the server, client will have client timestamps for t1 and t3, and a server timestamp for t2. Client will assume that the network latency is approximately symmetrical, and that the server processing time is negligible. The clock offset will be calculated by t2-(t1+t3)/2. This value will be stored in the client and used to determine message age. Server Client

Implementation For Synchronization Assuming the server processing time is negligible. Samples are taken every 5 seconds. Each sample is averaged by three requests. Only the latest sample is saved.

Deployment For Evaluation More than one Exchange will be created More than one trader will be created Exchanges and traders will be deployed to team member’s laptops and/or GMU servers such as mason.gmu.edu or zeus.ite.gmu.edu

Test Cases For Exchange 1.Exchange comes online and is ready to accept sell requests 2.Exchange receives first sell order 3.Exchange receives first buy order 4.Exchange is already selling a product and receives another selling order and successfully processes it within set time limit 5.Exchange is currently processing a buy order and receives another and successfully processes it within set time limit 6.Exchange is shutdown after processing all orders 7.Exchange shuts down normally 8.Exchange crashes

Test Cases For Trader 1.Trader comes online and is ready to send buy/sell orders 2.Trader sends buy order 3.Trader sends sell order 4.Trader receives confirmation for buy/sell order 5.Trader doesn’t receive confirmation for buy/sell order within expected time limit 6.Trader is unable to connect to Exchange 7.Trader shuts down normally 8.Trader crashes

Fault Simulation Simulate clock skew –Modify the system clocks for exchanges and traders Simulate Exchange/Trader failure –Use kill or task manager to terminate exchanges and traders Simulate Network failure –Unplug the network cable –Shutdown the NIC, Network switch etc. Simulate Network latency –Connect the trader and exchange via a SOCKS proxy server –Use open source server such as Simple SOCKS Server for Perl –Modify the code and randomly sleep a few seconds before forwarding the packets

Methods For Verification Manually run the system and use our eye balls Check the log files for verification Possible automation via scripting, such as using Perl Win32::GuiTest etc.