الخلاصة

  • القيمة 32 في Fragment Offset تعني موضع البايت 256 في البيانات الأصلية، لا البايت 32.
  • كل جزء يحمل MF=1 يجب أن يحتوي على عدد من البيانات يقبل القسمة على ثمانية؛ أما الجزء الأخير فيمكن أن يخالف ذلك.

الحقل لا يرقّم البايتات مباشرة

يعرّف RFC 791 حقل Fragment Offset على أنه 13 بت بوحدات من ثمانية أوكتات. يضرب المستقبل القيمة في ثمانية ليحصل على بداية البيانات داخل مخطط البيانات الأصلي. لذلك تشير القيمة 32 إلى الموضع 256.

السبب هو توزيع البتات. يمكن لثلاثة عشر بتاً تمثيل 8192 موضعاً. وعند اعتبار كل موضع ثمانية أوكتات، تمتد الإحداثية إلى 65,536 أوكتاً، بما ينسجم مع نطاق Total Length ذي 16 بت. أما البتات الثلاثة الدنيا فلا تُرسل، بل تُستعاد كأصفار.

التوفير يفرض حدّاً على التقسيم

يجب أن يكون موضع بداية الجزء التالي قابلاً للتمثيل بالوحدة نفسها. لذلك، عندما تكون MF=1، يجب أن يكون طول بيانات الجزء الحالي من مضاعفات الثمانية. المقصود هو البيانات، لا الطول الكلي الذي يشمل ترويسة IPv4.

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

الموضع والنهاية دليلان مختلفان

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

يحوّل المستقبل الإزاحة إلى بداية بالبايت، ثم يضم إليها طول البيانات ليكوّن فترة من البيانات الأصلية. يصف RFC 815 إعادة التجميع بفترات مستلمة وثغرات مفقودة؛ فقد يملأ الجزء الجديد ثغرة أو يقلصها أو يقسمها. وتكشف MF=0 الامتداد النهائي، لكنها لا تكفي وحدها لاكتمال إعادة التجميع.

الإحداثي يبقى واحداً عند التقسيم المتكرر

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

يوضح هذا التصميم أن حذف البتات المتوقعة لا يلغي التعقيد؛ بل ينقله إلى حدود الإرسال وإلى استعادة مواضع البايت أثناء إعادة التجميع.

المصادر