یادداشت بازی‌ساز: چالش هم‌زمان کردن کاربران در QuizShow

برای من به عنوان یک برنامه‌نویس، مسئله‌ی هماهنگ کردن یک سری دستگاه با هم از نظر زمانی یک چالش بوده.

 به عنوان مثال، ما در شرکت Quiz of Kings یک اپلیکیشن دیگر به اسم Quiz Show داشتیم که در آن مجری به صورت زنده برای کاربران صحبت می‌کرد و سپس تعدادی سوال روی گوشی آن‌ها نمایش داده می‌شد. ابتدا سوال اول می‌رسید و کاربران جواب می‌دادند و بعد از مدتی مجری جواب درست را می‌خواند و جواب روی گوشی کاربران نمایش داده می‌شد. بعد به سراغ سوالات بعدی می‌رفتیم تا به سوال آخر برسیم. کسانی که به همه‌ی سوالات جواب درست می‌دادند، برنده می‌شدند.

اولین چیزی که باید در نظر می‌گرفتیم، Latency ارسال ویدیو بود. به عنوان مثال وقتی مجری شروع به خواندن سوال می‌کرد، سوال مثلا ۱۰ ثانیه بعد در گوشی‌ها دیده ‌می‌شد، پس ما باید ۱۰ ثانیه بعد از حرف زدن مجری Event نمایش سوال را به کلاینت می‌فرستادیم که این Latency در آغاز هر قسمت از برنامه محاسبه و لحاظ می‌شد (زیرا مقدار آن در یک Stream با یک Stream دیگر فرق داشت). که به این ترتیب مشکل مربوط به ناهمگامی Latency را حل کردیم.

چالش اصلی این بود که سوالات باید دقیقا در یک زمان (یا در فاصله‌ی زمانی بسیار کوتاه) روی گوشی کاربران ظاهر می‌شدند تا تقلبی صورت نگیرد؛ و گرنه شما با دو گوشی که با هم اندکی اختلاف زمانی داشتند می‌توانستید سوال را زودتر ببینید و زمان کافی برای سرچ کردن داشته باشید (دقت در حد ۱ ثانیه لازم بود).

این اختلاف زمانی به این دلیل پیش می‌آمد که زمان گوشی‌های کاربران با هم فرق داشت. ما این مسئله را اول به این صورت حل کردیم که زمان سرور را به کلاینت می فرستادیم و کلاینت هم ساعت خودش را با سرور همگام می‌کرد.

اما مشکل بزرگ دیگری هم وجود داشت! ممکن بود در این حین برای بعضی از گوشی‌های کاربران مشکلی پیش بیاید. برای مثال برنامه‌ی سنگینی روی آن‌ها اجرا شود، هنگ کنند و … که باعث می‌شد مجددا آن‌ها از حالت ‌Sync زمانی خارج شوند.

ما نرخ این مشکل را از لاگ‌ها می‌فهمیدیم؛ زیرا هر تناقض زمانی در پاسخگویی به سوالات را در سیستم لاگ می‌کردیم و می‌دیدیم برای هر سوال، عده‌ی قابل توجهی از کاربران (نه خیلی زیاد و نه خیلی کم) خیلی دیر پاسخ می‌دهند. مثلا ۳۰ ثانیه دیرتر از زمان پاسخگویی به سوال، درخواست Submit آن‌ها را می‌دیدم که البته جواب را قبول نمی‌کردیم، زیرا زمان پاسخگویی تمام شده بود. با این حال می‌دانستیم احتمالا مشکلی برای گوشی‌ها پیش آمده و از حالت Sync خارج شده‌اند.

به دلیل این مجموعه عوامل مجبور بودیم که در هر بار Response پاسخگویی به سوالات، مجددا زمان سرور را به کلاینت ارسال کنیم تا اگر در فاصله‌ی زمانی پاسخ به یک سوال ناهمگامی زمانی بیش‌تر از ۱ ثانیه بوجود آمده باشد، باز هم کلاینت و سرور Sync شود. با این حال باز هم اگر فاصله‌ی گرفتن یک زمان سرور در یک API Call یا Event دریافتی، تا ارسال سوال بعدی (Event بعدی) به تاخیر چند دقیقه‌ای منجر می‌شد، مجددا ‌‌Sync یک سری از کاربران برهم‌ می‌خورد. اتفاقی که امکان وقوع آن بسیار نادر بود. در نظر داشتیم که اگر مشکل حاد شد، هر چند ثانیه یک‌بار یک سیگنال زمانی به کلاینت از طریق Socket ارسال کنیم و زمان سرور را اطلاع بدیم که خودش را با آن Sync کند.

این ها صرفا یک سری راه‌حل Manual بودند که ما برای هم‌زمان کردن استفاده می‌کردیم. اگر مسئله‌ای پیش‌رو دارید که در آن هم‌زمان بودن کاربران اهمیت دارد، می‌توانید از پروتکل NTP برای این منظور استفاده کنید.

البته باید توجه کنید که راه‌حل‌های ساده‌تر مشکل شما را حل می‌کنند یا خیر و اگر جوابگو نبودند به سراغ راه‌حل اصلی یعنی همان‌ NTP بروید.