Påståendet i Irene Aldriges bok (se avsnitt 5.3.1) att ITCH och OUCH skulle vara fördelaktiga över FIX och Rolf Anderssons artikel som vi-sar att FIX är snabbare (se avsnitt 2.2.5) motsäger varandra. Att de två undersökningarna kommer till så olika slutsatser beror troligt på att Andersson gjorde sin undersökning 2010, innan ITCH/OUCH över-gått till en binär kodning. Andersson använde alltså en strängbaserad ITCH implementation och en binär version av FIX, Aldrige talar om binär ITCH men strängbaserad FIX. Detta betyder att de två studierna hade mycket olika förutsättningar. Den slutsats vi kan dra från dessa två vitt skilda resultat är dock densamma, ett binärt, väl implementerat protokoll medför stora fördelar mot ett textbaserat.
Slutsatsen att binära protokoll är bättre än strängbaserade talar till att alla de alternativa protokollen vore bättre än det existerande FIX-protokollet. FIX-binär och ITCH/OUCH har samma problem som text-baserad FIX när det gäller meddelandestruktur. Nämligen att det finns en standard för meddelanden som skrivs över av företagens specifika-tioner och branschstandard. Meddelanden följer oftast bara standarden ungefärligt och anpassas med andra specifikationer. Detta att jämföra med ProtoBuf där det inte finns någon global standard. Ett ProtoBuf meddelande specificeras av ett enda meddelandeobjekt och följer sin specifikation exakt. Det resulterar i många fler specifikationer (en per meddelande), men varje meddelande följer en specifikation.
Att ProtoBuf har möjligheten att skapa helt nya meddelanden ger också en fördel mot de andra protokollen där man ofta utökar existe-rande meddelanden med inte skapar nya. Med ProtoBuf kan till ex-empel flera logon meddelanden specificeras så att interna och externa system loggar in med två olika meddelanden. Eller så kan svaret på en prisfråga innehålla fler parametrar om det är ett testsystem som frågar för att underlätta testning. Att kunna specificera fler meddelanden än ett som fyller samma funktion kan användas till mycket, men det skall också vägas in att alla nya meddelanden skall utvecklas och specifice-ras, risken finns att antalet meddelanden och specifikationer blir svåra att underhålla.
Kapitel 6
Sammanfattning, slutsatser och
fortsatt arbete
Syftet med uppsatsen var att undersöka om det fanns några alternativ till det protokoll som användes för interna kommunikationer. För att hitta vilka problem och fördelar den existerande lösningen hade inter-vjuades de som arbetade med att utveckla och underhålla kommuni-kationsdelarna i två olika system. Resultatet från dessa intervjuer och en undersökning av koden som skrev och läste meddelanden i syste-men användes som grund för att beskriva hur ett protokoll behövde prestera för att förbättra kommunikationen med systemen.
Två av de fyra frågor som ställdes i denna rapport kunde besvaras efter intervjuerna. Vad orsakar det existerade protokollet för problem idag och vad kan förbättras/ riskerar att orsakas av ett annat alternativt protokoll. Det existerande protokollet var stabilt och enkelt att förändra för att passa nya situationer. Det var dock enligt utvecklarna långsamt och mängden ändringar och förbättringar av standard orsakade pro-blem för de som underhöll systemen. Ett nytt protokoll skulle behöva uppnå samma stabilitet och flexibilitet utan att försvåra underhåll.
Två frågor återstod efter dessa intervjuer, vilka alternativ som fanns till det existerande protokoll och vilket, om något, av dessa alternativ som har potential över det existerande. För att besvara dessa under-söktes några protokoll som använts i liknande system. Tre protokoll undersöktes som alternativ till den existerande lösningen. Protokollbe-skrivningar och dokumentation sammanställdes för att skapa en över-blick över protokollen. Sammanställningen jämfördes mot de krav som ställts under tidigare intervjuer och undersökningsfas.
32 KAPITEL 6. SAMMANFATTNING, SLUTSATSER OCH FORTSATT ARBETE
Alla alternativa lösningar som undersöktes visade potential att för-bättra kommunikationen i systemen. En lösning stack dock ut, Pro-toBuf. Med hjälp av ProtoBuf kan systemen använda den existerande meddelandestrukturen där det passar och nya förbättrade meddelan-den mot de system som kräver och kan stödja detta. På det sättet behö-ver inte alla specifikationer skrivas om och de system som inte behöbehö-ver prestandaförbättringen behöver inte förändra lika mycket som om hela protokollet bytts. Samtidigt kan man förbättra den interna kommuni-kationen ännu mer genom att skapa nya, mer skräddarsydda medde-landen för viktiga flöden.
Slutsatsen av detta arbete kan sammanfattas i att det finns bättre lösningar än FIX och att man genom att byta protokoll skulle kunna underlätta utveckling och support. ProtoBuf visar potential att funge-ra bättre än det existefunge-rande protokollet men för att bestämma om ett byte av protokoll är lönsamt skulle ytterligare undersökning krävas. Att implementera en del av kommunikationen med hjälp av ProtoBuf och undersöka hur den delen presterar kan hjälpa till vid uppskatt-ning av hur mycket tid och arbete som krävs för att helt ersätta FIX. Skall externa kommunikationer bytas måste också alla externa parter godkänna ändringen och själva göra en del arbete.
Litteratur
[1] Irene Aldrige. High-Frequency Trading: A Practical Guide to
Algo-rithmic Strategies and Trading Systems. John Wiley & Sons, 2013.
[2] Rolf Andersson. Low Latency Market Data: Are Proprietary Protocols
Needed? http://fixglobal.com/home/low-latency-market-data-are - proprietary - protocols - needed/. Accessed on 2018-05-17. Juni 2010.
[3] FIX Trading Community. FIX Family of Standards. https://www. fixtrading.org/standards. Accessed on 2018-05-18.
[4] FIX Trading Community. Google Protocol Buffers (GPB). https:// www.fixtrading.org/standards/gpb/. Accessed on 2018-07-31. [5] Monica Dalen. Intervju som metod. Gleerups Utbildning AB, 2015. [6] GlobeNewswire. Migration to Binary versions of ITCH and OUCH. https://globenewswire.com/news-release/2015/04/29/729733/ 0 / en / IT INET Migration to Binary versions of ITCH and -OUCH-24-15.html. Accessed on 2018-07-27. April 2015.
[7] Google. Developer Guide. https://developers.google.com/protocol-buffers/docs/overview. Accessed on 2018-07-31.
[8] Michael Gregg m. fl. Hack the Stack. Elsevier, 2006.
[9] NASDAQ. Nasdaq TotalView-ITCH 5.0.http://www.nasdaqtrader. com / content / technicalsupport / specifications / dataproducts / NQTVITCHspecification.pdf. Accessed on 2018-07-26.
[10] NASDAQ. O*U*C*H Version 4.2.http://www.nasdaqtrader.com/ content/technicalsupport/specifications/TradingProducts/OUCH4. 2.pdf. Accessed on 2018-07-26.
[11] OnixS. FIX FAST (FIX Adapted for Streaming) Decoder and Encoder. https://www.onixs.biz/fix-fast-decoder-encoder.html. Acces-sed on 2018-10-04.
34 LITTERATUR
[12] Dimitrios Serpanos och Tilman Wolf. Architecture of Network Systems. Elsevier, 2011.
[13] Julian Skan, James Dickerson och Luca Gagliard. Fintech and the
evolving landscape.https://www.accenture.com/t20161011T031409Z_ _w__/us- en/_acnmedia/PDF- 15/Accenture- Fintech- Evolving-Landscape.pdf. Accessed on 2018-02-14. 2016.
[14] A V Stokes. Communications Standards. Elsevier, 1986.
[15] Michael Tooley och Steve Winder. Newnes Data Communications
Pocket Book. Newnes, 2002.
[16] International Telecommunication Union. Information technology
-open systems interconnecion - basic reference model: the basic model.
Bilaga A
Intervjufrågor
A.1 Intervju 1
• På vilka sätt fungerar kommunikationen mellan system A och sy-stem B bra?
• Vad är det med protokollet som fungerar bra för dig idag? • Finns det några problem med kommunikationen idag?
• Finns det något som tar mycket tid på grund av hur kommunika-tionen är uppsatt?
TRITA -EECS-EX-2019:58