الحد الأقصى للاتصالات: ما الذي يحدث حين تنفد فتحات البوابة

"max_connections": "2",
"active_cons": "1"

"max_connections": 2,
"active_cons": 1

إصداران من اللوحات، ونقطة نهاية واحدة، والحقلان نفسهما، ولا اتفاق على ما إذا كانت القيم سلاسل أم أرقامًا. الكتلة الثانية منقولة من عيّنة اختبار بقيمها كلها. أما الأولى فمركَّبة: الحمولة ذات شكل السلاسل التي نحتفظ بها تحمل max_connections قيمتها "1" ولا تحمل active_cons أصلًا، فهذا الزوج بعينه لا يظهر في أي ملف لدينا. والتباين حقيقي في الحالتين. وكائن نقل البيانات عندنا يعرّف نوع كلا الحقلين كسلسلة قابلة للعدم خلف محوِّل يقرأ سلسلة JSON أو رقم JSON أو قيمة منطقية، لأن حقلًا صارمًا واحدًا يُفشل المصافحة كلها، والمصدر الذي تفشل مصافحته لا قنوات له على الإطلاق.

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

فتحة الاتصال تعيش على المصدر، لا في المشغّل#

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

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

داخل تطبيق Windows الخاص بنا، ستة أشياء تفتح بثًا وتنفق من ذلك السقف:

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

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

الرقم يصل سلسلةً، أو رقمًا، أو لا يصل أصلًا#

ثلاثة أشكال لـ max_connections لها عيّنات اختبار. "max_connections": "2" هو التهجئة التي تكتبها مراجع واجهة برمجة اللوحة. و"max_connections": 2 رقم مجرد، وحتى ذلك الإصدار ليس متسقًا: في الحمولة ذات الشكل الرقمي التي نحتفظ بها، طابعا الانتهاء والإنشاء عددان صحيحان مجردان بينما timestamp_now ما زال مقتبسًا. و"user_info": []، مصفوفة في موضع الكائن، تُعدم كتلة المستخدم كلها وتسقط معها حقلَي الاتصال بينما يستمر بقية الاستيراد.

شكل رابع يمكن الوصول إليه وغير مثبَّت. المحوِّل نفسه يحوّل false المجردة إلى غائب، لا إلى صفر، وهذا مسجَّل عندنا لحقل URL فقط، حيث تكون "0" أسوأ من لا شيء. وmax_connections تحمل ذلك المحوِّل، فالقيمة المنطقية هناك تختفي بالطريقة نفسها. لا عيّنة اختبار تثبت ذلك، وأفضّل الإشارة إلى هذا على أن أدع ثلاثة أشكال مقيسة تمرّ على أنها أربعة.

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

عند الجهاز تنطويان في حالة واحدة. أي قيمة لا تزيد على الصفر تُطبَّع إلى 1، ومعرّف المصدر الذي لم تسمع به ذاكرة السقف المخبّأة يُقرأ 1 أيضًا. والأنواع غير البوابات تأخذ ذلك الافتراضي دائمًا، لأن الحقل لا يوجد إلا في مصافحة البوابة. وعبر المُدخَلات الـ 2,203 في قائمتَي التشغيل الحقيقيتين اللتين نقيسهما، سطح سمات EXTINF ثمانية مفاتيح، ليس بينها عدد اتصالات، ولا يعرّف RFC 8216 ولا المرجع الذي يستعير منه كل مشغّل واحدًا.

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

التبديل تحرير يتبعه اكتساب، بهذا الترتيب#

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

الإيقاف هو الجزء الوحيد من تغيير القناة الذي يمكن أن يستغرق ثوانيَ.

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

