TSM - Simple Binary Encoding (SBE)

Andrei Bal - Software Developer @ Itiviti

Sistemele financiare folosesc volume mari de mesaje în diferite formate pentru a comunica. Numărul de mesaje poate ajunge și la câteva milioane pe secundă, iar volumul crește în fiecare an. Într-un asemenea mediu, softul utilizat trebuie să fie foarte eficient, iar cea mai des întâlnită problemă este performanța scăzută la codarea/decodarea mesajelor. Protocolul Financial Information Exchange (FIX) a fost creat în 1992 cu scopul de a permite tranzacționarea electronică. SBE este un protocol binar FIX care are ca scop să eficientizeze pe cât de mult cu putință această problemă. În anul 2013, CME (Chicago Mercantile Exchange) i-a însărcinat pe Martin Thompson, Todd Montgomery și Olivier Deheurles să dezvolte o implementare de referință pentru SBE. Principalele motive ale CME pentru dezvoltarea acestui protocol au fost volumul mare de date și obținerea unei latențe scăzute în propagarea datelor.

Protocolul SBE (Simple Binary Encoding) are ca obiectiv optimizarea sistemelor performante de tranzacționare financiară. SBE este optimizat pentru low-latency atât la codare cât și la decodare.

SBE vine ca alternativă a protocolului FIX tradițional. Toate câmpurile documentate în protocolul tradițional sunt suportate și în protocolul SBE.

Design principles

Protocolul are la bază ideea de direct data access, situație care se datorează folosirii de native binary data types și preferinței pentru poziția și lungimea fixă a câmpurilor. În SBE raw-data este opacă, cu alte cuvinte, nu are altă constrângere decât lungimea, câmpurile de dată ocupând doar șiruri de octeți.

Structura mesajelor SBE

Principiile care au stat la baza protocolului SBE:

  1. Copy-Free. Sistemele în general operează cu memory buffers în care mesajele sunt codate și decodate. Protocolul SBE nu folosește niciun memory buffer intermediar, doar memory underlying buffer, pentru aceste transformări ale mesajului.

  2. Native Type Mapping. Folosind native binary data types, lungimea fixă a câmpurilor și Copy-Free design, codarea și decodarea câmpurilor se poate face direct din memory underlying buffer.

  3. Allocation-Free. Codecurile pentru protocolul SBE nu sunt alocate în memorie. Folosind flyweight pattern direct peste memory underlying buffer pentru codare și decodare, nu este nevoie de alocări de memorie pentru aceste obiecte. Fiecare mesaj este identificat printr-un message header template id, astfel se poate identifica codecul ce trebuie folosit.

  4. Streaming Access. Codecurile SBE folosesc memory underlying bufferul într-o progresie, adică fiecare mesaj este codat sau decodat în funcție de poziția la momentul respectiv în memory underlying buffer.

  5. World Aligned Access. Protocolul SBE folosește niște template-uri pentru fiecare mesaj, astfel știm poziția fiecărui câmp atât la codare cat și la decodare. Pentru eficiența maximă, câmpurile mesajului sunt sortate după tip și în ordine descendentă în ceea ce privește dimensiunea.

  6. Backwards Compatibility. SBE este backwards compatible, nu tot timpul se poate face upgrade, astfel un sistem nou poate comunica cu un sistem vechi.

Structura mesajelor

Antetul (header) conține informații referitoare la lungimea mesajului, id-ul șablonului folosit, id-ul și versiunea schiței XML folosite.

Pentru a coda un mesaj este necesară codarea antetului mai întâi și apoi codarea mesajului. La decodare, se decodează antetul mai întâi, iar pe baza id-ului șablonului, va ști ce șablon trebuie să folosească pentru decodarea mesajului.

Câmpurile de bază fac parte din corpul propriu-zis al mesajului, alături de grupurile repetitive și datele variabile.

Elemente folosite în definirea schiței XML:

