بازی ابری منبع باز در WebRTC: p2p، چند نفره، تاخیر صفر

نرم افزار به عنوان یک سرویس، زیرساخت به عنوان یک سرویس، پلت فرم به عنوان یک سرویس، پلت فرم ارتباطی به عنوان یک سرویس، ویدئو کنفرانس به عنوان یک سرویس، در مورد بازی ابری به عنوان یک سرویس چطور؟ قبلاً چندین تلاش برای ایجاد بازی های ابری (Cloud Gaming) مانند Stadia که اخیراً توسط گوگل راه اندازی شده است، صورت گرفته است. استادیا برای WebRTC جدید نیست، اما آیا دیگران می توانند از WebRTC به همین روش استفاده کنند؟

Thanh Nguyen تصمیم گرفت این فرصت را در پروژه منبع باز خود CloudRetro آزمایش کند. CloudRetro بر اساس Pion است، محبوب کتابخانه WebRTC مبتنی بر Go (با تشکر نشان داده شده از تیم توسعه Pion برای کمک آنها در تهیه این مقاله). در این مقاله، Thanh یک نمای کلی از معماری پروژه خود ارائه می دهد و همچنین در مورد چیزهای مفیدی که یاد گرفته است و با چه چالش هایی در طول کار خود مواجه شده است صحبت می کند.

ورود

سال گذشته، وقتی گوگل Stadia را معرفی کرد، ذهن من را به هم ریخت. این ایده به قدری منحصر به فرد و مبتکرانه است که من دائماً فکر می کردم که چگونه این امر حتی با فناوری موجود امکان پذیر است. میل به درک بهتر این موضوع مرا بر آن داشت تا نسخه خود را از یک بازی ابری منبع باز ایجاد کنم. نتیجه به سادگی فوق العاده بود. در زیر می خواهم روند کار در سال خود را به اشتراک بگذارم پروژه.

TLDR: نسخه اسلاید کوتاه با نکات برجسته

چرا بازی ابری آینده است؟

من معتقدم که Cloud Gaming به زودی به نسل بعدی نه تنها بازی، بلکه سایر حوزه های علوم رایانه تبدیل خواهد شد. بازی ابری اوج مدل مشتری/سرور است. این مدل با میزبانی منطق بازی بر روی سرور راه دور و پخش تصاویر/صوتی برای مشتری، مدیریت باطن را به حداکثر می‌رساند و کار ظاهری را به حداقل می‌رساند. سرور پردازش های سنگینی را انجام می دهد تا مشتری دیگر تحت محدودیت های سخت افزاری قرار نگیرد.

Google Stadia اساسا به شما امکان می دهد بازی کنید بازی های AAA (یعنی بازی های پرفروش رده بالا) در رابطی مانند YouTube. همین روش را می توان برای سایر برنامه های سنگین آفلاین مانند سیستم عامل یا طراحی گرافیکی 2D/3D و غیره نیز به کار برد. به طوری که می توانیم آنها را به طور مداوم بر روی دستگاه های با مشخصات پایین در چندین پلت فرم اجرا کنیم.

آینده این فناوری: تصور کنید که ویندوز 10 مایکروسافت روی مرورگر کروم اجرا شود؟

بازی های ابری از نظر فنی چالش برانگیز هستند

بازی یکی از آن حوزه‌های نادری است که نیاز به پاسخگویی سریع و ثابت کاربر دارد. اگر گهگاه با 2 ثانیه تأخیر در هنگام کلیک بر روی یک صفحه مواجه شویم، این قابل قبول است. پخش‌های ویدیویی زنده معمولاً چند ثانیه تأخیر دارند، اما همچنان قابلیت استفاده معقولی را ارائه می‌دهند. با این حال، اگر بازی اغلب 500 میلی‌ثانیه عقب می‌افتد، به سادگی قابل پخش نیست. هدف ما دستیابی به تأخیر بسیار کم است تا شکاف بین ورودی و رسانه تا حد امکان کمتر باشد. بنابراین، رویکرد سنتی برای پخش ویدئو در اینجا قابل اجرا نیست.

قالب بازی General Cloud

پروژه متن باز CloudRetro