والتفكيك عند مغادرة صفحة أو إغلاق التطبيق أكثر تراخيًا. إحالة المشغّل إلى التقاعد إطلاقٌ ونسيان: إيقاف، مسح، تخلّص، كل ذلك على خيط من المجمّع، ولا شيء ينتظر النتيجة. مساران يحدّان الانتظار. الخروج من التطبيق يسمح بـ 1 ثانية؛ والمشغّل الذي فشل في منتصف بنائه يحصل على 2. وإذا لم يستطع المسار المحدود أخذ القفل في نافذته فإنه يسلّم التفكيك إلى المسار غير المحدود ويعود على أي حال، لأن تحرير مشغّل من تحت خيط ما زال داخل المكتبة الأصلية يُسقط العملية كلها. وكلا الرقمين ثابت مصرَّف وسيتغير إذا قاسه أحد. إغلاق التطبيق طلبُ تحرير، لا إثباتٌ على أن التحرير قد تم.

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

الحساب الذي يجب أن يجتازه التبديل المتداخل#

معظم التبديلات تحتاج فتحة واحدة في كل مرة. وحالة واحدة تحتاج حقًا اثنتين: يفشل بث، كثيرًا دون أن يبلّغ المحرك عن شيء غير Playing، فيرفع المشغّل بديلًا على مفكّك ترميز ثانٍ حتى لا تسوَدّ الصورة أبدًا. أثناء ذلك التداخل يكون البثّان مفتوحَين. والقاعدة التي تحكمه، منسوخة من المخطِّط الذي يملك القرار:

required  = 1 (standby)
          + 1 when the candidate streams from the same source as the outgoing stream
          + active recordings on the incoming source
available = max_connections of the incoming source

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

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

النافذة محدودة من جانبنا. الضبط الحالي يمنح الاحتياطي 6,000 مللي ثانية ليصل إلى إطاره الأول و250 مللي ثانية ليستقر قبل أن يثبَّت التبديل، فنحتفظ بمفكّك الترميز الثاني مفتوحًا 6,250 مللي ثانية على الأكثر ونتخلى عن احتياطي يفوّت الموعد. أما متى يتوقف المصدر عن حساب ذلك الاتصال فسؤال منفصل، ولا نستطيع الإجابة عنه. تلك أرقام ضبط وستتغير؛ والحساب هو الجزء الذي يحمل المعنى. واختبارات ميزانية الاتصال والمخطِّط وذاكرة السقف المخبّأة والمحكِّم وتزامن التسجيل تشغّل 57 حالة وكلها تنجح حتى وقت كتابة هذه السطور.

التسجيل يأخذ الاتصال الذي كانت الصورة تستخدمه#

سعة التسجيل هي السقف ناقص واحد، فالمصدر ذو الاتصالات الثلاثة يستطيع تشغيل تسجيلَين ويترك فتحة لتشاهد شيئًا. والمصدر ذو الاتصال الواحد حالة خاصة في الشيفرة وحالة فظّة في الواقع: تبقى السعة واحدًا، وبدء التسجيل يعلّق التشغيل لذلك المصدر، ويخرج من وضع صورة داخل صورة، ويستبدل الفيديو ببطاقة عنوانها «المعاينة متوقفة أثناء التسجيل». لا شيء يُسرق ولا شيء يُصفّ خلف توقف. التسجيل يحصل على الفتحة والشاشة تقول ذلك، بنص كُتب منفصلًا لقناة حية ولفيلم ولحلقة.

وفوق ذلك يقع إعداد عام للمهام المتزامنة، افتراضيه 2، والسقف الفعلي لكل مصدر هو الأصغر بين الاثنين. عند سقف قدره ثلاثة يتعادل الحدّان. وعند أربعة فما فوق يكون افتراضي التطبيق نفسه هو القيد الملزِم.

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

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

تسع بلاطات تحتاج تسعة اتصالات فقط إذا تشاركت مصدرًا واحدًا#

