تبادل المعلومات المالية

يُعرف ترميز رسائل FIX الأصلي باسم ترميز قيمة الوسم. يتكون كل حقل من وسم رقمي فريد وقيمة. يُحدد الوسم الحقل دلاليًا، ولذلك فإن الرسائل ذاتية الوصف. يعتمد ترميز قيمة الوسم على الأحرف، باستخدام رموز ASCII .

8=FIX.4.2|9=65|35=A|49=SERVER|56=CLIENT|34=177|52=20090107-18:15:16|98=0|108=30|10=062| ^ ٥ + ١٠ + ١٠ + ٧ + ٢١ + ٥ + ٧ ^ = ٦٥

FIXML ^{[ 7 ]} هو مخطط XML لرسائل FIX. وهو مكافئ دلاليًا للرسائل المشفرة بقيم العلامات، ولكنه يستفيد من تقنية محلل XML. يُستخدم FIXML عادةً في تطبيقات المكاتب الخلفية والمقاصة، وليس في التداول.

يُعرّف ترميز البيانات الثنائي البسيط ^{[ 8 ]} تنسيقًا سلكيًا باستخدام أنواع بيانات أولية أصلية لأنظمة الحوسبة. ولذلك، يكون ترميز الرسائل وفك ترميزها أقل زمن استجابة بكثير من البروتوكولات القائمة على الأحرف، إذ لا حاجة إلى ترجمة البيانات إلى تنسيق يمكن للحواسيب استخدامه. وإلى جانب مزايا زمن الاستجابة، يكون الأداء أكثر قابلية للتحديد لأن رسائل ترميز البيانات الثنائي البسيط مقيدة بقوالب، ويُفضّل استخدام عناصر بيانات ثابتة الطول. ومن النتائج الأخرى أن الحقول تكون عادةً في موضع ثابت، ما يُغني مُرشّحات الرسائل والموجّهات عن فك تشفير الرسالة بأكملها للوصول إلى الحقول الرئيسية.

طُوِّر بروتوكول SBE من قِبَل فريق عمل الأداء العالي في بروتوكول FIX لدعم التداول عالي الأداء. وقد اعتُبِر ترميز Tagvalue غير مناسب للغرض المطلوب لأنه يعتمد على الأحرف بدلاً من النظام الثنائي، كما أن حقوله ورسائله ذات الأطوال المتغيرة تؤدي إلى أداء غير حتمي.

على عكس بروتوكولي tagvalue وFIXML، فإن رسالة SBE لا تصف نفسها بنفسها. يتم إرسال البيانات فقط عبر الشبكة مع ترويسة بسيطة لتحديد القالب الذي يتحكم في الرسالة. أما البيانات الوصفية التي تصف بنية الرسالة، فيتم تبادلها خارج نطاق الشبكة بين الأجهزة المتصلة.

تنشر منصة FIX Trading Community مخطط XML لمخططات رسائل SBE. قد يحتوي مخطط الرسالة على أي عدد من قوالب الرسائل. يصف القالب الحقول التي تُشكّل الرسالة. بالإضافة إلى ذلك، يُقدّم المخطط قائمة بأنواع البيانات البسيطة والمركبة التي يُمكن إعادة استخدامها بواسطة أي عدد من الحقول.

من الناحية العملية، بافتراض تطبيق بلغة C/C++، ومع مراعاة ترتيب البايتات : تُقابل معظم الأنواع غير المركبة في الرسالة مباشرةً نفس النوع في اللغة. على سبيل المثال، يُقابل عدد صحيح 32 بت uint32_t، وتُقابل السلاسل النصية الثابتة const char *، وتُقابل الأعداد العشرية، floatوهكذا. يمكن إنشاء ملف C/C++ structمن تعريف المخطط. بعد ذلك، عند إعطاء مؤشر إلى مخزن مؤقت للرسالة، فإن الوصول إلى الحقول غير المركبة في الرسالة يُعادل تحويل نوعها إلى مؤشر إلى بنية والوصول إلى عناصر البنية مباشرةً.

/* تم إنشاء بنية من المخطط */ struct Message { ... uint32_t qty ; ... const char * symbol ; ... };void consume_message ( void * incoming_message ) { const struct Message * msg = ( const struct Message * ) incoming_message ; printf ( "تم تداول %u من %s \n " , msg -> qty , msg -> symbol ); ... }

كما طورت مجموعة FIX Trading Community خرائط قياسية بين بروتوكول FIX وبروتوكولات الرسائل الأخرى، بما في ذلك:

