الخلاصة

  • حافظت RFC 3678 على استدعاءات عضوية البث المتعدد القائمة لتوافق الشفرة والثنائيات، وأضافت خيارات ودوالاً لمرشح المصادر بدلاً من تغيير الواجهة القديمة.
  • يغيّر الاستدعاء التفاضلي مصدراً واحداً في المرشح الجاري. أما استدعاء الحالة الكاملة فيستبدل النمط والقائمة معاً؛ وتقول RFC 3678 إن هذه الطريقة لازمة لتغيير نمط INCLUDE/EXCLUDE من دون مغادرة المجموعة، ومفيدة للقوائم الكبيرة لأنها تتيح تحديثاً ذرياً.

لم يكن ممكناً توسيع الاستدعاء القديم

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

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

مصدر واحد في كل مرة

تغيّر الواجهة التفاضلية المرشح على مراحل. في عضوية Any-Source Multicast يقبل المستقبل المصادر عموماً في البداية؛ ثم يحظر أو يرفع الحظر عن مصدر بعينه. أما في Source-Specific Multicast فيضيف التطبيق مصدراً محدداً إلى مجموعة الاستقبال أو يزيله منها. والحالة السابقة للاستدعاء مهمة: تميّز الوثيقة بين تركيبات العضوية والخيار غير الصالحة وبين حالات مثل حظر مصدر محظور أصلاً أو ترك مصدر لم يُنضم إليه.

تكون هذه القواعد مقتصدة حين يحتاج التطبيق إلى تعديل صغير واحد. يمكنه أن يقول «احظر هذا المصدر» أو «انضم إلى هذا المصدر» من دون إعادة إرسال بقية القائمة. لكن المعنى يعتمد على حالة العضوية والمرشح الحالية؛ فالعملية تفاضلية وليست تصريحاً كاملاً بالحالة المطلوبة بعد انتهائها. وتعرّف المذكرة خيارات خاصة بـIPv4 مثل IP_ADD_SOURCE_MEMBERSHIP وأخرى مستقلة عن البروتوكول مثل MCAST_JOIN_SOURCE_GROUP. RFC 3678

أو استبدال الحالة كاملة

تؤدي واجهة الحالة الكاملة وظيفة مختلفة. يمرر التطبيق نمط المرشح — MCAST_INCLUDE أو MCAST_EXCLUDE — وقائمة المصادر كاملة لإدراجها أو استبعادها. ويحل هذا الاستدعاء المرشح الجديد محل القديم بدلاً من تطبيق تغيير عضوية واحد عليه.

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

وللقراءة عقدها الخاص: يستطيع التطبيق تقدير حجم المخزن المؤقت، ثم يتلقى عدد المصادر الكلي ويعيد الاستدعاء إذا لم تكف المساحة. وإذا وضع التنفيذ حداً أقصى لحجم القائمة، فقد يفشل الإعداد الذي يتجاوزه بالخطأ ENOBUFS. لذا فإن «استبدال الكل» طريقة لإدارة الحالة، لا وعداً بسعة غير محدودة. RFC 3678

مجموعة واحدة ونظاما عناوين

أبقت المذكرة تراكيب وخيارات خاصة بـIPv4 لتقليل التغييرات على تطبيقاته القائمة. وعرّفت أيضاً صيغاً مستقلة عن البروتوكول تحمل المجموعة والمصدر في تراكيب مقبس تستوعب أكثر من عائلة عناوين، مع تحديد الواجهة المحلية على حدة بواسطة فهرس الواجهة. وفرت RFC 3493 كثيراً من أساس واجهة مقابس IPv6، لكنها لم تحدد عمليتي الانضمام والمغادرة للبث المتعدد على نحو مستقل عن البروتوكول؛ وهنا أضافت RFC 3678 ما كان ناقصاً. RFC 3493

يسهل الخلط بين ثلاثة معانٍ عند قراءة توقيع الدالة: عنوان المجموعة هو وجهة البث المتعدد، وعنوان المصدر يحدد المرسل، أما فهرس الواجهة فيقيد العملية بموضع الاتصال المحلي. صحح الخطأ التقني المعتمد رقم 2524 لاحقاً وصف وسيط getsourcefilter في القسم 5.2.2؛ فبدلاً من «عنوان IP المحلي للواجهة» ينبغي أن يكون «فهرس الواجهة»، كما ورد في دالة الضبط قبل ذلك. وصحح خطأ تحريري معتمد آخر إحالة إلى قسم أخطاء غير موجود. لا يغير أي منهما نموذج الترشيح، لكنهما يثبتان معنى الوسيط. أخطاء RFC 3678

الترشيح هنا لا يعني الترشيح في كل الشبكة

قد يطبّق نظام التشغيل مرشح المصادر محلياً حتى عندما لا تدعم أجهزة التوجيه IGMPv3 أو MLDv2. وبذلك قد يحصل التطبيق على أثر داخل المضيف من دون أن يثبت توقف الحزم غير المرغوبة عن عبور الوصلة المحلية. تنقل البروتوكولات معلومات المرشح نحو جهاز التوجيه؛ وهذا مسار شبكي منفصل عن استدعاء المقبس، وله حالته ومساره الخاصان. وتصف RFC 3376 وRFC 3810 وRFC 4604 أجزاء من هذا السلوك في جهة الشبكة. RFC 3376 RFC 3810 RFC 4604

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

RFC 3678 وثيقة Informational وتقول صراحة إنها لا تحدد معياراً للإنترنت، كما تحيل إلى مواصفة المقابس الرسمية. أما إسهامها التاريخي فأضيق وأكثر تحديداً: حماية الاستدعاءات القديمة، وإبقاء تعديل مصدر واحد بسيطاً، مع توفير بديل يستبدل المرشح كله عند الحاجة إلى تغيير الحالة أو التعامل مع قائمة كبيرة. وتُستخدم مذكرتا Lu Heng رقم 64 و65، المنشورتان بعد ذلك بسنوات طويلة، هنا كعدستين تحليليتين للتوافق والتبني المحلي؛ لم يكتبهما مؤلفو RFC ولم تؤيداها أو تؤثرا في تصميم عام 2004. سجل RFC 3678 Note 64 Note 65

المصادر