swe 622- distributed systems project phase i eric barnes, david chang, david nelson fisayo...
TRANSCRIPT
SWE 622- Distributed Systems
Project Phase I
Eric Barnes, David Chang, David Nelson
Fisayo Oluwadiya, Xiang Shen
Architecture
Exchange
`
Trader
NetWork
Exchange
`
Trader
TCP Connection
TCP Connection
TCP Connection
TCP Connection
… ...
… ...
Message
Message
Message
Message
Message
Processor
ExchangeServerSqlite
DB
JFrameExchangeGUI
TraderOutput
TraderInput
initDB
start
start
start
quer
y, co
mm
it
query
SwingWorkerstart
update
input queue
TraderInput
TraderOutput
...
output queue
output queue
time msg
time msg
TraderClient
Trader
Monitor
JFrameTraderGUI
TraderWorker
Listener
SwingWorker
Exchange Trader
processed queue
TraderWorker
Listener
start
start
startstart
update
some other exchange some other trader
start
start,
business msg
business msg
sell, buy
start, sync time...
business msg
Exchange
new
one TCP connection
Exchange waits for new connections. Spawn new threads TraderOutput/
Input for each new connection. It also
creates all the queues.
sync time
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:1237237965973buy:Exchange1:Trader2:product_one:756:123.45:1237237970443
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:1237237964619
Exchange Messages:
time:1237237964534
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
t1 t2 t3
•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 requests2. Exchange receives first sell order3. Exchange receives first buy order4. Exchange is already selling a product and receives another
selling order and successfully processes it within set time limit5. Exchange is currently processing a buy order and receives
another and successfully processes it within set time limit6. Exchange is shutdown after processing all orders7. Exchange shuts down normally8. 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.