كل بلاطة تبني نسخة مفكّك ترميز خاصة بها ومشغّلًا خاصًا بها، والهندسات الست المشحونة تحمل 2 و4 و3 و4 و6 و9 بلاطات بترتيب الإعلان. البلاطة المملوءة تكلّف اتصالًا واحدًا من مصدرها هي، فتسع بلاطات تحتاج تسعة اتصالات فقط عندما تسحب التسع كلها من حساب واحد؛ وعبر ثلاثة مصادر تكلّف ثلاثة لكل مصدر، والفتحة الفارغة لا تكلّف شيئًا. والبلاطات التي تُفتح معًا تتوزع على جدول مشترك قدره 180 مللي ثانية، وهذا يضع البلاطة التاسعة في تخطيط 3x3 بعد 1,440 مللي ثانية من الأولى، وذلك التباعد ثابت مصرَّف آخر.

منتقي المصدر يعدّ البلاطات المعيَّنة لكل مصدر ويستثني عمدًا الفتحة التي تحرّرها، فتغيير قناة بلاطة يحرّر اتصال تلك البلاطة قبل اختبار البديل. الصفوف تقرأ «2 من 4 اتصالات في هذا التخطيط»، أو تعلّم المصدر ممتلئًا، والتخطيط الذي لا متسع فيه في أي مكان يحصل على حالة محجوبة، لا على فشل. وقائمة المصادر تشرح الرقم نفسه بهدوء أكبر، كشارة تقرأ «اتصال واحد» حين يكون السقف 1 أو «4 اتصالات»، مع تلميح يسمّيها الحد الأقصى لاتصالات البث المتزامنة التي تسمح بها البوابة.

أسوأ علّة شحنتها هذه الميزة لم يكن لها علاقة بالاتصالات وكل علاقتها بتلك البلاطات التسع. كان مدقّق الخادم للتخطيطات المتزامنة يحمل قائمة هندسات مسموحة لم تُمدَّد يومًا إلى ما بعد أربعة أشكال، بينما كان العميلان يكتبان 2x3 و3x3 بالفعل، فحفظ تخطيط من ست أو تسع بلاطات أنتج حمولة رفضها الخادم. لم يكن العَرَض حفظ تخطيط فاشلًا، وهو ما كان سيُكتشف. المزامنة تشحن التغييرات في دفعات تصل إلى 500 والسجل الواحد المرفوض يُفشل الدفعة كلها، فاختفت أيضًا مفضلة لا علاقة لها بُدّلت في النافذة نفسها، ولم يكن لدى من فقدها أي سبب يربطها بتخطيط بُني قبل دقائق. والتعليق فوق القائمة المسموحة المصحَّحة يقول القاعدة الآن بصوت عالٍ: إضافة هندسة إلى العميل تعني إضافتها هنا، في التغيير نفسه.

المشغّل لا يستطيع أن يخبرك أن الحد كان هو السبب#

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

رفض واحد نعرفه، لأننا نحن حسبناه: التداخل الذي لم يجد اتصالًا احتياطيًا. وهو يسمّي سببًا يستطيع الشخص أن يتصرف بشأنه ولا يصل إلى أي سطح، وهو ما تعترف به ملاحظتنا نحن. وكل سطح هنا خاص بسطح مكتب Windows؛ فرأس Xbox لا شيفرة تسجيل فيه ولا شيئًا من هذه البطاقات.

نقرأ active_cons ولا نعرضه لأحد#

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

ذلك خطئي أنا، لا سهوٌ ورثته، وهو يضايقني كل مرة أنظر فيها إلى النوع.

هناك نسخة يمكن الدفاع عنها من القرار. القيمة كانت ستكذب. فهي تُلتقط أثناء مصافحة وتُختم بلحظة التقاطها، فأي رقم نرسمه سيكون قراءة من المزامنة الأخيرة، لا عدًّا حيًّا، وذاكرة السقف المخبّأة تتحدث من تلك اللقطة المخزَّنة نفسها لا من استدعاء جديد لبوابتك. و«3 من 4 قيد الاستخدام» قديمة أسوأ من لا رقم على الإطلاق، خصوصًا على الشاشة التي يفتحها الناس حين يكونون أصلًا يبحثون عن سبب. تلك الحجة حقيقية. لكنها ليست أيضًا الحجة التي أنتجت الحالة الراهنة، إذ حُمل الحقل طول الطريق إلى السلك ثم تُرك هناك.

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

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