الخلاصة

  • وضع RFC 2351 جلسة MATIP فوق اتصال TCP للاتفاق على نوع الحركة والتجميع والترويسة وطريقة العرض ونطاق الطرفيات.
  • كان Open Confirm دليلاً على إعداد جلسة قابلة للاستخدام، لا على حجز مقعد أو إصدار تذكرة أو اكتمال تسليم رسالة Type B.
  • سمحت الوثيقة بتكرار طلب Type A عند غياب الرد، لكنها لم تجعل الصمت دليلاً على أن المحاولة الأولى لم تُنفَّذ.

يبدأ الحد الفاصل من موقف بسيط في مكتب سفر. يرسل الموظف طلباً إلى النظام المركزي ولا يعود الرد. يقول RFC 2351 إن حركة Type A قد تُفقد، وإن المستخدم يستطيع تكرار الطلب عند عدم تلقي جواب. هذه وسيلة للاستمرار، لا تقريراً عما حدث للمحاولة الأولى.

ربما لم يصل الطلب. وربما وصل ورُفض. وربما غيّر مخزون المقاعد، ثم ضاع الرد في طريق العودة. تبدو الحالات الثلاث متطابقة على شاشة الطرفية، لكنها تفرض قرارات مختلفة على إعادة الإرسال والمحاسبة وخدمة المسافر.

لم يُصمَّم MATIP لحسم هذه النتيجة. كان يعالج انتقالاً تاريخياً: تطبيقات وطرفيات طيران سبقت انتشار TCP/IP، وشبكات خاصة يصعب استبدالها دفعة واحدة. وفر البروتوكول طريقة مشتركة لحمل تلك المحادثات فوق بنية أرخص وأكثر قابلية للتشغيل البيني.

طريق مشترك لمعانٍ بقيت محلية

فرّق RFC بين Type A التفاعلي، المستخدم للاستعلام والحجز وإصدار التذاكر والاتصال بين المضيفات، وبين Type B المخصص للرسائل ذات الحماية الأعلى وتعدد الوجهات ودرجات الأولوية. بقيت الصيغ التشغيلية الدقيقة في معايير IATA والاتفاقات الثنائية.

يقع MATIP بين TCP وتطبيق الطيران. خُصص المنفذان 350 و351 لنوعي الحركة. بعد إنشاء TCP، يتبادل الطرفان Session Open وOpen Confirm لتحديد النوع الفرعي والتجميع والترويسة وترميز المحارف ووحدات ASCU. تحتاج مجموعات الإعداد المختلفة إلى جلسات منفصلة.

تصف صفحة RFC Editor الوثيقة بأنها Informational، لا معيار إنترنت ملزماً. قيمتها أنها عرّفت حداً يمكن لنظامين تنفيذه، لا أنها منحت ذلك الحد سلطة على الحجز.

يمكن أن يكون TCP متصلاً وMATIP مغلقاً. ويمكن قبول جلسة MATIP مع رفض بعض وحدات ASCU. ويمكن إعداد الوحدة من دون أن يسمح التطبيق لها بعملية بعينها. ويمكن للتطبيق استلام البيانات قبل أن يثبت النتيجة في السجل الدائم. كل حالة تحتاج إيصالها الخاص.

ماذا أكد Open Confirm؟

في Type A الحواري، يستطيع Open Confirm رفض الجلسة أو قبولها أو قبولها بشروط، مع تحديد الوحدات المرفوضة أو المهيأة. هذا إثبات مهم لاتفاق الطرفين على بنية الجلسة.

لكنه لا يحمل معرف حجز عالمياً، ولا نسخة مخزون، ولا ضمان سعر، ولا قيداً محاسبياً للتذكرة. بقي معنى الحمولة لدى تطبيق الطيران. نقل MATIP المعنى من دون أن يصبح صاحب القرار النهائي فيه.

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

في Type B، يثبت فتح الجلسة توافق خصائص الاتصال. ثم يجب أن تتوافق الرسالة مع قواعد خدمة Type B المستخدمة. قبول القناة لا يثبت أن كل وجهة استلمت الرسالة أو أن النظام التالي نفذ أثرها.

موثوقية البايتات ليست موثوقية الحجز

عرّف RFC 793 TCP كتدفق بايتات مرتب وموثوق بين العمليات. يخص هذا الضمان وصول البايتات، ولا يحدد معناها التجاري أو صلاحية الفاعل أو لحظة الالتزام.

قد تؤكد المكدسة البعيدة البايتات قبل أن يلتزم التطبيق بالعملية. وقد يلتزم التطبيق ثم يفقد العميل الرد. لا يمكن التمييز بأمان إلا بمعرف معاملة دائم، وحالة محفوظة، وطريق لقراءة النتيجة بعد إعادة الاتصال. عنوان IP أو ASCU أو معرف جلسة MATIP يساعد في توجيه الحركة، لكنه لا يصبح تلقائياً مفتاحاً يمنع التكرار.

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

قراءة تاريخية بلا ادعاء انتشار

لا تثبت المصادر أن شركة طيران بعينها نشرت MATIP، ولا أنه واسع الاستخدام في 2026، ولا أنها تصف حادثة حقيقية. إنها توثق كيف أمكن توحيد النقل مع بقاء سلطة التطبيق في مكانها.

توضح حجة Lu Heng عن أولوية الشفرة العاملة هذا الانضباط: قيمة الإشارة المشتركة تأتي مما تستطيع تطبيقات مستقلة ملاحظته فعلاً. إذا تحولت عبارة «قُبلت الجلسة» إلى «اكتمل الحجز»، اكتسب الرمز قوة لا يسندها التنفيذ. ويكمل مبدأ المواصفة الأولية الدنيا الصورة: نوحّد ما يلزم للتشغيل البيني، ونترك القرار المحلي لمن يتحمل أثره.

فتح RFC 2351 طريق IP أمام طرفيات قديمة. ولم ينقل سجل المقاعد إلى الطريق.