• بروتوكول جوجل بافرز
• ASN.1
• JSON

لم يكن لبروتوكول جلسة FIX الأصلي اسم خاص به، إذ كان جزءًا من مواصفات شاملة تغطي دلالات طبقة التطبيق وتشفير الرسائل أيضًا. مع ذلك، بدءًا من إصدار FIX 5.0، تم فصل طبقة الجلسة كمواصفة مستقلة مع إطلاق FIXT. ^{[ 9 ]} كان FIXT مشابهًا إلى حد كبير لطبقة الجلسة الأصلية غير المسماة في الإصدار 4.x، ولكنه قدم ابتكارًا هامًا واحدًا، وهو توفير آلية لدمج إصدارات طبقة تطبيق FIX عبر إصدار جلسة مشترك. الإصدار الحالي من FIXT هو 1.1.

من الناحية النظرية، فإن بروتوكول FIXT مستقل عن النقل. ومع ذلك، فإنه يستخدم عادة عبر بروتوكول التحكم في الإرسال (TCP).

بروتوكول FIXT هو بروتوكول اتصال مباشر بين نقطتين ، يضمن وصول الرسائل في كلا الاتجاهين. تحمل الرسائل المرسلة في كل اتجاه رقم تسلسلي في رأس الرسالة. في حال حدوث عطل في الاتصال، يمكن للطرف الآخر طلب إعادة إرسال الرسائل المفقودة. يدعم البروتوكول وصول الرسائل حتى في حالة انقطاع الاتصال ثم إعادة إنشاء الجلسة لاحقًا.

لتنفيذ إنشاء الجلسات وضمان التسليم، يحدد كل من بروتوكول FIXT وبروتوكول FIX 4.x الكلاسيكي أنواع رسائل الجلسات التالية:

• نبض القلب
• طلب اختبار
• إعادة إرسال الطلب
• يرفض
• إعادة ضبط التسلسل
• تسجيل الخروج
• تسجيل الدخول
• XMLnonFIX

طُوِّر بروتوكول FIXP ^{[ 10 ] من قِبَل فريق عمل FIX عالي الأداء [ 11 ]} لتلبية احتياجات التداول عالي الأداء. وتتمثل الحاجة الأساسية في ترميز وفك ترميز الرسائل بزمن استجابة منخفض، والتحكم في ضمانات تسليم الرسائل.

لضمان زمن استجابة منخفض، تُدعم ترميزات الرسائل الثنائية لكلٍ من طبقة الجلسة ورسائل التطبيق. يتم تجريد تنسيق البيانات الفعلي في مواصفات FIXP، مما يتيح للمستخدمين اختيار ترميز FIX الذي يناسبهم، شريطة أن يتفق النظراء على بروتوكول مُحدد. وقد استُخدم الترميز الثنائي البسيط في المراحل الأولى من التطوير.

يغطي بروتوكول FIXP حالات الاستخدام من نقطة إلى نقطة وحالات البث المتعدد باستخدام العناصر الأساسية المشتركة.

عند إنشاء جلسة اتصال من نقطة إلى نقطة، يتفاوض النظراء على ضمانات التسليم من بين الخيارات التالية:

• قابل للاسترداد: يتم تسليم الرسائل مرة واحدة فقط. في حال اكتشاف ثغرات، يمكن استرداد الرسائل المفقودة عن طريق إعادة الإرسال.
• خاصية التكرار: يتم التسليم مرة واحدة على الأكثر. في حال اكتشاف أي ثغرات، يتم إخطار المرسل، ولكن عملية الاسترداد تخضع لسيطرة التطبيق، إن تم ذلك أصلاً.
• غير متسلسل: لا يضمن التسليم. هذا الخيار مناسب إذا كانت الضمانات غير ضرورية أو إذا تم توفير الاسترداد على مستوى التطبيق أو من خلال قناة اتصال مختلفة .
• ملاحظة: لا ينبغي إرسال أي رسائل تطبيقية في اتجاه واحد من الجلسة.

قد تكون ضمانات التسليم غير متناظرة. على سبيل المثال، قد يُدخل المتداول أوامر عبر تدفق بيانات غير قابل للتنفيذ، بينما تُعاد الأوامر عبر تدفق بيانات قابل للاسترداد. في الأسواق سريعة الحركة، غالبًا ما يكون التأخير المتأصل في إعادة الإرسال غير مرغوب فيه، مما يؤدي إلى ضياع فرص أو صفقات خاسرة.