الخلاصة

  • أتاحت RFC 1190 للعقدة الوسيطة أن تقر CONNECT وتوافق على معرّف محلي وتحاول حجز الموارد قبل أن يقرر تطبيق الوجهة المشاركة.
  • كان ACCEPT قرارًا مستقلًا من الوجهة، يعيد FlowSpec التي تحققت فعليًا على ذلك الفرع، لا الطلب الأصلي كما أرسل.
  • احتاج التدفق متعدد الوجهات إلى نتيجة منفصلة لكل هدف وتسوية عند المصدر؛ ولم يثبت القبول وصول الحزم أو نجاح الوسائط لاحقًا.

بُنيت الشجرة قبل أن تتحرك البيانات

نشرت RFC 1190 في أكتوبر 1990 مواصفة Experimental Internet Stream Protocol Version 2، أو ST-II. كانت بروتوكولًا تجريبيًا محدود الاستخدام، لا Internet Standard. وتحفظ سجلات RFC Editor وIETF Datatracker واقعة أن RFC 1819 تجاوزتها؛ لكنها لا تثبت تدفقًا تشغيليًا ولا انتشارًا عامًا.

عمل ST-II في طبقة Internet بجوار IP. لم يعامل البيانات كرزم مستقلة، بل أنشأ شجرة simplex من مصدر واحد إلى هدف أو أكثر. شمل التدفق المسارات والموارد المخصصة والحالة التي تحفظها كل عقدة. كان setup شرطًا يسبق الإرسال.

دفعت البنية كلفة التحكم مبكرًا كي يكون تمرير البيانات سريعًا. قسمت TargetList حسب الفروع، واختير المسار، وحُفظت حالة control، وفاوضت العقد المجاورة على اختصار محلي للتمرير. لكن اكتمال عمل العقدة في موقعها لم يختصر قرار التطبيق في النهاية.

كان الرد الأول يخص علاقة مجاورة

حين تتلقى عقدة وسيطة CONNECT، ترد سريعًا، إن لم يظهر خطأ، بـ ACK أو HID-REJECT أو HID-APPROVE. كان HID معرّف hop قصيرًا يتيح الوصول إلى حالة التمرير بكلفة قليلة.

تجيب الموافقة عن سؤال محدود: هل تستطيع هاتان العقدتان استعمال المعرّف المقترح لهذه العلاقة؟ لا تقول إن الطريق اللاحق موجود، أو إن الموارد البعيدة تكفي، أو إن العملية المستهدفة تعمل، أو إنها ترغب في الانضمام. العقدة الوسيطة مسؤولة عن حالتها، وليست وكيلًا عن تطبيق لا تديره.

كذلك اختلف Name العام للتدفق عن HID المحلي، واختلفت TargetList عن SAP الذي يختار التطبيق الأعلى. لم يكن أي منها هوية إنسان أو تفويضًا مؤسسيًا.

حملت FlowSpec طلبًا وحدًا ونتيجة متغيرة

ضمّت FlowSpec قيم Desired وحدود Limits. كانت Desired ما يرجوه المصدر، وكانت Limits الحد الأدنى الذي لا يجوز للعقد الوسيطة والوجهة تجاوزه إلى الأسفل. فإذا وفر أحد الفروع bandwidth أقل أو delay أكبر أو PDU أصغر، حدّثت العقدة Desired بما حصلت عليه قبل تمرير CONNECT، ما دام الناتج داخل Limits.

وشمل مفهوم الموارد أكثر من سعة الوصلة: forwarding state، وقدرة المعالجة، والbuffers، وسعة الشبكة، ومعرّفات multicast. لم تحدد RFC طريقة واحدة تحجز بها كل شبكة تلك العناصر. بل أقرت بأن شبكات قليلة آنذاك وفرت الحجز، وأن المؤلفين لم يعرفوا شبكة تحجز المجموعة كلها.

