استعادة حالة الآلة لا تعيد لحظة العزف

الخلاصة

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

وصل متأخراً، ففاته ما لا يتكرر

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

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

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

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

الموسيقى هنا أوامر، وليست تسجيلاً صوتياً

يحمل MIDI تعليمات رمزية للآلة: ابدأ نغمة، أنهها، غيّر إعداداً. ينتج المستقبل الصوت باستخدام هذه التعليمات وحالته المتراكمة. لذلك لا تشبه استعادة هذه البيانات إعادة أجزاء ناقصة من ملف صوتي مسجل.

في نوفمبر 2006، ميزت RFC 4695 بين آثار عابرة وآثار قد تستمر بلا نهاية محددة. فقدان NoteOn قد يعني أن نغمة لم تُسمع، وينتهي أثر غيابها عادة بانتهاء المدة التي كان يفترض أن تشغلها. أما فقدان NoteOff فقد يترك نغمة مستمرة. وفقدان أمر تغيير مستوى صوت القناة قد يؤثر في كل ما يأتي بعده.

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

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

ما تمنحه أرقام الحزم، وما لا تمنحه

يوفر RTP أرقام تسلسل وطوابع زمنية وأدوات لمراقبة الاستقبال. ومع ذلك، توضح RFC 3550، الصادرة في يوليو 2003، أنه لا يضمن بذاته وصول البيانات أو وصولها في موعد محدد أو بالترتيب. الأرقام تساعد على رؤية فجوة، لكنها لا تعرف أي نغمة ينبغي إسكاتها.

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

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

حافظت مواصفة 2011، التي حلت محل وثيقة 2006، على هذا الالتزام: ألا يحتوي الأداء الناتج عن التدفق عبر نقل غير موثوق على آثار غير محددة المدة. الالتزام لا يساوي وعداً بعدم حدوث أي تشوه عابر، ولا برهاناً على أن كل تنفيذ في الواقع يفي به.

للسجل بداية، وليس ذاكرة مطلقة

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

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

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

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

قد يكون التصحيح الصحيح هو عدم العزف

تعالج بنية Chapter N في السجل أنماط التناوب المعتادة بين بدء النغمة وإنهائها. لا تسجل كل ضغطة حدثت طوال الجلسة. كما أن سجل NoteOn لا يحمل التوقيت الدقيق لتنفيذ الأمر الأصلي؛ يقدم البت Y إرشاداً بشأن عزف النغمة أو تجاوزها.

لماذا يُتجاوز أمر عُثر عليه؟ لأن النغمة المتأخرة قد تفسد الإيقاع بدلاً من إصلاحه. توضح RFC 4696، وهي دليل تنفيذ معلوماتي من نوفمبر 2006، كيف يمكن للمستقبل ألا يصدر النغمة، ومع ذلك يحدث سجلاته الداخلية كما لو أن أمر البدء قد أُخذ في الحسبان. هذا يهيئه لفهم الأوامر التالية من دون إضافة صوت في غير موضعه.

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

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

وقت الصمت قد يكون وقت اكتشاف متأخر

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

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

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

ثم تأتي حدود الشبكة المشتركة. يسبق التحكم في الازدحام تلبية معدل الحراسة المطلوب. وتشرح RFC 3551 مسؤولية التعايش المعقول مع التدفقات الأخرى. الرغبة في وقف نغمة خاطئة بسرعة لا تمنح التطبيق حقاً مفتوحاً في زيادة الإرسال. وقد تتحول حركة التصحيح نفسها إلى سبب لمزيد من التأخير والفقد.

الحزمة القديمة قد تعيد الخطأ إلى الحاضر

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

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

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

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

ما وثقه التاريخ، وما لم يشهد عليه

في مايو 2017، تناولت RFC 8088 سجل RTP MIDI بوصفه مثالاً مفيداً على استعادة حالة ملخصة وتقليصها بمساعدة تقارير RTCP. ربطت فائدته بالوسائط الرمزية الشديدة الاعتماد على الحالة. لم تقدم بذلك قياساً للانتشار التجاري أو لنجاح حفلات فعلية.

وبالمثل، يوفر تسجيل audio/rtp-midi لدى IANA اسماً مشتركاً ومعلمات ومراجع لتدفقات MIDI الآنية. إنه يساعد الأجهزة على معرفة التنسيق، لكنه لا يختبر عنها الأداء أو يؤكد حصة سوقية.

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

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