WebRTC پر اوپن سورس کلاؤڈ گیمنگ: p2p، ملٹی پلیئر، صفر تاخیر

سافٹ ویئر بطور سروس، انفراسٹرکچر بطور سروس، پلیٹ فارم بطور سروس، کمیونیکیشن پلیٹ فارم بطور سروس، ویڈیو کانفرنسنگ بطور سروس، کلاؤڈ گیمنگ بطور سروس کے بارے میں کیا خیال ہے؟ کلاؤڈ گیمنگ (کلاؤڈ گیمنگ) بنانے کے لیے پہلے ہی کئی کوششیں ہو چکی ہیں، جیسا کہ اسٹڈیا، جسے گوگل نے حال ہی میں شروع کیا ہے۔ سٹیڈیا WebRTC میں نیا نہیں ہے۔، لیکن کیا دوسرے بھی اسی طرح WebRTC استعمال کر سکتے ہیں؟

Thanh Nguyen نے اس موقع کو اپنے اوپن سورس پروجیکٹ CloudRetro پر آزمانے کا فیصلہ کیا۔ CloudRetro Pion پر مبنی ہے، مقبول Go پر مبنی WebRTC لائبریری (شکریہ دکھایا گیا اس مضمون کی تیاری میں مدد کے لیے پیون ڈیولپمنٹ ٹیم سے)۔ اس مضمون میں، Thanh اپنے پروجیکٹ کے فن تعمیر کا ایک جائزہ فراہم کرتا ہے، اور اس کے بارے میں بھی بات کرتا ہے کہ اس نے کون سی مفید چیزیں سیکھیں اور اپنے کام کے دوران اسے کن چیلنجوں کا سامنا کرنا پڑا۔

داخلہ

پچھلے سال، جب گوگل نے Stadia کا اعلان کیا تو اس نے میرا دماغ اڑا دیا۔ یہ آئیڈیا اتنا انوکھا اور اختراعی ہے کہ میں مسلسل سوچتا رہتا تھا کہ موجودہ ٹیکنالوجی کے ساتھ یہ کیسے ممکن ہے۔ اس موضوع کو بہتر طور پر سمجھنے کی خواہش نے مجھے اوپن سورس کلاؤڈ گیم کا اپنا ورژن بنانے پر آمادہ کیا۔ نتیجہ صرف لاجواب تھا۔ ذیل میں میں اپنے سال پر کام کرنے کے عمل کا اشتراک کرنا چاہوں گا۔ پروجیکٹ.

TLDR: جھلکیوں کے ساتھ مختصر سلائیڈ ورژن

کلاؤڈ گیمنگ کیوں مستقبل ہے۔

مجھے یقین ہے کہ کلاؤڈ گیمنگ جلد ہی نہ صرف گیمنگ بلکہ کمپیوٹر سائنس کے دیگر شعبوں کی اگلی نسل بن جائے گی۔ کلاؤڈ گیمنگ کلائنٹ/سرور ماڈل کا عروج ہے۔ یہ ماڈل بیک اینڈ مینجمنٹ کو زیادہ سے زیادہ کرتا ہے اور ریموٹ سرور پر گیم لاجک کی میزبانی کرکے اور کلائنٹ کو امیجز/آڈیو سٹریم کرکے فرنٹ اینڈ کام کو کم کرتا ہے۔ سرور بھاری پروسیسنگ کرتا ہے لہذا کلائنٹ اب ہارڈ ویئر کی حدود کے رحم و کرم پر نہیں ہے۔

Google Stadia بنیادی طور پر آپ کو کھیلنے دیتا ہے۔ AAA گیمز (یعنی ہائی اینڈ بلاک بسٹر گیمز) یوٹیوب جیسے انٹرفیس پر۔ اسی طریقہ کار کو دیگر بھاری آف لائن ایپلی کیشنز جیسے آپریٹنگ سسٹم یا 2D/3D گرافک ڈیزائن وغیرہ پر بھی لاگو کیا جا سکتا ہے۔ تاکہ ہم ان کو ایک سے زیادہ پلیٹ فارمز پر کم مخصوص آلات پر مسلسل چلا سکیں۔

اس ٹیکنالوجی کا مستقبل: تصور کریں کہ کیا مائیکروسافٹ ونڈوز 10 کروم براؤزر پر چلتا ہے؟

کلاؤڈ گیمنگ تکنیکی طور پر چیلنجنگ ہے۔

