الخلاصة

  • يطلب PUSH من TCP ألّا ينتظر إلى ما لا نهاية وصول بايتات إضافية قبل دفع البيانات المقدَّمة بالفعل.
  • لا تمثل PSH علامة سجل؛ فقد تختلف حدود الكتابة والمقطع ومخزن الاستقبال والقراءة.
  • على البروتوكول الذي يحتاج إلى رسائل أن يعرّف آلية التأطير الخاصة به فوق TCP.

من «الرسالة» إلى التدفق

تجربت مواصفات TCP المبكرة فكرة «الرسالة». وتوضح RFC 793 أن تلك الآلية أعيد وصفها بوصفها وظيفة PUSH. المغزى أن TCP يقدّم تدفقًا متصلًا من الثمانيات، لا سلسلة رسائل تحتفظ بحدودها.

عندما يطلب التطبيق PUSH، فهو يطلب إرسال البيانات التي سلّمها بالفعل وإيصالها سريعًا إلى المستخدم البعيد. إنه طلب يتعلق بالانتظار في المخازن، وليس تغييرًا لنموذج البيانات.

حدود منفصلة

تذكر RFC 9293 أنه إذا أتاحت الواجهة تحديد PUSH في SEND، توضع PSH على آخر مقطع TCP منشأ من ذلك المخزن. ومع ذلك يستطيع TCP تقسيم المخزن أو دمج البيانات أو جمع طلبات PUSH المتتالية أثناء تشكيل المقاطع.

وإذا لم يوفر التنفيذ PUSH للجهة المرسلة، فلا يجوز له أن يحتفظ بالبيانات إلى ما لا نهاية؛ وعندما لا تبقى بيانات أخرى في الطابور، يجب أن يضع PSH على آخر مقطع مخزّن.

قد يمتلئ مخزن الاستقبال وتُعاد البيانات إلى التطبيق قبل رؤية PSH. وإظهار إشارة PUSH المستلمة للتطبيق اختياري؛ فإذا اختارت الواجهة عرضها، فقد يؤدي PUSH أيضًا إلى إعادة مخزن ممتلئ جزئًا. كما أن حجم قراءة التطبيق لا يلزم أن يطابق حجم كتابة المرسل.

لذلك تعبّر PSH عن نية التقدّم، لا عن نهاية سجل تطبيقي. ولا تضمن إرسالًا فوريًا أو عددًا معينًا من المقاطع أو اكتمال قراءة. وتظل قيود التحكم في التدفق والازدحام وNagle والتنفيذ قائمة.

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

المصادر