تصمیم گرفتم یک نمونه آزمایشی از یک بازی ابری ایجاد کنم تا ببینم آیا همه اینها با چنین محدودیت های شبکه سختی امکان پذیر است یا خیر. من Golang را برای اثبات مفهوم انتخاب کردم، زیرا این زبانی بود که بیشتر با آن آشنا بودم و به دلایل دیگر، همانطور که بعداً کشف کردم، برای این پیاده سازی مناسب بود. Go ساده است و بسیار سریع توسعه می یابد. کانال‌های in Go برای مدیریت چند رشته‌ای عالی هستند.

پروژه CloudRetro.io یک سرویس بازی ابری منبع باز برای بازی های یکپارچهسازی با سیستمعامل است. هدف این پروژه آوردن راحت ترین تجربه بازی به بازی های سنتی قدیمی و اضافه کردن چند نفره است.
در اینجا می توانید در مورد پروژه بیشتر بدانید: https://github.com/giongto35/cloud-game.

عملکرد CloudRetro

CloudRetro از بازی های یکپارچهسازی با سیستمعامل برای نشان دادن قدرت بازی های ابری استفاده می کند. که به شما اجازه می دهد تا تجربیات منحصر به فرد بازی را بدست آورید.

• قابل حمل بودن بازی
  • پخش فوری هنگام باز کردن یک صفحه؛ بدون نیاز به دانلود یا نصب
  • در مرورگر تلفن همراه کار می کند، بنابراین برای اجرای آن نیازی به نرم افزار نیست

