الخلاصة

  • وضع RFC 1014، الذي نشرته Sun Microsystems في يونيو 1987، قاعدة تجعل طول كل عنصر مشفّر مضاعفاً لأربعة بايتات. تبدأ السلسلة متغيرة الطول بعدّاد من أربعة بايتات، ثم أحرفها، ثم أصفار تكمل الحد التالي.
  • في مثال الملف داخل الوثيقة، يشغل اسم sillyprog تسعة بايتات من الأحرف وثلاثة أصفار للحشو. يبدأ نوع الملف عند الإزاحة 16. يحدد العدّاد طول الاسم، ويحدد الحشو موضع الحقل الذي يليه.

الفجوة الصغيرة بعد اسم الملف قد تزيح قراءة بقية السجل. لتعرض Sun Microsystems هذه المشكلة وضعت في RFC مثالاً بسيطاً: مستخدم افتراضي اسمه john يحفظ برنامج Lisp يدعى sillyprog، ومحتواه (quit). على الآلتين المختلفتين أن تجدا نوع الملف في المكان نفسه. يكتب XDR العدد 9 أولاً في أربعة بايتات، ثم أحرف الاسم التسعة، ثم ثلاثة أصفار. عند الإزاحة 16 يبدأ نوع الملف. لم تضف الأصفار حرفاً إلى الاسم؛ لقد مهدت الطريق للقيمة التالية.

كان تبادل البيانات سنة 1987 يجمع أجهزة لا تتشابه في طريقة ترتيب القيم في ذاكرتها. ذكرت الوثيقة محطات Sun وأجهزة VAX وIBM PC وCray. قدم XDR، أي التمثيل الخارجي للبيانات، لغة لوصف القيم وقواعد مشتركة لكتابتها في تيار بايتات. استخدم Sun RPC وNFS هذه اللغة لوصف بياناتهما. افترض المعيار أن البايت ذو الثماني بتات ينتقل بمعناه، ثم ألزم العناصر بإيقاع متكرر: مضاعفات أربعة بايتات.

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

يوضح جدول البايتات في RFC الحساب من دون حيلة. الإزاحات من 0 إلى 3 تحمل الطول 9. تبدأ الأحرف عند 4 وتنتهي عند 12. تحتل الأصفار المواضع 13 و14 و15. يبدأ EXEC، نوع الملف المشفّر بالقيمة 2، عند 16. من يعد الأصفار أحرفاً يغيّر الاسم. ومن يقفز إلى الحقل التالي بعد الأحرف مباشرة يقرأه قبل أوانه بثلاثة مواضع. هنا يصبح ضبط الصفوف الصغيرة شرطاً لتفاهم أجهزة كبيرة مختلفة.

تواصل الوثيقة المثال ليتضح أن طول المحتوى يتغير بينما القاعدة ثابتة. يختار النوع EXEC فرعاً يحمل اسم المفسّر lisp: طول 4 وأربعة أحرف. يخزن اسم المالك john بالطريقة نفسها. أما بيانات البرنامج (quit) فطولها ستة بايتات؛ يسبقها العدد 6 وتتبعها صفران. في كل مرة يعرف القارئ أين ينتهي المحتوى وأين تنتهي الوحدة المشفّرة. لا يحتاج كل حقل إلى الطول نفسه حتى يحافظ التيار على ترتيب مفهوم.

ميّز XDR بين السلاسل النصية والبيانات المعتمة. السلسلة في هذا RFC مكوّنة من بايتات ASCII. البيانات المعتمة تحمل بايتاتها من غير أن يفسرها XDR. يمكن إعلان حد أقصى للطول، وتجاوز ذلك الحد خطأ في الترميز. يقدم العدّاد حجم المحتوى اللازم للقراءة والفحص، بينما تضع أصفار الحشو بداية الحقل التالي على حد من أربعة. لكل جزء وظيفة محددة؛ الخلط بين المحتوى والفراغ يفسد القيمة أو موضع ما بعدها.

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

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