گیمنگ ان نایاب علاقوں میں سے ایک ہے جہاں مستقل، تیز صارف ردعمل کی ضرورت ہوتی ہے۔ اگر کبھی کبھار کسی صفحہ پر کلک کرتے وقت ہمیں 2 سیکنڈ کی تاخیر کا سامنا کرنا پڑتا ہے، تو یہ قابل قبول ہے۔ لائیو ویڈیو اسٹریمز میں چند سیکنڈ کا وقفہ ہوتا ہے، لیکن پھر بھی مناسب استعمال کی پیشکش کرتے ہیں۔ تاہم، اگر گیم کثرت سے 500ms سے پیچھے رہتا ہے، تو یہ صرف ناقابل کھیل ہے۔ ہمارا مقصد انتہائی کم تاخیر کو حاصل کرنا ہے تاکہ ان پٹ اور میڈیا کے درمیان فاصلہ کم سے کم ہو۔ لہذا، ویڈیو سٹریمنگ کے لیے روایتی طریقہ یہاں لاگو نہیں ہوتا ہے۔

جنرل کلاؤڈ گیم ٹیمپلیٹ

اوپن سورس پروجیکٹ CloudRetro

میں نے کلاؤڈ گیم کا ایک ٹیسٹ نمونہ بنانے کا فیصلہ کیا تاکہ یہ دیکھا جا سکے کہ آیا یہ سب کچھ نیٹ ورک کی اس طرح کی سخت پابندیوں کے ساتھ ممکن ہے۔ میں نے تصور کے ثبوت کے لیے گولانگ کا انتخاب کیا کیونکہ یہ وہ زبان تھی جس سے میں سب سے زیادہ واقف تھا اور بہت سی دوسری وجوہات کی بناء پر اس نفاذ کے لیے موزوں تھا، جیسا کہ میں نے بعد میں دریافت کیا۔ گو آسان ہے اور بہت تیزی سے ترقی کرتا ہے۔ گو میں چینلز ملٹی تھریڈنگ کے انتظام کے لیے بہترین ہیں۔

پروجیکٹ CloudRetro.io ریٹرو گیمنگ کے لیے ایک اوپن سورس کلاؤڈ گیمنگ سروس ہے۔ پروجیکٹ کا مقصد روایتی ریٹرو گیمز میں گیمنگ کا سب سے زیادہ آرام دہ تجربہ لانا اور ملٹی پلیئر شامل کرنا ہے۔
آپ یہاں پراجیکٹ کے بارے میں مزید جان سکتے ہیں: https://github.com/giongto35/cloud-game.

CloudRetro فعالیت

CloudRetro کلاؤڈ گیمنگ کی طاقت کو ظاہر کرنے کے لیے ریٹرو گیمز کا استعمال کرتا ہے۔ جو آپ کو گیمنگ کے بہت سے منفرد تجربات حاصل کرنے کی اجازت دیتا ہے۔

• کھیل کی پورٹیبلٹی
  • صفحہ کھولتے وقت فوری پلے بیک؛ کوئی ڈاؤن لوڈ یا انسٹالیشن کی ضرورت نہیں ہے۔
  • موبائل براؤزر میں کام کرتا ہے، اس لیے اسے چلانے کے لیے کسی سافٹ ویئر کی ضرورت نہیں ہے۔

