Project: Distributed Trading System

Overview

Your team is charged with building a prototype for a trading system.  Exchanges located in different cities act as brokers, receiving buying and selling orders for goods.  Different exchanges may trade different sets of goods, and the trading price for the same good may be different at different exchanges.  Geographically distributed traders issue buying and selling orders, each order directed to an exchange. 

In your prototype, selling orders identify the good being offered and the asking price.  Exchanges have no initial knowledge of the available goods: goods become available for trading at an exchange only after the first selling order comes in.  As a simplifying assumption, the asking price in each incoming selling order becomes the new trading price of that good at the exchange. Your prototype does not manage the quantity of available goods.  

Buying orders identify the good being purchased and the quantity. (Note: in reality, sellers would determine the next asking price depending on the volume being traded.)  An exchange ignores buying orders for goods that are not traded at that location.

Each exchange echoes all processed buying and selling orders to traders.  This allows traders to follow the activity at each exchange, and to determine where to buy at the most advantageous price.  For simplicity, you may assume that orders are processed by an exchange as soon as they come in (and, in the case of buying orders, provided they pertain to traded goods).

Deployment

Your prototype should support at least two exchanges and at least two traders, each running as a separate process and communicating over the network infrastructure.  You should demonstrate your prototype deployed over at least two machines. Traders and exchanges can be deployed arbitrarily among the machines.

Information about the existing exchanges (name, network address…) may be encoded in a configuration file, which may be replicated as needed.  Upon being started, trader processes read this configuration file and register with every exchange listed (e.g., passing the trader’s network address).  Exchanges have no initial knowledge of traders, and refer to these registrations for echoing processed orders to every registered trader.

Design and implementation

Your team is responsible for designing and implementing a prototype with the following features:

-          Traders should 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.

The interactions among the distributed components may be implemented using RMI, point-to-point asynchronous message passing over TCP/IP, and web services.  You are encouraged to experiment with different interaction mechanisms in your project, choosing one that is appropriate for each different interaction.  For example, traders may use mechanism a to send orders to exchanges, and exchanges may use mechanism b to echo orders to all traders.  Network broadcasting or multicasting mechanisms cannot be used.

Off-the-shelf clock synchronization mechanism such as NTP, also cannot be used. Your team is responsible to design and implement mechanisms to determine whether messages are stale (see above).

You are encouraged to use Java but your team may decide to use another language you are more comfortable with.

GUI

To allow your team to concentrate on the topic of this course, a basic Graphical User Interface is provided in the form of Java code over Swing.  Teams are free to extend, modify, or replace this GUI.

Evaluation

You should take at least the following run-time measurements:

-          latency between starting to send an order and proceeding with other activities, averaged over at least 20 orders

-          latency between issuing an order and the last trader receiving it’s echo, averaged over at least 20 orders

-          latency between a trader failure and the last exchange stopping echoing orders, averaged over at least 5 failures

-          average and max observed during operation

1.      clock skew

2.      network latency

-          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)

-          others you feel appropriate.

You should take at least the following development measurements:

-          total new and modified LOC

-          effort spent in design, coding/integrating, experiments (man-hour)

-          others you feel appropriate.

Note that the grade is not proportional to the results of the evaluation, but rather to how well the evaluation is made.  For example, suppose that team X decides to use RMI while team Y decides to use asynchronous messages.  If team X happens to obtain better results on latency, that doesn’t imply a better grade.  You should feel free to experiment with, and evaluate different design solutions, even if you are not sure they will lead to the best results along a particular aspect of performance.

Logistics

Students will work in teams of 4 or 5: student preference will be taken into account in forming teams, but instructor discretion ultimately applies.

Personal laptops may be used for development and demonstration, as well as GMU student servers.  The prototype must be demonstrated in the regular classroom, either using the GMU network infrastructure, or a private network assembled by the team.  Teams are responsible for all the planning and setup required to demonstrate the prototype.

Deliverables

Prj1: Slides describing (a) prototype design, (b) description of the experiments, and (c) planning of the implementation and evaluation. Budget the slides for a 10 minute presentation.

Prj2: Code of the prototype. This is the final code you will use for the experiments. Although you may write additional scripts or testing programs, your grade will be penalized for changes to the code of the prototype proper.

Prj3: Slides describing (a) prototype design, with revisions, if any, (b) code snippets illustrating key aspects of the design, (c) description and results of the evaluation experiments. Budget the slides for a 30 minute presentation, including demos of relevant experiments.