لذلك لا تكفي عبارة «تم الحجز». يلزم اسم العقدة ومدير الموارد والفرع والهدف والقيم المطلوبة والمتحققة والمدة وإمكان preemption. ما تحقق محليًا لا يتحول إلى ضمان عالمي.

رأى تطبيق الوجهة اقتراحًا تغير في الطريق

عند target، أكملت host agent تفاوض HID، ثم قدمت إلى العملية المحددة Name وFlowSpec وOptions وGroup ومحدد التطبيق. كان للتطبيق أن يقبل أو يرفض أو يخفض الخدمة المرغوبة.

بعد ذلك فقط أرسلت العقدة ACCEPT أو REFUSE. أخذت الرسالة Reference جديدًا وربطته بـ CONNECT السابق عبر LnkReference. تحققت كل عقدة وسيطة من الصلة، وأقرت الاستلام لجارتها، وأعادت رسالة إلى المصدر على المسار المعاكس.

أغلق طريق العودة سلطة لم يغلقها طريق الذهاب. اختارت وظيفة routing الفرع؛ خصص مدير الموارد ما يملكه؛ وافق الجيران على handle؛ قرر تطبيق الهدف المشاركة؛ وقرر المصدر إن كانت الشروط الراجعة صالحة. لم يرث أي طرف اختصاص الطرف التالي.

أعادت الأهداف عقودًا مختلفة

في شجرة متعددة الأهداف، انتظر المصدر ACCEPT أو REFUSE أو خطأً لكل target. أخبر التطبيق بنتيجة كل فرع عند وصولها، لكن setup لم يكتمل قبل إغلاق جميع النتائج وتفاوض المعرّفات.

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

قبول B لا يعبّر عن C أو D. وهو لا يثبت حتى أن المصدر تبنى شروط B. كانت النتيجة مرتبطة بالهدف والمسار، أما الحالة المجمعة فقرار آخر.

لم يكن ACCEPT إيصال تسليم

احتاج ACCEPT نفسه إلى عبور موثوق نحو المصدر. فإذا لم تتلق عقدة ACK بعد المحاولات، أرسلت REFUSE في اتجاه المصدر وDISCONNECT في اتجاه الهدف. وقد يستولي تدفق أعلى precedence على الموارد بعد الإنشاء؛ تحمل NOTIFY ضمانًا منقحًا؛ وقد يترك CHANGE الفاشل حجزًا تغير جزئيًا ويحتاج recovery.

صرحت RFC 1190 أيضًا بأن ST لا يوفر security services بذاته. فلا يثبت ACCEPT هوية شخص، ولا سلطة قانونية، ولا إذنًا بالفوترة. ولا يثبت وصول البيانات، أو فك الصوت والصورة، أو استفادة مشارك من الجودة الموعودة.

أزالت المراجعة HID وأبقت قرار الوجهة

راجعت RFC 1819 التجربة عام 1995 باسم ST2+، وتحفظ سجلات RFC Editor وDatatracker هويتها. وأكدت ملاحظة IESG أن النسختين ليستا Internet Standard ولا قيد النظر لذلك.

احتفظ ST2+ بتسلسل CONNECT وACK ومدير الموارد المحلي وقرار تطبيق الهدف وعودة ACCEPT. لكنه حذف HID لأن تعقيده أعاق interoperability. وحذف أيضًا subset implementations بعدما تبين أن السماح بجزء من البروتوكول لم يضمن قدرة مشتركة بين التنفيذات.

اختفى الحقل الذي وافقت عليه العقدة في 1990، ولم تختف سلطة التطبيق على المشاركة. هذا يفصل format عن compatibility، والحجز عن consent.

طرحت RFC 1077 قبل ذلك مشكلة الشبكات السريعة خارج سرعة الوسط وحدها. ثم عرّفت RFC 1633 وRFC 2212 أسطحًا أخرى للحجز والخدمة المضمونة. التشابه سياق، وليس دليل نسب مباشر أو نشر أو نتيجة.

المصادر