قبلت قائمة الانتظار المهمة، لكنها لم تطبع صفحة: تأكيدان في RFC 1179

الخلاصة

• وثقت RFC 1179 بروتوكول LPD بوصفه ممارسة قائمة: daemon يعمل فوق TCP على المنفذ 515 ويتلقى أوامر تخص طابور طباعة مسمى، ومنها أمر بدء طباعة الأعمال المنتظرة.
• في Receive job يؤكد daemon أولاً أمراً فرعياً للملف؛ ثم يضع العميل صفراً ليقول إن تسلسل البايتات المعلن انتهى؛ وبعد ذلك يأتي تأكيد ثان. هذه سلسلة لاستلام ملف، لا شهادة بطباعة صفحة.

كلمة واحدة كانت تخفي عدة انتقالات

لا تنتقل مهمة الطباعة من التطبيق إلى الورق بحركة واحدة. العميل يطلب، وdaemon يقبل خطوة بروتوكول، والطابور يحفظ عملاً منتظراً، وعملية قد تبدأ، وملف التحكم يحدد كيفية فهم ملف البيانات، ثم قد يصدر جهاز نتيجة مادية. لكل انتقال صاحب مختلف ونطاق دليل مختلف.

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

يستخدم LPD بروتوكول TCP، ويستمع daemon إلى المنفذ 515. تنشأ وصلة جديدة لكل أمر، ويأتي رمز ثنائي ثم اسم طابور ASCII ثم معاملات أخرى عند الحاجة. وتطلب RFC أن تقرأ أسماء الأوامر بوصفها تعليمات موجهة إلى daemon. وصول التعليمات ليس هو وقوع الأثر الذي تسميه.

يتضح ذلك في Print any waiting jobs: فهو يبدأ عملية الطباعة إن لم تكن تعمل. ولا يقول إن مهمة محددة اختيرت، أو إن الملفات قابلة للتفسير، أو إن الجهاز يملك ورقاً، أو إن صفحة خرجت. إنه أمر بدء يقع بعد الاستلام وقبل أي مشاهدة للنتيجة.

للاستلام تأكيدان لا تأكيد واحد

بعد أمر Receive job يرسل العميل أوامر فرعية لملف التحكم أو ملف البيانات. وعليه أن ينتظر بعد كل أمر فرعي تأكيد daemon. الأوكتت ذي البتات الصفرية إيجابي، وأي نمط آخر سلبي. يتعلق هذا الرد بقبول الخطوة التالية من التبادل، لا بالحكم على المهمة كلها.

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

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

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

ملف التحكم تعليمات وليس سجلاً موثقاً للهوية

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

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

قيمة LPD التاريخية أنها تسمي ما يستطيع البروتوكول إثباته بدقة: قبل daemon أمراً فرعياً، أعلن العميل انتهاء بايتات، أجاب daemon بعد الإعلان، ووصل أمر لبدء الأعمال المنتظرة. أما الصفحة المطبوعة أو التسليم أو الأثر اللاحق فتحتاج دليلاً من سطح آخر.

المصادر

• RFC 1179 — Line Printer Daemon Protocol