الخلاصة

  • بعد أن يعلن الخادم PIPELINING في جواب EHLO ناجح، يستطيع العميل إرسال مجموعة أوامر بلا انتظار جواب كل واحد، مع بقاء الحكم على كل أمر مستقلاً.
  • لا تعمل السرعة إلا إذا عُدّت الأجوبة بحسب موضعها، وتوقفت المجموعات عند تغيّر الحالة، وفُهمت الأجوبة متعددة الأسطر، واحترمت نافذة TCP، ولم يفقد الخادم أي بايت وصل إليه.

كانت الكلفة في الصمت

يتقدم SMTP العادي كسلسلة سؤال وجواب: تعريف، ثم انتظار؛ مرسل، ثم انتظار؛ متلقٍ، ثم انتظار؛ طلب بدء البيانات، ثم انتظار جديد. يشرح RFC 2920 أن زمن الدوران على الوصلات عالية الكمون قد يهيمن على مدة الاتصال كلها.

سمح PIPELINING لعدة أوامر معروفة بأن تنطلق قبل عودة أول جواب. لم يدمج الخادم قراراتها. الذي تداخل هو الانتظار، بينما بقي لكل أمر حكمه.

هكذا صار لدى العميل أكثر من قصد معلق في الوقت نفسه. في النمط المتدرج لا يملك الجواب التالي إلا سؤالاً واحداً. أما في المجموعة فلا بد من دفتر ترتيب دقيق.

لم يكن ترتيب TCP دليلاً كافياً على القدرة

يحفظ TCP ترتيب البايتات، لكن الخوادم المنشورة لم تحفظ دائماً المدخلات التي قرأتها. يسجل RFC 2920 انتقالات اتصال بين عمليات ضيّعت بايتات سبقت قراءتها، وخوادم مسحت مدخل TCP بعد فشل أمر، وأخرى خلطت نتيجة آخر RCPT TO بحالة جميع المتلقين وقرار DATA.

لذلك يبدأ العميل بـEHLO، ولا يختار المسار المتداخل إلا بعد جواب 250 يتضمن PIPELINING. ما يزال سجل امتدادات SMTP لدى IANA يربط الكلمة بـRFC 2920 من دون وسيط.

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

الأمر الذي يغيّر الحالة ينهي المجموعة

يمكن وضع RSET وأوامر المرسل وRCPT TO داخل المجموعة. أما EHLO وDATA وVRFY وEXPN وTURN وQUIT وNOOP فلا تأتي إلا في آخرها، لأن نجاحها أو فشلها يغيّر الخطوة التي يجب أن يتخذها العميل. ولهذا يصلح NOOP نقطة مزامنة.

تفصل القاعدة بين التوازي والاعتماد. يمكن اقتراح عدة متلقين ثم قراءة أحكامهم المستقلة. ولا يجوز التصرف كأن مرحلة البيانات فُتحت قبل وصول جوابها. قد تحدد امتدادات لاحقة حدوداً خاصة؛ غياب التحديد ليس إذناً مفتوحاً.

الموضع يحدد صاحب الجواب

في مثال توضيحي، يؤدي إرسال مرسل وثلاثة متلقين وDATA إلى خمسة أجوبة معلقة. قد تتكرر رموز الحالة وتتغير النصوص بين التطبيقات. يمنع RFC 2920 صراحة مطابقة الجواب بالرمز أو الكلمات.

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

وقد يمتد جواب SMTP على أسطر. يحمل السطر الوسيط شرطة بعد الرمز، ولا يحملها السطر الأخير. عدّ الأسطر كأجوبة يزيح كل الأحكام اللاحقة. يشرح المعنى نتيجةً عُرف صاحبها؛ لكنه لا يكتشف ذلك الصاحب.

لا يمنع TCP المرتب المأزق

يستطيع العميل غير الحاجب قراءة الأجوبة فيما لا تزال كتابة سابقة معلقة. أما العميل الحاجب فيجب أن يضمن أن المجموعة كلها تتسع داخل نافذة TCP. وإلا فقد ينتظر إكمال الكتابة بينما ينتظر الخادم أن يقرأ العميل الأجوبة التي يحاول إرجاعها.

ذكر RFC 2920 تاريخياً نافذة غالباً، وليس دائماً، بحجم 4K ثمانيّات. ليست هذه قيمة حديثة عامة. القاعدة الباقية هي مواءمة المجموعة مع التدفق الفعلي أو القراءة والكتابة بالتوازي.

يزيد PIPELINING مقدار القصد غير المؤكد. يأتي الأداء من التزامن، ويأتي التقدم من حد يمكن إثباته.

تعهد الخادم ألا يمحو المدخل

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

رفض متلقٍ لا يمنح حق حذف أمر لاحق وصل بالفعل. ونقل الاتصال بين عمليتين لا يجعل البايتات المقروءة مسبقاً مادة قابلة للرمي. المخزن يحمل قصداً عبّر عنه العميل.

يمكن جمع بعض الأجوبة العادية، لكن لا يجوز حجب أجوبة أوامر نهاية المجموعة أو الأوامر غير المعروفة. الكفاءة لا تخفي اللحظة التي يجب عندها تغيير الحالة.

تغيرت الوثائق وبقيت الآلية

قدّم RFC 1854 الامتداد عام 1995. حل RFC 2197 محله في 1997 وقال إن التغيير تحريري فقط. أصبح RFC 2920 هو STD 60 في 2000. ويصف RFC 5321 SMTP بأنه حوار متدرج عمداً، يمكن تعديله بامتداد متفق عليه بين الطرفين.

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

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

المصادر والحدود

يأتي التسلسل من RFC 1854 وRFC 2197 وRFC 2920، وإطار SMTP من RFC 5321، والتسجيل الحالي من IANA. لا تقيس هذه المصادر الانتشار الحالي أو إعدادات المنتجات أو مقدار الأداء أو معدل الأعطال.