• جلسات بازی را می توان در چندین دستگاه به اشتراک گذاشت و برای دفعه بعدی که وارد سیستم می شوید در ابر ذخیره می شود
• بازی را می‌توان پخش کرد یا می‌توان آن را توسط چندین کاربر به طور همزمان بازی کرد:
  • Crowdplay مانند TwitchPlayPokemon، فقط چند پلتفرمی بیشتر و بیشتر زمان واقعی
  • بازی های آنلاین آفلاین. بسیاری از کاربران می توانند بدون راه اندازی شبکه بازی کنند. بازی Samurai Shodown اکنون توسط 2 بازیکن از طریق شبکه CloudRetro قابل بازی است

  
  نسخه آزمایشی بازی چند نفره آنلاین در دستگاه های مختلف

  شالوده

  الزامات و پشته فن آوری

  در زیر لیستی از الزاماتی است که من قبل از شروع پروژه تعیین کردم.

  1. یک بازیکن
  این الزام ممکن است در اینجا خیلی مهم یا بدیهی به نظر نرسد، اما یکی از نکات کلیدی من است، به بازی های ابری اجازه می دهد تا حد امکان از خدمات پخش سنتی دور بمانند. اگر روی یک بازی تک نفره تمرکز کنیم، می‌توانیم از شر یک سرور متمرکز یا CDN خلاص شویم، زیرا مجبور نیستیم برای توده‌ها استریم کنیم. به جای آپلود جریان ها در یک سرور سینک یا ارسال بسته ها به یک سرور WebSocket متمرکز، جریان های سرویس مستقیماً از طریق یک اتصال WebRTC همتا به همتا به کاربر تحویل داده می شوند.

  2. جریان رسانه با تاخیر کم
  با خواندن در مورد Stadia، اغلب می بینم که WebRTC در برخی مقالات ذکر شده است. من متوجه شدم که WebRTC یک فناوری برجسته است و برای استفاده در بازی های ابری عالی است. WebRTC پروژه ای است که مرورگرهای وب و برنامه های تلفن همراه را از طریق یک API ساده ارتباط بلادرنگ را فراهم می کند. این اتصال همتا به همتا را فراهم می کند، برای رسانه بهینه شده است و دارای کدک های استاندارد داخلی مانند VP8 و H264 است.

  من اطمینان از بهترین تجربه کاربری ممکن را بر حفظ گرافیک با کیفیت در اولویت قرار دادم. برخی از تلفات در الگوریتم قابل قبول است. Google Stadia یک مرحله اضافی برای کاهش اندازه تصویر در سرور دارد و فریم‌ها قبل از انتقال به همتایان به کیفیت بالاتر ارتقا می‌یابند.

  3. زیرساخت های توزیع شده با مسیریابی جغرافیایی
  مهم نیست که الگوریتم فشرده سازی و کد چقدر بهینه شده است، شبکه همچنان عامل تعیین کننده ای است که بیشترین سهم را در تأخیر دارد. معماری باید مکانیزمی برای جفت کردن سرور نزدیک به کاربر برای کاهش زمان رفت و برگشت (RTT) داشته باشد. معماری باید دارای 1 هماهنگ کننده و چندین سرور جریان توزیع شده در سراسر جهان باشد: غرب ایالات متحده، شرق ایالات متحده، اروپا، سنگاپور، چین. همه سرورهای جریان باید کاملاً ایزوله باشند. سیستم می تواند توزیع خود را زمانی که سرور به شبکه می پیوندد یا از آن خارج می شود، تنظیم کند. بنابراین، با ترافیک زیاد، افزودن سرورهای اضافی امکان مقیاس بندی افقی را فراهم می کند.

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

  5. جداسازی رابط و سرویس بازی را پاک کنید
  من سرویس بازی ابری را به عنوان یک پلتفرم می بینم. همه باید بتوانند هر چیزی را به پلتفرم متصل کنند. الان ادغام کردم LibRetro با سرویس بازی ابری زیرا LibRetro یک رابط شبیه ساز بازی زیبا برای بازی های یکپارچهسازی با سیستمعامل مانند SNES، GBA، PS ارائه می دهد.

  6. اتاق های چند نفره، بازی جمعی و ارتباط خارجی (دیپ لینک) با بازی
  CloudRetro از بسیاری از گیم پلی های جدید مانند CrowdPlay و Online MultiPlayer برای بازی های یکپارچهسازی با سیستمعامل پشتیبانی می کند. اگر چندین کاربر پیوند عمیق یکسانی را در رایانه های مختلف باز کنند، بازی در حال اجرا مشابهی را مشاهده می کنند و حتی می توانند به آن بپیوندند.

  علاوه بر این، حالت های بازی در فضای ذخیره سازی ابری ذخیره می شوند. این به کاربران این امکان را می دهد که در هر زمان در هر دستگاه دیگری به بازی ادامه دهند.

  7. پوسته پوسته شدن افقی
  مانند هر SAAS امروزه، بازی های ابری باید به گونه ای طراحی شوند که به صورت افقی مقیاس پذیر باشند. طراحی هماهنگ کننده-کارگر به شما اجازه می دهد تا کارگران بیشتری را برای سرویس دهی به ترافیک بیشتر اضافه کنید.

  8. عدم اتصال به یک ابر
  زیرساخت CloudRetro بر روی ارائه دهندگان ابری مختلف (Digital Ocean، Alibaba، ارائه دهنده سفارشی) برای مناطق مختلف میزبانی می شود. من اجرای در یک ظرف Docker را برای زیرساخت فعال می کنم و تنظیمات شبکه را با استفاده از یک اسکریپت bash پیکربندی می کنم تا از قفل شدن در یک ارائه دهنده ابر واحد جلوگیری کنم. با ترکیب آن با NAT Traversal در WebRTC، می‌توانیم انعطاف‌پذیری برای استقرار CloudRetro بر روی هر پلتفرم ابری و حتی بر روی ماشین‌های هر کاربری داشته باشیم.

  طراحی معماری

  کارگر: (یا سرور استریم که در بالا ذکر شد) بازی ها را چند برابر می کند، خط لوله رمزگذاری را اجرا می کند و رسانه کدگذاری شده را برای کاربران پخش می کند. نمونه های کارگر در سراسر جهان توزیع شده اند و هر کارگر می تواند چندین جلسه کاربر را به طور همزمان مدیریت کند.

  هماهنگ کننده: مسئول جفت کردن کاربر جدید با مناسب ترین کارگر برای پخش است. هماهنگ کننده از طریق WebSocket با کارگران در تعامل است.

  ذخیره سازی وضعیت بازی: ذخیره سازی از راه دور مرکزی برای همه ایالت های بازی. این ذخیره سازی عملکردهای مهمی مانند ذخیره/بارگیری از راه دور را ارائه می دهد.

  
  معماری سطح بالا CloudRetro

  اسکریپت سفارشی

  هنگامی که یک کاربر جدید CloudRetro را در مراحل 1 و 2 که در شکل زیر نشان داده شده است باز می کند، هماهنگ کننده به همراه لیست کارگران موجود به صفحه اول درخواست می شود. پس از این، در مرحله 3 مشتری با استفاده از یک درخواست پینگ HTTP، تاخیرها را برای همه نامزدها محاسبه می کند. این لیست تاخیرها سپس به هماهنگ کننده بازگردانده می شود تا او بتواند مناسب ترین کارگر را برای خدمت به کاربر تعیین کند. مرحله 4 زیر بازی را ایجاد می کند. یک اتصال جریان WebRTC بین کاربر و کارگر اختصاص داده شده برقرار می شود.
  
  اسکریپت کاربر پس از دسترسی

  آنچه در درون کارگر است

  خطوط لوله بازی و استریم در داخل کارگر به صورت مجزا ذخیره می شوند و در آنجا از طریق رابط تبادل اطلاعات می کنند. در حال حاضر این ارتباط با انتقال داده ها در حافظه از طریق انجام می شود کانال های گلانگ در همین روند. هدف بعدی تفکیک است، یعنی. راه اندازی مستقل بازی در فرآیند دیگری.

  
  تعامل اجزای کارگر

  اجزای اصلی:

  • WebRTC: یک مؤلفه مشتری که ورودی کاربر را می پذیرد و رسانه کدگذاری شده را از سرور خروجی می دهد.
  • شبیه ساز بازی: جزء بازی به لطف کتابخانه Libretro، این سیستم قادر است بازی را در همان فرآیند اجرا کند و به صورت داخلی رسانه ها و جریان ورودی را رهگیری کند.
  • فریم های درون بازی گرفته می شوند و به رمزگذار ارسال می شوند.
  • رمزگذار تصویر/صوت: یک خط لوله رمزگذاری که فریم های رسانه را می گیرد، آنها را در پس زمینه رمزگذاری می کند و تصاویر/صوتی کدگذاری شده را خروجی می دهد.

  اجرا

  CloudRetro به عنوان فناوری ستون فقرات خود به WebRTC متکی است، بنابراین قبل از فرو رفتن در جزئیات اجرای Golang، تصمیم گرفتم در مورد خود WebRTC صحبت کنم. این فناوری شگفت‌انگیزی است که به من کمک زیادی در دستیابی به تأخیر فرعی برای پخش داده‌ها کرده است.

  WebRTC

  WebRTC برای ارائه اتصالات همتا به همتا با کیفیت بالا در برنامه های موبایل و مرورگرهای بومی با استفاده از API های ساده طراحی شده است.

  پیمایش NAT

  WebRTC به دلیل عملکرد NAT Traversal معروف است. WebRTC برای ارتباط همتا به همتا طراحی شده است. هدف آن یافتن مناسب ترین مسیر مستقیم، اجتناب از دروازه ها و فایروال های NAT برای ارتباط همتا به همتا از طریق فرآیندی به نام ICE. به عنوان بخشی از این فرآیند، APIهای WebRTC آدرس IP عمومی شما را با استفاده از سرورهای STUN پیدا کرده و آن را به سرور رله ارسال می کنند (دور زدن) زمانی که اتصال مستقیم نمی تواند برقرار شود.

  با این حال، CloudRetro به طور کامل از این ویژگی سوء استفاده نمی کند. ارتباطات همتا به نظیر آن بین کاربران وجود ندارد، بلکه بین کاربران و سرورهای ابری وجود دارد. سمت سرور مدل محدودیت های ارتباط مستقیم کمتری نسبت به یک دستگاه کاربر معمولی دارد. این به شما این امکان را می دهد که پورت های ورودی را از قبل باز کنید یا از آدرس های IP عمومی به طور مستقیم استفاده کنید، زیرا سرور پشت NAT نیست.

  قبلاً می خواستم این پروژه را به یک پلتفرم توزیع بازی برای Cloud Gaming تبدیل کنم. ایده این بود که به سازندگان بازی اجازه داده شود بازی ها و منابع پخش را ارائه دهند. و کاربران به طور مستقیم با ارائه دهندگان تعامل خواهند داشت. در این روش غیرمتمرکز، CloudRetro فقط یک چارچوب برای اتصال منابع جریان شخص ثالث به کاربران است و زمانی که دیگر میزبانی نمی شود، مقیاس پذیرتر می شود. نقش WebRTC NAT Traversal در اینجا برای تسهیل اولیه سازی اتصال همتا به همتا در منابع استریم شخص ثالث بسیار مهم است و اتصال سازنده را به شبکه آسان تر می کند.

  فشرده سازی ویدیو

  فشرده‌سازی ویدیو بخش ضروری خط لوله است و به جریان روان کمک زیادی می‌کند. در حالی که دانستن تمام جزئیات رمزگذاری ویدیوی VP8/H264 ضروری نیست، درک مفاهیم می‌تواند به شما در درک گزینه‌های سرعت پخش ویدئو، اشکال‌زدایی رفتار غیرمنتظره و تنظیم تأخیر کمک کند.

  فشرده‌سازی ویدیو برای یک سرویس استریم چالش برانگیز است زیرا الگوریتم باید اطمینان حاصل کند که کل زمان رمزگذاری + زمان انتقال شبکه + زمان رمزگشایی تا حد امکان کم است. علاوه بر این، فرآیند کدگذاری باید یکنواخت و مستمر باشد. برخی از معاوضه‌های رمزگذاری اعمال نمی‌شوند - برای مثال، نمی‌توانیم زمان‌های رمزگذاری طولانی را به اندازه فایل‌های کوچکتر و زمان‌های رمزگشایی ترجیح دهیم، یا از فشرده‌سازی متناقض استفاده کنیم.

  ایده پشت فشرده سازی ویدیو حذف بیت های غیر ضروری از اطلاعات و در عین حال حفظ سطح قابل قبولی از دقت برای کاربران است. این الگوریتم علاوه بر رمزگذاری فریم های تصویر ثابت، فریم فعلی را از فریم های قبلی و بعدی استنباط می کند، بنابراین فقط تفاوت آنها ارسال می شود. همانطور که از مثال با Pacman مشاهده می شود، فقط نقاط دیفرانسیل منتقل می شوند.

  
  مقایسه فریم های ویدئویی با استفاده از Pacman به عنوان مثال

  فشرده سازی صدا

  به همین ترتیب، الگوریتم فشرده سازی صدا داده هایی را که برای انسان قابل درک نیستند حذف می کند. Opus در حال حاضر بهترین کدک صوتی است. این برای انتقال یک موج صوتی بر روی یک پروتکل دیتاگرام سفارش داده شده مانند RTP (پروتکل حمل و نقل در زمان واقعی) طراحی شده است. تاخیر آن از mp3 و aac کمتر است و کیفیت بالاتری دارد. تأخیر معمولاً حدود 5 تا 66,5 میلی‌ثانیه است.

  Pion، WebRTC در Golang

  دستگیره یک پروژه متن باز است که WebRTC را به Golang می آورد. به جای بسته بندی معمول کتابخانه های C++ WebRTC بومی، Pion یک پیاده سازی بومی Golang از WebRTC با عملکرد بهتر، یکپارچه سازی Go و کنترل نسخه روی پروتکل های WebRTC است.

  این کتابخانه همچنین امکان پخش جریانی را با تعداد زیادی داخلی عالی با تأخیر زیر ثانیه فراهم می کند. پیاده سازی خاص خود را از STUN، DTLS، SCTP و غیره دارد. و چند آزمایش با QUIC و WebAssembly. این کتابخانه منبع باز خود یک منبع یادگیری واقعا خوب با مستندات عالی، پیاده سازی پروتکل شبکه و نمونه های جالب است.

  انجمن Pion، که توسط یک خالق بسیار پرشور رهبری می‌شود، بسیار پر جنب و جوش است و بحث‌های با کیفیت زیادی در مورد WebRTC در جریان است. اگر به این فناوری علاقه مند هستید، همراه باشید http://pion.ly/slack - چیزهای جدید زیادی یاد خواهید گرفت.

  نوشتن CloudRetro در Golang

  
  پیاده سازی کارگر در Go

  به کانال‌های در عمل بروید

  به لطف طراحی زیبای کانال Go، مشکلات پخش رویداد و همزمانی تا حد زیادی ساده شده است. همانطور که در نمودار، GoRoutine های مختلف دارای اجزای متعددی هستند که به صورت موازی اجرا می شوند. هر جزء حالت خود را مدیریت می کند و از طریق کانال ها ارتباط برقرار می کند. ادعای انتخابی Golang مجبور می کند هر بار در بازی یک رویداد اتمی پردازش شود (تیک بازی). این بدان معنی است که برای این طراحی نیازی به قفل نیست. به عنوان مثال، هنگامی که کاربر ذخیره می کند، یک عکس فوری کامل از وضعیت بازی مورد نیاز است. این حالت باید پیوسته باقی بماند و تا زمانی که ذخیره کامل شود وارد شوید. در طول هر تیک بازی، باطن تنها می‌تواند یک عملیات ذخیره یا ورودی را انجام دهد و این موضوع باعث می‌شود که موضوع فرآیند ایمن باشد.

  func (e *gameEmulator) gameUpdate() {
  for {
  	select {
  		case <-e.saveOperation:
  			e.saveGameState()
  		case key := <-e.input:
  			e.updateGameState(key)
  		case <-e.done:
  			e.close()
  			return
  	}
      }
  }

  Fan-in/Fan-out

  این الگوی Golang کاملاً با موارد استفاده CrowdPlay و Multiple Player من مطابقت دارد. با پیروی از این الگو، تمام ورودی های کاربر در یک اتاق در کانال ورودی مرکزی تعبیه شده است. رسانه بازی سپس برای همه کاربران در یک اتاق مستقر می شود. به این ترتیب به تقسیم حالت بازی بین چندین جلسه بازی کاربران مختلف دست می‌یابیم.

  
  همگام سازی بین جلسات مختلف

  معایب گلانگ

  گولنگ کامل نیست. کانال کند است در مقایسه با مسدود کردن، کانال Go به سادگی یک راه ساده تر برای مدیریت رویدادهای همزمان و رشته ای است، اما کانال بهترین عملکرد را ارائه نمی دهد. منطق مسدود کننده پیچیده ای در زیر کانال وجود دارد. بنابراین من برخی از تنظیمات را در پیاده سازی انجام دادم، قفل ها و مقادیر اتمی را در هنگام جایگزینی کانال ها برای بهینه سازی عملکرد دوباره اعمال کردم.

  علاوه بر این، زباله جمع کن در گلنگ مدیریت نشده است که گاهی اوقات باعث مکث های مشکوک طولانی می شود. این به شدت با برنامه پخش زمان واقعی تداخل دارد.

  COG

  این پروژه از کتابخانه منبع باز Golang VP8/H264 برای فشرده سازی رسانه و Libretro برای شبیه سازهای بازی استفاده می کند. همه این کتابخانه‌ها به سادگی بسته‌بندی‌های کتابخانه C در Go هستند COG. برخی از معایب ذکر شده در این پست توسط دیو چنی. مشکلاتی که باهاش ​​مواجه شدم:

  • ناتوانی در سقوط در CGO، حتی با Golang RecoveryCrash.
  • عدم شناسایی گلوگاه های عملکرد زمانی که ما قادر به تشخیص مشکلات دقیق در CGO نیستیم.

  نتیجه

  من به هدف خود یعنی درک خدمات بازی های ابری و ایجاد پلتفرمی رسیدم که به من کمک می کند بازی های یکپارچهسازی با سیستمعامل نوستالژیک را به صورت آنلاین با دوستانم انجام دهم. این پروژه بدون کتابخانه پایون و حمایت جامعه پایون امکان پذیر نبود. من از توسعه فشرده آن بسیار سپاسگزارم. API های ساده ارائه شده توسط WebRTC و Pion یکپارچگی یکپارچه را تضمین می کنند. اولین اثبات مفهومی من در همان هفته منتشر شد، حتی با وجود اینکه هیچ دانش قبلی از ارتباط همتا به همتا (P2P) نداشتم.

  علیرغم سهولت ادغام، جریان P2P در واقع یک حوزه بسیار پیچیده در علوم کامپیوتر است. او باید با پیچیدگی معماری های شبکه قدیمی مانند IP و NAT برای ایجاد یک جلسه همتا به همتا مقابله کند. در حین کار بر روی این پروژه، دانش ارزشمند زیادی در مورد شبکه و بهینه سازی عملکرد به دست آوردم، بنابراین همه را تشویق می کنم که سعی کنند محصولات P2P را با استفاده از WebRTC بسازند.

  CloudRetro به تمام موارد استفاده ای که از دیدگاه من به عنوان یک گیمر یکپارچهسازی با سیستمعامل انتظار داشتم پاسخ می دهد. با این حال، فکر می‌کنم بخش‌های زیادی در پروژه وجود دارد که می‌توانم آن‌ها را بهبود بخشم، مانند قابل اطمینان‌تر کردن و کارآمدتر کردن شبکه، ارائه گرافیک بازی با کیفیت بالاتر یا امکان اشتراک‌گذاری بازی‌ها بین کاربران. من سخت روی این موضوع کار می کنم. لطفا دنبال کنید پروژه و اگر دوست داشتید حمایت کنید

منبع: www.habr.com