1 / 7

Building a Scalable Server with Executable for GUI-Driven Requirements

Learn how to build a server-side executable for heavy process management, state optimization, recovery, and connection management using TCP sockets. Explore the benefits of building a server, such as scaling, parallel processing, and client evolution support. Also, discover how to integrate a GUI and add new functionalities to the server.

nlucio
Download Presentation

Building a Scalable Server with Executable for GUI-Driven Requirements

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. Now we build a server from our executable • Server-side: • Executable • Heavyweight process that stays up • Library (e.g, excel add-in) • Add a message set (will be driven by our GUI requirements) • State management for optimization • Retain our mid-term executable as a regression test driver • Recovery • State re-construction • Connection management (we will use TCP sockets) • Why build a server? • Scaling • Parallel processing • Separate by process boundary so client can be written in a different language/dev environment • Support client evolution (more rapid than server side - mfc, java, .net, etc) • Socket code fragments will be supplied on class page • Heavyweight process vs. thread • Shared memory • Contention management • Ease of debug • Complexity compromise • Parallel processing model • Clustering • Individual machine may have multiple CPU’s, OS may be fine grained

  2. Putting it all together • Teams can build server and client in parallel via stubs • Functionality we will have to add to our server: • Bucketed Risk • Scenario capability • VaR • Position change intra-day (“new business” or trading activity intra-day) • There will be a second grading phase on the server • GUI • Our executable will now become our test driver • GUI environment choice is up to the teams - language/tools are your choice • GUI code will not be graded - it just has to work with your server • The full app will be demo’d during last class by each team. Both team members must present. • We will start drilling into GUI requirements • Now that we can price and calculate risk it’s time to put a nice front end on it! • New functionality will be added to server as well

  3. Measuring trading book change • We can now calculate risk at a point in time for a given book • Credit : Loss Given Default • Market : Interest rate sensitivity • However, the risk changes daily given trading activity and changing market environment… • What is market environment (yield curve or spread change)? • What is the new position (trading activity or “new business”) • What is the new risk given above? • Sensitivities change as valuations change given non-linearity of p/y function • We need an itemized bill: • “Risk Attribution” (what were the biggest contributors to my risk profile)? • “PnL Attribution” (How did I make/lose money?) • If VaR changed materially where did it come from? Big position move or a risk move? • Was it due to Interest Rate movement of Spread movement?

  4. Requirements for Final Submission • Calculate LGD for the book • Calculate LGD given a ratings downgrade scenario: • AA to A (for example) • BBB to BB (Investment grade crosses over to junk) • This is when we’ll need to use the unique ID (SBB_ID) • Calculate change in position given trading activity intra-day • We’ll have a starting book and end-of-day “closing” book • You should be able to: • Load two position files and price by either spread or yield • Calculate Market Value of the trading book • Calculate scenarios by shifting the yield curve • Show how risk has changed given trading activity • Show risk bucketed by maturity band • Calculate hedge amount of the 2 year treasury to flatten out risk in each band • Each team will have to use graphics to meet some aspect of the requirements • Tabular and graphical display integrated • Accept user input for running pre-determined as well as ad-hoc scenarios • Calculate VaR for trading book

  5. Requirements for Front End • Static reports: • Position change (see spreadsheet story-board) • Total Notional Amount, Risk and LGD by: • “Quality” • “Issuer” • User input driven: • Risk and Market Value by maturity band: • Maturity buckets defined as: 0-2yr, 2-5yr, 5-10yr, 10-30yr inclusive • Display Notional Amount of 2 year treasuries (T2 in file) to hedge each bucket • bucket risk = dv01_2yr * Amount • bucket risk = sum of individual risks of each position in the bucket • User should be able to re-run maturity band report with shifted inputs: • Yield curve parallel up and down by 50% (of starting yield curve yields) • User entered spreads at each point (to support ad-hoc shifts) • It is required is to display data in tabular form (see spreadsheet spec) • It is required to display in graphical form as well (use your imagination). • e.g, pie, bar, stacked bar, line, scatter… Solve for Amount: (if long

  6. Code Submission 2 of 3 • Server built with version 1 of message set defined • Stub client wiggling in your language of choice • Your regression harness is now your executable loading tradingbook.txt with answers • Tradingbook.txt and results.txt are posted on class page after mid term submission lecture • Submission will be a server and a python client • Python example is posted with socket code fragment • The client process will write 3 numbers to stdout: • Amount of 2 year treasuries needed to hedge risk in the 30 year maturity bucket • Total market value of portfolio given 100 basis point shift UP of all yields • Total market value of portfolio given 100 basis point shift DOWN of all yields • “run.sh” to start server • Timing info to be written to stdout by server process as before • Bracket message handler with START_TIMER() … END_TIMER() • Download new SBB_util.h/cc to get parameterized version of end_clock(…) • Return real, user and system time as a message to the client • “Client.py” to exec client which will write out results to stdout • Output format (all in 3 decimal places): • Hedge_amount mkt_value+100 mkt_value-100 real user system • I’ll measure client side real, user, sys time by: • $ time python client.py • The real time is our time elapsed end to end time • With the timer routine embedded in our C++ server we can see overhead of: • Python, GUI code, IPC

  7. Requirements for Final Presentation • Architecture: • Description of: • Server-side capabilities • Client-side capabilities • How is logic partitioned between server and client side? • GUI technology choice rationale • “Middleware” protocol • Challenges faced during implementation • How was the work partitioned within the team? • Demonstrate the front end • What questions does the app help the user answer? • Clear description of how to install it, build it and use it • Walk through test-driver of the server side (a requirement!) • I will drive after the presentation is given and ask questions interactively

More Related