• گیم سیشنز کو متعدد ڈیوائسز پر شیئر کیا جا سکتا ہے اور اگلی بار لاگ ان کرنے کے لیے کلاؤڈ میں اسٹور کیا جا سکتا ہے۔
• گیم کو سٹریم کیا جا سکتا ہے، یا اسے ایک ساتھ کئی صارفین کھیل سکتے ہیں:
  • TwitchPlayPokemon کی طرح کراؤڈ پلے، صرف زیادہ کراس پلیٹ فارم اور زیادہ ریئل ٹائم
  • آف لائن گیمز آن لائن۔ بہت سے صارفین نیٹ ورک قائم کیے بغیر کھیل سکتے ہیں۔ Samurai Shodown اب CloudRetro نیٹ ورک پر 2 کھلاڑی کھیل سکتے ہیں۔

  
  مختلف آلات پر آن لائن ملٹی پلیئر گیم کا ڈیمو ورژن

  بنیادی ڈھانچے

  تقاضے اور ٹیکنالوجی اسٹیک

  ذیل میں ان تقاضوں کی فہرست ہے جو میں نے پروجیکٹ شروع کرنے سے پہلے طے کی ہیں۔

  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 بہت سے نئے گیم پلے کو سپورٹ کرتا ہے جیسے کراؤڈ پلے اور آن لائن ملٹی پلیئر ریٹرو گیمز کے لیے۔ اگر متعدد صارفین ایک ہی ڈیپ لنک کو مختلف کمپیوٹرز پر کھولتے ہیں، تو وہ ایک ہی گیم کو چلتے ہوئے دیکھیں گے اور یہاں تک کہ اس میں شامل ہونے کے قابل بھی ہوں گے۔

  مزید یہ کہ گیم اسٹیٹس کلاؤڈ اسٹوریج میں محفوظ ہیں۔ یہ صارفین کو کسی بھی وقت کسی بھی دوسرے ڈیوائس پر کھیل جاری رکھنے کی اجازت دیتا ہے۔

  7. افقی پیمانہ
  آج کل کسی بھی SAAS کی طرح، کلاؤڈ گیمنگ کو افقی طور پر توسیع پذیر ہونے کے لیے ڈیزائن کیا جانا چاہیے۔ کوآرڈینیٹر ورکر ڈیزائن آپ کو مزید ٹریفک فراہم کرنے کے لیے مزید کارکنوں کو شامل کرنے کی اجازت دیتا ہے۔

  8. ایک بادل سے کوئی تعلق نہیں۔
  CloudRetro کا بنیادی ڈھانچہ مختلف علاقوں کے لیے مختلف کلاؤڈ فراہم کنندگان (ڈیجیٹل اوشین، علی بابا، کسٹم فراہم کنندہ) پر ہوسٹ کیا جاتا ہے۔ میں انفراسٹرکچر کے لیے ڈوکر کنٹینر میں چلانے کو قابل بناتا ہوں اور ایک ہی کلاؤڈ فراہم کنندہ میں بند ہونے سے بچنے کے لیے بیش اسکرپٹ کا استعمال کرتے ہوئے نیٹ ورک کی ترتیبات کو ترتیب دیتا ہوں۔ اسے WebRTC میں NAT Traversal کے ساتھ ملا کر، ہم کسی بھی کلاؤڈ پلیٹ فارم اور یہاں تک کہ کسی بھی صارف کی مشینوں پر CloudRetro کو تعینات کرنے کی لچک حاصل کر سکتے ہیں۔

  تعمیراتی خاکہ

  کارکن: (یا اوپر ذکر کردہ اسٹریمنگ سرور) گیمز کو ضرب دیتا ہے، انکوڈنگ پائپ لائن چلاتا ہے، اور انکوڈ شدہ میڈیا کو صارفین تک پہنچاتا ہے۔ کارکن کی مثالیں پوری دنیا میں تقسیم کی جاتی ہیں، اور ہر کارکن بیک وقت متعدد صارف سیشنز کو سنبھال سکتا ہے۔

  کوآرڈینیٹر: نئے صارف کو سٹریمنگ کے لیے موزوں ترین کارکن کے ساتھ جوڑا بنانے کے لیے ذمہ دار ہے۔ کوآرڈینیٹر WebSocket کے ذریعے کارکنوں کے ساتھ بات چیت کرتا ہے۔

  گیم اسٹیٹ اسٹوریج: تمام گیم اسٹیٹس کے لیے سنٹرل ریموٹ اسٹوریج۔ یہ اسٹوریج اہم کام فراہم کرتا ہے جیسے کہ ریموٹ سیو/لوڈ۔

  
  CloudRetro کا اعلیٰ سطحی فن تعمیر

  حسب ضرورت اسکرپٹ

  جب کوئی نیا صارف نیچے دیے گئے اعداد و شمار میں دکھائے گئے مراحل 1 اور 2 میں CloudRetro کھولتا ہے، کوآرڈینیٹر سے دستیاب کارکنوں کی فہرست کے ساتھ پہلے صفحہ پر درخواست کی جاتی ہے۔ اس کے بعد، مرحلہ 3 میں کلائنٹ HTTP پنگ کی درخواست کا استعمال کرتے ہوئے تمام امیدواروں کے لیے تاخیر کا حساب لگاتا ہے۔ تاخیر کی یہ فہرست پھر کوآرڈینیٹر کو بھیج دی جاتی ہے تاکہ وہ صارف کی خدمت کے لیے موزوں ترین کارکن کا تعین کر سکے۔ نیچے کا مرحلہ 4 گیم بناتا ہے۔ ایک WebRTC سٹریمنگ کنکشن صارف اور تفویض کردہ کارکن کے درمیان قائم ہوتا ہے۔
  
  رسائی حاصل کرنے کے بعد صارف کا اسکرپٹ

  کارکن کے اندر کیا ہے۔

  گیم اور اسٹریمنگ پائپ لائنز ورکر کے اندر تنہائی میں محفوظ کی جاتی ہیں اور انٹرفیس کے ذریعے وہاں معلومات کا تبادلہ کیا جاتا ہے۔ فی الحال، یہ مواصلات میموری میں ڈیٹا کی منتقلی کے ذریعے کیا جاتا ہے گولانگ چینلز اسی عمل میں. اگلا مقصد علیحدگی ہے، یعنی ایک اور عمل میں گیم کا آزادانہ آغاز۔

  
  کارکنوں کے اجزاء کا تعامل

  اہم اجزاء:

  • WebRTC: ایک کلائنٹ کا جزو جو صارف کے ان پٹ کو قبول کرتا ہے اور سرور سے انکوڈ شدہ میڈیا کو آؤٹ پٹ کرتا ہے۔
  • گیم ایمولیٹر: کھیل کے اجزاء. Libretro لائبریری کی بدولت، سسٹم گیم کو اسی عمل کے اندر چلانے اور میڈیا اور ان پٹ سٹریم کو اندرونی طور پر روکنے کے قابل ہے۔
  • درون گیم فریم پکڑے جاتے ہیں اور انکوڈر کو بھیجے جاتے ہیں۔
  • تصویر/آڈیو انکوڈر: ایک انکوڈنگ پائپ لائن جو میڈیا فریم لیتی ہے، انہیں پس منظر میں انکوڈ کرتی ہے، اور انکوڈ شدہ امیجز/آڈیو کو آؤٹ پٹ کرتی ہے۔

  Реализация

  CloudRetro اپنی ریڑھ کی ہڈی کی ٹیکنالوجی کے طور پر WebRTC پر انحصار کرتا ہے، اس لیے Golang کے نفاذ کی تفصیلات میں جانے سے پہلے، میں نے خود WebRTC کے بارے میں بات کرنے کا فیصلہ کیا۔ یہ حیرت انگیز ٹیکنالوجی ہے جس نے ڈیٹا کو سٹریمنگ کے لیے سب سیکنڈ لیٹینسی حاصل کرنے میں میری بہت مدد کی ہے۔

  WebRTC

  WebRTC سادہ APIs کا استعمال کرتے ہوئے مقامی موبائل ایپس اور براؤزرز پر اعلیٰ معیار کے پیئر ٹو پیئر کنکشن فراہم کرنے کے لیے ڈیزائن کیا گیا ہے۔

  NAT ٹراورسل

  WebRTC اپنی NAT Traversal فعالیت کے لیے جانا جاتا ہے۔ WebRTC کو پیئر ٹو پیئر کمیونیکیشن کے لیے ڈیزائن کیا گیا ہے۔ اس کا مقصد سب سے موزوں راست راستہ تلاش کرنا ہے، NAT گیٹ ویز اور فائر والز سے گریز کرتے ہوئے پیر ٹو پیئر کمیونیکیشن کے لیے ICE. اس عمل کے حصے کے طور پر، WebRTC APIs STUN سرورز کا استعمال کرتے ہوئے آپ کا عوامی IP پتہ تلاش کرتے ہیں اور اسے ریلے سرور (ٹرن) جب براہ راست کنکشن قائم نہیں کیا جاسکتا۔

  تاہم، CloudRetro اس خصوصیت کا مکمل فائدہ نہیں اٹھاتا ہے۔ اس کے پیئر ٹو پیئر کنکشن صارفین کے درمیان نہیں بلکہ صارفین اور کلاؤڈ سرورز کے درمیان موجود ہیں۔ ماڈل کے سرور سائیڈ میں ایک عام صارف کے آلے کے مقابلے میں براہ راست مواصلاتی پابندیاں کم ہیں۔ یہ آپ کو آنے والی بندرگاہوں کو پہلے سے کھولنے یا عوامی IP پتوں کو براہ راست استعمال کرنے کی اجازت دیتا ہے، کیونکہ سرور NAT کے پیچھے نہیں ہے۔

  پہلے، میں کلاؤڈ گیمنگ کے لیے پروجیکٹ کو گیم ڈسٹری بیوشن پلیٹ فارم میں تبدیل کرنا چاہتا تھا۔ خیال یہ تھا کہ گیم تخلیق کاروں کو گیمز اور اسٹریمنگ کے وسائل فراہم کرنے کی اجازت دی جائے۔ اور صارفین براہ راست فراہم کنندگان کے ساتھ بات چیت کریں گے۔ اس وکندریقرت انداز میں، CloudRetro صرف تیسری پارٹی کے اسٹریمنگ وسائل کو صارفین سے مربوط کرنے کا ایک فریم ورک ہے، جب اس کی میزبانی نہیں کی جاتی ہے تو اسے مزید توسیع پذیر بناتا ہے۔ WebRTC NAT Traversal کا کردار یہاں تھرڈ پارٹی اسٹریمنگ کے وسائل پر پیئر ٹو پیئر کنکشن کی شروعات کو آسان بنانے کے لیے بہت اہم ہے، جس سے تخلیق کار کے لیے نیٹ ورک سے جڑنا آسان ہو جاتا ہے۔

  ویڈیو کمپریشن

  ویڈیو کمپریشن پائپ لائن کا ایک ناگزیر حصہ ہے اور ہموار بہاؤ میں بہت زیادہ حصہ ڈالتا ہے۔ اگرچہ VP8/H264 ویڈیو انکوڈنگ کی ہر تفصیل کو جاننا ضروری نہیں ہے، لیکن تصورات کو سمجھنے سے آپ کو ویڈیو کی رفتار کے اختیارات کو سمجھنے، غیر متوقع رویے کو ڈیبگ کرنے، اور تاخیر کو ایڈجسٹ کرنے میں مدد مل سکتی ہے۔

  اسٹریمنگ سروس کے لیے ویڈیو کو کمپریس کرنا مشکل ہے کیونکہ الگورتھم کو یہ یقینی بنانا چاہیے کہ کل انکوڈنگ ٹائم + نیٹ ورک ٹرانسمیشن ٹائم + ڈی کوڈنگ ٹائم جتنا ممکن ہو کم ہو۔ اس کے علاوہ، کوڈنگ کا عمل مستقل اور مسلسل ہونا چاہیے۔ کچھ انکوڈنگ ٹریڈ آف لاگو نہیں ہوتے ہیں- مثال کے طور پر، ہم فائل کے چھوٹے سائز اور ڈی کوڈنگ کے اوقات پر طویل انکوڈنگ کے اوقات کو پسند نہیں کر سکتے، یا غیر مطابقت پذیر کمپریشن استعمال کر سکتے ہیں۔

  ویڈیو کمپریشن کے پیچھے خیال یہ ہے کہ صارفین کے لیے قابل قبول سطح کی درستگی کو برقرار رکھتے ہوئے معلومات کے غیر ضروری بٹس کو ختم کیا جائے۔ انفرادی جامد تصویر کے فریموں کو انکوڈنگ کرنے کے علاوہ، الگورتھم پچھلے اور اگلے فریموں سے موجودہ فریم کا اندازہ لگاتا ہے، اس لیے صرف ان کا فرق بھیجا جاتا ہے۔ جیسا کہ Pacman کے ساتھ مثال سے دیکھا جا سکتا ہے، صرف تفریق پوائنٹس منتقل ہوتے ہیں۔

  
  Pacman کو بطور مثال استعمال کرتے ہوئے ویڈیو فریموں کا موازنہ

  آڈیو کمپریشن

  اسی طرح، آڈیو کمپریشن الگورتھم ایسے ڈیٹا کو چھوڑ دیتا ہے جسے انسان نہیں سمجھ سکتے۔ Opus فی الحال بہترین کارکردگی کا مظاہرہ کرنے والا آڈیو کوڈیک ہے۔ یہ آر ٹی پی (ریئل ٹائم ٹرانسپورٹ پروٹوکول) جیسے آرڈر شدہ ڈیٹاگرام پروٹوکول پر آڈیو لہر کو منتقل کرنے کے لیے ڈیزائن کیا گیا ہے۔ اس کی تاخیر mp3 اور aac سے کم ہے، اور معیار زیادہ ہے۔ تاخیر عام طور پر تقریباً 5~66,5ms ہوتی ہے۔

  گولانگ میں Pion، WebRTC

  پیون ایک اوپن سورس پروجیکٹ ہے جو WebRTC کو Golang میں لاتا ہے۔ مقامی C++ WebRTC لائبریریوں کی عام ریپنگ کے بجائے، Pion WebRTC کا ایک مقامی گولانگ نفاذ ہے جس میں WebRTC پروٹوکولز پر بہتر کارکردگی، Go انٹیگریشن اور ورژن کنٹرول ہے۔

  لائبریری ذیلی سیکنڈ لیٹنسی کے ساتھ بہت سارے زبردست بلٹ ان کے ساتھ اسٹریمنگ کو بھی قابل بناتی ہے۔ اس کا اپنا STUN، DTLS، SCTP وغیرہ کا نفاذ ہے۔ اور QUIC اور WebAssembly کے ساتھ کچھ تجربات۔ یہ اوپن سورس لائبریری بذات خود بہترین دستاویزات، نیٹ ورک پروٹوکول کے نفاذ، اور عمدہ مثالوں کے ساتھ ایک بہت اچھا سیکھنے کا وسیلہ ہے۔

  Pion کمیونٹی، جس کی قیادت ایک بہت پرجوش تخلیق کار کرتی ہے، کافی جاندار ہے، جس میں WebRTC کے بارے میں بہت ساری معیاری بات چیت چل رہی ہے۔ اگر آپ اس ٹیکنالوجی میں دلچسپی رکھتے ہیں تو شامل ہوں۔ http://pion.ly/slack - آپ بہت سی نئی چیزیں سیکھیں گے۔

  گولانگ میں CloudRetro لکھنا

  
  گو میں ایک کارکن کا نفاذ

  چینلز کو ایکشن میں دیکھیں

  Go کے خوبصورت چینل ڈیزائن کی بدولت، ایونٹ سٹریمنگ اور ہم آہنگی کے مسائل بہت آسان ہو گئے ہیں۔ جیسا کہ خاکہ میں ہے، مختلف GoRoutines میں متعدد اجزاء متوازی چلتے ہیں۔ ہر جزو اپنی حالت کا انتظام کرتا ہے اور چینلز کے ذریعے بات چیت کرتا ہے۔ گولانگ کا انتخابی دعویٰ گیم میں ہر بار ایک ایٹم ایونٹ پر کارروائی کرنے پر مجبور کرتا ہے (گیم ٹک)۔ اس کا مطلب ہے کہ اس ڈیزائن کے لیے کسی لاکنگ کی ضرورت نہیں ہے۔ مثال کے طور پر، جب کوئی صارف محفوظ کرتا ہے، تو گیم اسٹیٹ کا مکمل سنیپ شاٹ درکار ہوتا ہے۔ یہ حالت مسلسل برقرار رہنی چاہیے، لاگ ان ہونے تک جب تک محفوظ نہ ہو جائے۔ ہر گیم ٹک کے دوران، بیک اینڈ صرف ایک سیو یا ان پٹ آپریشن ہینڈل کر سکتا ہے، جس سے پروسیس تھریڈ محفوظ ہو جاتا ہے۔

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

  فین ان/فین آؤٹ

  یہ گولانگ ٹیمپلیٹ میرے کراؤڈ پلے اور ایک سے زیادہ پلیئر کے استعمال کے معاملے میں بالکل فٹ بیٹھتا ہے۔ اس پیٹرن پر عمل کرتے ہوئے، ایک کمرے میں تمام صارف کے ان پٹ مرکزی داخلی راستے میں بنائے جاتے ہیں۔ پھر گیم میڈیا کو ایک ہی کمرے میں تمام صارفین کے لیے تعینات کیا جاتا ہے۔ اس طرح، ہم مختلف صارفین کے کئی گیم سیشنز کے درمیان گیم اسٹیٹ کی تقسیم کو حاصل کرتے ہیں۔

  
  مختلف سیشنوں کے درمیان ہم وقت سازی

  گولانگ کے نقصانات

  گولانگ کامل نہیں ہے۔ چینل سست ہے۔ بلاک کرنے کے مقابلے میں، گو چینل ہم آہنگی اور تھریڈڈ ایونٹس کو ہینڈل کرنے کا آسان طریقہ ہے، لیکن چینل بہترین کارکردگی فراہم نہیں کرتا ہے۔ چینل کے نیچے ایک پیچیدہ بلاکنگ منطق ہے۔ لہذا میں نے عمل درآمد میں کچھ ایڈجسٹمنٹ کیں، کارکردگی کو بہتر بنانے کے لیے چینلز کو تبدیل کرتے وقت تالے اور جوہری اقدار کو دوبارہ لاگو کیا۔

  اس کے علاوہ، گولانگ میں کچرا اٹھانے والا غیر منظم ہے، جس کی وجہ سے بعض اوقات مشکوک طور پر طویل وقفے کا سامنا کرنا پڑتا ہے۔ یہ ریئل ٹائم اسٹریمنگ ایپلیکیشن میں بہت زیادہ مداخلت کرتا ہے۔

  سی جی او

  پروجیکٹ میڈیا کمپریشن کے لیے موجودہ اوپن سورس Golang VP8/H264 لائبریری اور گیم ایمولیٹرز کے لیے Libretro استعمال کرتا ہے۔ یہ تمام لائبریریاں صرف گو میں سی لائبریری کے ریپرز ہیں۔ سی جی او. کچھ نقصانات میں درج ہیں۔ ڈیو چینی کی یہ پوسٹ. مجھے درپیش مسائل:

  • CGO میں حادثے کو پکڑنے میں ناکامی، یہاں تک کہ گولانگ ریکوری کریش کے ساتھ بھی؛
  • کارکردگی کی رکاوٹوں کی نشاندہی کرنے میں ناکامی جب ہم CGO میں تفصیلی مسائل کا پتہ لگانے سے قاصر ہوتے ہیں۔

  حاصل يہ ہوا

  میں نے کلاؤڈ گیمنگ سروسز کو سمجھنے اور ایک ایسا پلیٹ فارم بنانے کا اپنا مقصد حاصل کر لیا جو آن لائن اپنے دوستوں کے ساتھ پرانی ریٹرو گیمز کھیلنے میں میری مدد کرتا ہے۔ یہ منصوبہ Pion لائبریری اور Pion کمیونٹی کے تعاون کے بغیر ممکن نہیں تھا۔ میں اس کی گہری ترقی کے لیے بے حد مشکور ہوں۔ WebRTC اور Pion کی طرف سے فراہم کردہ سادہ APIs نے ہموار انضمام کو یقینی بنایا۔ میرا تصور کا پہلا ثبوت اسی ہفتے جاری کیا گیا تھا، حالانکہ مجھے پیئر ٹو پیئر (P2P) کمیونیکیشن کے بارے میں پہلے سے کوئی علم نہیں تھا۔

  انضمام کی آسانی کے باوجود، P2P سٹریمنگ درحقیقت کمپیوٹر سائنس میں ایک بہت پیچیدہ شعبہ ہے۔ اسے پیئر ٹو پیئر سیشن بنانے کے لیے دیرینہ نیٹ ورک آرکیٹیکچرز جیسے IP اور NAT کی پیچیدگی سے نمٹنا پڑتا ہے۔ اس پروجیکٹ پر کام کرتے ہوئے، میں نے نیٹ ورکنگ اور کارکردگی کو بہتر بنانے کے بارے میں بہت قیمتی معلومات حاصل کی، اس لیے میں ہر کسی کو WebRTC کا استعمال کرتے ہوئے P2P پروڈکٹس بنانے کی کوشش کرنے کی ترغیب دیتا ہوں۔

  CloudRetro استعمال کے ان تمام معاملات کو پورا کرتا ہے جن کی مجھے ایک ریٹرو گیمر کے طور پر اپنے نقطہ نظر سے توقع تھی۔ تاہم، میرے خیال میں اس پروجیکٹ میں بہت سے شعبے ہیں جنہیں میں بہتر بنا سکتا ہوں، جیسے کہ نیٹ ورک کو زیادہ قابل اعتماد اور پرفارمنس بنانا، اعلیٰ معیار کے گیم گرافکس فراہم کرنا، یا صارفین کے درمیان گیمز کا اشتراک کرنے کی صلاحیت۔ میں اس پر سخت محنت کر رہا ہوں۔ پر عمل کریں پروجیکٹ اور اگر آپ کو یہ پسند ہے تو اس کی حمایت کریں۔

ماخذ: www.habr.com