Elementul este compus dintr-un scalar sau o mulțime de scalari, cum ar fi o mulțime de caractere. Pot fi definite una sau mai multe codări de tipul . Elementul poate fi definit și ca o constantă adăugând atributul presence="constant", în acest caz, trebuie să aibă o valoare asignată.

Exemplu:

<type name=”char1” length=”1” primitiveType=”char”/>
<type name=”int8_t” primitiveType=”int8”
      nullValue=”-128” presence=”optional” 
      minValue=”-127” maxValue=”127”/>

Elementul poate fi compus din orice combinație de tipuri, incluzând elemente de tipul , , și .

Exemplu:

<composite name=”messageHeader” 
 description=”Message identifiers and length of 
              message root”>
    <type name=”blockLength” primitiveType=”uint16”/>
    <type name=”templateId” primitiveType=”uint16”/>
    <type name=”schemaId” primitiveType=”uint16”/>
    <type name=”version” primitiveType=”uint16”/>
</composite>

Elementul poate conține orice număr de elemente . Elementul conține o valoare validă de tipul string. Valoarea string trebuie să poată fi convertită la tipul de data descrisă de atributul encodingType care reprezintă tipul scalar al codării unui câmp simplu.

Exemplu:

<enum name=”OrderSide_enum” encodingType=”uint8”>
    <validValue name=”Buy”>1</validValue>
    <validValue name=”Sell”>2</validValue>
    <validValue name=”Cross”>3</validValue>
</enum>

Elementul poate conține atâtea elemente câte sunt specificate în numărul de biti al primitivei declarate în câmpul encodingType. Spre exemplu, pentru uint8 pot fi declarate 8 elemente . Atributul encodingType se reprezintă tipul de codare efectuată asupra unui scalar.

Elementul este codat sub forma unui bitset. Codarea unui bitset trebuie să fie un unsigned integer.

Exemplu:

<set name=”MiFIDIndicators_set” encodingType=”uint8”>
    <choice name=”DEAIndicator”>0</choice>
    <choice name=”InvestmentAlgoIndicator”>1</choice>
    <choice name=”ExecutionAlgoIndicator”>2</choice>
    <choice name=”CommodityDerivativeIndicator”>3
    </choice>
    <choice name=”DeferralIndicator”>4</choice>
</set>

Pentru a defini un mesaj în schița XML, este nevoie de adăugarea unui element la elementul rădăcină al schiței XML . Atributele name și id sunt obligatorii pentru stabilirea numelui mesajului și al unui identificator numeric unic, numit și template ID.

Elementele care pot fi definite în cadrul unui mesaj în schița XML sunt , și . Nu există limitare în ceea ce privește numărul de apariții pentru fiecare tip.

Tool-ul SBE

Pentru a putea folosi toolul SBE, este necesară mai întâi definirea unei schițe XML care descrie structura mesajelor și a tipurilor de date folosite, într-un fișier xml. Fișierul XML este folosit ca dată de intrare pentru toolul SBE și pe baza lui sunt generate codecuri pentru mesajele definite în fișier.

Toolul este dezvoltat în Java și poate genera codecuri în Java, C++ și C#. Generarea codec-urilor se face prin execuția următoarei comenzi în linie de comandă:

$ java -jar sbe-all-1.8.3.jar 

Itiviti a dezvoltat în Cluj o soluție în Java pentru folosirea protocolului SBE în comunicarea cu Euronext Cash Markets. În acest caz, schița XML a fost definită de către cei de la Euronext și pe baza schiței XML au fost generate cu ajutorul toolului SBE obiecte Java; câte două obiecte pentru fiecare mesaj definit în schița XML, un obiect pentru codarea mesajului, respectiv pentru decodarea aceluiași mesaj. De asemenea a fost generat câte un obiect pentru fiecare element de tipul și .

Referințe:

  1. https://mechanical-sympathy.blogspot.com/2014/05/simple-binary-encoding.html

  2. https://github.com/real-logic/simple-binary-encoding/wiki

  3. https://en.wikipedia.org/wiki/OSI_model#cite_note-3

  4. Simple Binary Encoding Technical Specification Version 1.0 - Feb. 9, 2017