Բաց կոդով ամպային խաղեր WebRTC-ում. p2p, մուլտիպլեյեր, զրոյական ուշացում

Ծրագրային ապահովումը՝ որպես ծառայություն, ենթակառուցվածքը՝ որպես ծառայություն, հարթակ՝ որպես ծառայություն, հաղորդակցման հարթակ՝ որպես ծառայություն, վիդեոկոնֆերանսը՝ որպես ծառայություն, իսկ ամպային խաղերը՝ որպես ծառայություն: Արդեն մի քանի փորձ է եղել ստեղծել ամպային խաղեր (Cloud Gaming), ինչպիսին Stadia-ն է, որը վերջերս թողարկվել է Google-ի կողմից։ Ստադիա նոր չէ WebRTC-ում, բայց մյուսները կարո՞ղ են օգտագործել WebRTC-ն նույն կերպ:

Թան Նգուենը որոշել է փորձարկել այս հնարավորությունը իր CloudRetro բաց կոդով նախագծի վրա: CloudRetro-ն հիմնված է Pion-ի վրա, հանրաճանաչ WebRTC գրադարան՝ հիմնված Go-ի վրա (շնորհակալություն Ցուցադրված է Pion-ի զարգացման թիմից՝ այս հոդվածը պատրաստելու հարցում նրանց աջակցության համար): Այս հոդվածում Թանը ներկայացնում է իր նախագծի ճարտարապետության ակնարկը, ինչպես նաև խոսում է այն մասին, թե ինչ օգտակար բաներ է սովորել և ինչ մարտահրավերների է հանդիպել իր աշխատանքի ընթացքում:

Մուտք

Անցյալ տարի, երբ Google-ը հայտարարեց Stadia-ի մասին, այն փչացրեց իմ միտքը: Գաղափարն այնքան յուրահատուկ և նորարար է, որ ես անընդհատ մտածում էի, թե ինչպես է դա հնարավոր նույնիսկ գոյություն ունեցող տեխնոլոգիայի դեպքում: Այս թեման ավելի լավ հասկանալու ցանկությունն ինձ դրդեց ստեղծել բաց կոդով ամպային խաղի իմ սեփական տարբերակը: Արդյունքն ուղղակի ֆանտաստիկ էր։ Ստորև կցանկանայի կիսվել իմ տարվա վրա աշխատելու ընթացքով նախագիծը.

TLDR՝ կարճ սլայդ տարբերակ՝ կարևորագույն կետերով

Ինչու է ամպային խաղերը ապագան

Ես հավատում եմ, որ Cloud Gaming-ը շուտով կդառնա ոչ միայն խաղերի, այլ նաև համակարգչային գիտության այլ ոլորտների հաջորդ սերունդը։ Ամպային խաղը հաճախորդի/սերվերի մոդելի գագաթնակետն է: Այս մոդելը առավելագույնի է հասցնում հետնամասի կառավարումը և նվազագույնի է հասցնում ճակատային աշխատանքը՝ հոսթինգ անելով խաղի տրամաբանությունը հեռավոր սերվերի վրա և պատկերներ/աուդիո հեռարձակելով հաճախորդին: Սերվերը կատարում է ծանր մշակում, այնպես որ հաճախորդն այլևս չի ենթարկվում ապարատային սահմանափակումների:

Google Stadia-ն հիմնականում թույլ է տալիս խաղալ AAA խաղեր (այսինքն՝ բարձրակարգ բլոկբաստեր խաղեր) այնպիսի ինտերֆեյսի վրա, ինչպիսին YouTube-ն է: Նույն մեթոդաբանությունը կարող է կիրառվել այլ ծանր օֆլայն հավելվածների համար, ինչպիսիք են օպերացիոն համակարգը կամ 2D/3D գրաֆիկական դիզայնը և այլն: այնպես, որ մենք կարողանանք դրանք հետևողականորեն գործարկել ցածր սպեկտրի սարքերի վրա բազմաթիվ հարթակներում:

Այս տեխնոլոգիայի ապագան. Պատկերացնո՞ւմ եք, եթե Microsoft Windows 10-ն աշխատեր Chrome բրաուզերում:

Ամպային խաղերը տեխնիկապես դժվար է

Խաղը այն հազվագյուտ ոլորտներից է, որտեղ պահանջվում է մշտական, արագ օգտագործողի արձագանք: Եթե ​​երբեմն մենք բախվում ենք 2 վայրկյան ուշացումով էջը սեղմելիս, դա ընդունելի է: Ուղիղ վիդեո հոսքերը հակված են մի քանի վայրկյանի հետաձգմանը, բայց դեռ առաջարկում են ողջամիտ օգտագործելիություն: Այնուամենայնիվ, եթե խաղը հաճախ հետ է մնում 500 մս-ով, այն պարզապես հնարավոր չէ խաղալ: Մեր նպատակն է հասնել չափազանց ցածր հետաձգման, որպեսզի մուտքագրման և մեդիայի միջև եղած բացը հնարավորինս փոքր լինի: Հետևաբար, վիդեո հոսքի ավանդական մոտեցումն այստեղ կիրառելի չէ:

Ընդհանուր ամպի խաղի ձևանմուշ

Բաց կոդով նախագիծ CloudRetro

Ես որոշեցի ստեղծել ամպային խաղի թեստային նմուշ՝ տեսնելու, թե արդյոք այս ամենը հնարավոր է ցանցի նման խիստ սահմանափակումների դեպքում: Ես ընտրեցի Golang-ը հայեցակարգի ապացույցի համար, քանի որ դա այն լեզուն էր, որին ես ամենից շատ ծանոթ էի և հարմար էր այս իրականացման համար շատ այլ պատճառներով, ինչպես հետագայում հայտնաբերեցի: Go-ն պարզ է և զարգանում է շատ արագ; 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 script՝ մեկ ամպային մատակարարի մեջ արգելափակվելուց խուսափելու համար: Համակցելով սա NAT Traversal-ի հետ WebRTC-ում, մենք կարող ենք ճկունություն ունենալ՝ տեղակայելու CloudRetro-ն ցանկացած ամպային հարթակի և նույնիսկ ցանկացած օգտագործողի մեքենաների վրա:

  Ճարտարապետական ​​ձևավորում

  Աշխատող. (կամ վերը նշված հոսքային սերվերը) բազմապատկում է խաղերը, գործարկում է կոդավորման խողովակաշարը և կոդավորված մեդիան հոսում է օգտվողներին: Աշխատողների օրինակները բաշխված են ամբողջ աշխարհում, և յուրաքանչյուր աշխատող կարող է միաժամանակ կառավարել բազմաթիվ օգտատերերի նիստերը:

  Համակարգող. պատասխանատու է նոր օգտատիրոջը հոսքի համար ամենահարմար աշխատողի հետ զուգակցելու համար: Համակարգողը շփվում է աշխատողների հետ WebSocket-ի միջոցով:

  Խաղի վիճակի պահեստավորում. կենտրոնական հեռավոր պահեստավորում բոլոր խաղի վիճակների համար: Այս պահեստը ապահովում է այնպիսի կարևոր գործառույթներ, ինչպիսիք են հեռակառավարումը/բեռնումը:

  
  CloudRetro-ի վերին մակարդակի ճարտարապետություն

  Հատուկ սցենար

  Երբ նոր օգտատերը բացում է CloudRetro-ն ստորև նկարում ներկայացված 1-ին և 2-րդ քայլերում, համակարգողը և հասանելի աշխատողների ցանկը ուղարկվում են առաջին էջ: Դրանից հետո 3-րդ քայլում հաճախորդը հաշվարկում է ուշացումները բոլոր թեկնածուների համար՝ օգտագործելով HTTP ping հարցումը: Հետաձգումների այս ցանկն այնուհետև ուղարկվում է համակարգողին, որպեսզի նա կարողանա որոշել օգտագործողին սպասարկելու համար ամենահարմար աշխատողին: Ստորև բերված 4-րդ քայլը ստեղծում է խաղը: Օգտագործողի և նշանակված աշխատողի միջև հաստատվում է WebRTC հոսքային կապ:
  
  Մուտք գործելուց հետո օգտագործողի սցենարը

  Ինչ կա աշխատողի ներսում

  Խաղի և հոսքային խողովակաշարերը պահվում են աշխատողի ներսում մեկուսացված և այնտեղ տեղեկատվություն փոխանակում միջերեսի միջոցով: Ներկայումս այս հաղորդակցությունն իրականացվում է հիշողության մեջ տվյալների փոխանցման միջոցով Գոլանգի ալիքներ նույն գործընթացում։ Հաջորդ նպատակը սեգրեգացիան է, այսինքն. խաղի անկախ մեկնարկը մեկ այլ գործընթացում:

  
  Աշխատող բաղադրիչների փոխազդեցությունը

  Հիմնական բաղադրիչներ.

  • WebRTC: հաճախորդի բաղադրիչ, որն ընդունում է օգտատիրոջ մուտքը և սերվերից դուրս է բերում կոդավորված մեդիա:
  • Խաղի էմուլյատոր. խաղի բաղադրիչ. Libretro գրադարանի շնորհիվ համակարգը ի վիճակի է գործարկել խաղը նույն գործընթացի ներսում և ներքուստ ընդհատել մեդիան և մուտքային հոսքը:
  • Խաղի շրջանակները նկարահանվում և ուղարկվում են կոդավորողին:
  • Պատկերի/Աուդիո Կոդավորիչ. կոդավորման խողովակաշար, որը վերցնում է մեդիա շրջանակները, կոդավորում է դրանք ֆոնին և թողարկում կոդավորված պատկերներ/աուդիո:

  Իրականացման

  CloudRetro-ն ապավինում է WebRTC-ին՝ որպես իր ողնաշարի տեխնոլոգիայի, այնպես որ նախքան Golang-ի իրականացման մանրամասների մեջ խորանալը, ես որոշեցի խոսել հենց WebRTC-ի մասին: Սա զարմանահրաշ տեխնոլոգիա է, որն ինձ մեծապես օգնել է հոսքային տվյալների համար երկրորդական ուշացման հասնելու հարցում:

  WebRTC- ն

  WebRTC-ն նախագծված է ապահովելու բարձրորակ հավասարակից կապեր բնիկ բջջային հավելվածների և բրաուզերների վրա՝ օգտագործելով պարզ API-ներ:

  NAT Traversal

  WebRTC-ն հայտնի է իր NAT Traversal ֆունկցիոնալությամբ: WebRTC-ն նախատեսված է հասակակիցների միջև հաղորդակցության համար: Դրա նպատակն է գտնել ամենահարմար ուղիղ երթուղին, խուսափելով NAT-ի դարպասներից և firewalls-ից՝ հավասարակցական հաղորդակցության համար՝ գործընթացի միջոցով, որը կոչվում է. ICE. Որպես այս գործընթացի մաս, WebRTC API-ները գտնում են ձեր հանրային IP հասցեն STUN սերվերների միջոցով և այն փոխանցում ռելե սերվերին (ԿԱՐՈՂ) երբ ուղղակի կապ չի կարող հաստատվել:

  Այնուամենայնիվ, CloudRetro-ն ամբողջությամբ չի օգտագործում այս հնարավորությունը: Դրա գործընկերների միջև կապերը գոյություն ունեն ոչ թե օգտվողների, այլ օգտագործողների և ամպային սերվերների միջև: Մոդելի սերվերի կողմն ունի ավելի քիչ ուղղակի կապի սահմանափակումներ, քան սովորական օգտագործողի սարքը: Սա թույլ է տալիս նախապես բացել մուտքային նավահանգիստները կամ ուղղակիորեն օգտագործել հանրային IP հասցեները, քանի որ սերվերը NAT-ի հետևում չէ:

  Նախկինում ես ցանկանում էի նախագիծը վերածել Cloud Gaming-ի խաղերի բաշխման հարթակի: Գաղափարն այն էր, որ խաղեր ստեղծողներին թույլ տան տրամադրել խաղեր և հոսքային ռեսուրսներ: Եվ օգտվողները ուղղակիորեն կշփվեն պրովայդերների հետ: Այս ապակենտրոնացված ձևով, CloudRetro-ն ուղղակի շրջանակ է՝ երրորդ կողմի հոսքային ռեսուրսներն օգտատերերին միացնելու համար՝ դարձնելով այն ավելի լայնածավալ, երբ այն այլևս հոսթինգ չէ: WebRTC NAT Traversal-ի դերն այստեղ շատ կարևոր է երրորդ կողմի հոսքային ռեսուրսների վրա հասակակից կապի սկզբնավորումը հեշտացնելու համար, ինչը ստեղծողի համար հեշտացնում է ցանցին միանալը:

  Տեսանյութի սեղմում

  Տեսանյութերի սեղմումը խողովակաշարի անփոխարինելի մասն է և մեծապես նպաստում է հարթ հոսքին: Թեև անհրաժեշտ չէ իմանալ VP8/H264 վիդեո կոդավորման բոլոր մանրամասները, հասկացությունների ըմբռնումը կարող է օգնել ձեզ հասկանալ հոսքային տեսանյութի արագության տարբերակները, վրիպազերծել անսպասելի վարքագիծը և կարգավորել հետաձգումը:

  Հոսքային ծառայության համար տեսանյութի սեղմումը դժվար է, քանի որ ալգորիթմը պետք է ապահովի, որ կոդավորման ընդհանուր ժամանակը + ցանցի փոխանցման ժամանակը + ապակոդավորման ժամանակը հնարավորինս ցածր լինի: Բացի այդ, կոդավորման գործընթացը պետք է լինի հետևողական և շարունակական: Կոդավորման որոշ փոխզիջումներ չեն կիրառվում, օրինակ, մենք չենք կարող նախապատվություն տալ կոդավորման երկար ժամանակներին ավելի փոքր ֆայլերի չափերի և ապակոդավորման ժամանակների փոխարեն կամ օգտագործել անհամապատասխան սեղմում:

  Տեսանյութերի սեղմման գաղափարն է՝ վերացնել տեղեկատվության ավելորդ մասնիկները՝ միաժամանակ պահպանելով օգտագործողների համար ընդունելի ճշգրտության մակարդակը: Ի հավելումն առանձին ստատիկ պատկերի շրջանակների կոդավորման, ալգորիթմը ենթադրում է ընթացիկ շրջանակը նախորդ և հաջորդներից, ուստի ուղարկվում է միայն դրանց տարբերությունը: Ինչպես երևում է Pacman-ի օրինակից, փոխանցվում են միայն դիֆերենցիալ կետեր:

  
  Տեսանյութերի շրջանակների համեմատություն՝ օգտագործելով Pacman-ը որպես օրինակ

  Աուդիո սեղմում

  Նմանապես, աուդիո սեղմման ալգորիթմը բաց է թողնում այն ​​տվյալները, որոնք չեն կարող ընկալվել մարդկանց կողմից: Opus-ը ներկայումս լավագույն կատարող աուդիո կոդեկն է: Այն նախագծված է աուդիո ալիք փոխանցելու պատվիրված datagram արձանագրության միջոցով, ինչպիսին է RTP-ը (Real Time Transport Protocol): Դրա հետաձգումը ցածր է mp3-ից և aac-ից, իսկ որակն ավելի բարձր է: Լատենտությունը սովորաբար կազմում է մոտ 5-66,5 մս:

  Pion, WebRTC Գոլանգում

  Պիոն բաց կոդով նախագիծ է, որը WebRTC-ին բերում է Golang: C++ WebRTC գրադարանների սովորական փաթեթավորման փոխարեն, Pion-ը WebRTC-ի տեղական Golang-ի ներդրումն է՝ ավելի լավ կատարողականությամբ, Go ինտեգրմամբ և տարբերակների վերահսկմամբ WebRTC արձանագրությունների վրա:

  Գրադարանը նաև հնարավորություն է տալիս հեռարձակում բազմաթիվ հիանալի ներկառուցված սարքերով, որոնք ունեն երկրորդական ուշացում: Այն ունի STUN, DTLS, SCTP և այլնի իր ներդրումը: և որոշ փորձեր QUIC-ի և WebAssembly-ի հետ: Այս բաց կոդով գրադարանն ինքնին իսկապես լավ ուսուցման ռեսուրս է հիանալի փաստաթղթերով, ցանցային արձանագրությունների ներդրմամբ և հիանալի օրինակներով:

  Pion համայնքը, որը ղեկավարվում է շատ կրքոտ ստեղծագործողի կողմից, բավականին աշխույժ է, WebRTC-ի վերաբերյալ շատ որակյալ քննարկումներ են ընթանում: Եթե ​​դուք հետաքրքրված եք այս տեխնոլոգիայով, միացեք http://pion.ly/slack - Դուք շատ նոր բաներ կսովորեք:

  CloudRetro գրել Golang-ում

  
  Գոյում բանվորի ներդրում

  Անցեք ալիքներ գործողության մեջ

  Go-ի գեղեցիկ ալիքի դիզայնի շնորհիվ իրադարձությունների հոսքի և միաժամանակության խնդիրները զգալիորեն պարզեցված են: Ինչպես գծապատկերում, տարբեր GoRoutine-ներն ունեն զուգահեռ աշխատող մի քանի բաղադրիչ: Յուրաքանչյուր բաղադրիչ կառավարում է իր վիճակը և հաղորդակցվում ալիքների միջոցով: Գոլանգի ընտրովի պնդումը ստիպում է մեկ ատոմային իրադարձություն մշակել ամեն անգամ խաղի ընթացքում (խաղի տիզ): Սա նշանակում է, որ այս դիզայնի համար կողպեքի կարիք չկա: Օրինակ, երբ օգտատերը պահում է, պահանջվում է խաղի վիճակի ամբողջական պատկերը: Այս վիճակը պետք է մնա շարունակական՝ մուտք գործելով մինչև պահպանման ավարտը: Յուրաքանչյուր խաղի ժամանակ, հետնամասը կարող է միայն պահպանել կամ մուտքագրել գործողություն՝ դարձնելով գործընթացի շարանը անվտանգ:

  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-ի օգտագործման գործին: Այս օրինակին հետևելով՝ մեկ սենյակում օգտագործողի բոլոր մուտքերը ներկառուցված են կենտրոնական մուտքի ալիքում: Խաղի մեդիան այնուհետև տեղադրվում է նույն սենյակում գտնվող բոլոր օգտվողների համար: Այս կերպ մենք հասնում ենք խաղային վիճակի բաժանմանը տարբեր օգտատերերի մի քանի խաղ սեսիաների միջև։

  
  Համաժամեցում տարբեր նիստերի միջև

  Golang-ի թերությունները

  Գոլանգը կատարյալ չէ: Ալիքը դանդաղ է: Արգելափակման համեմատ՝ Go ալիքը պարզապես ավելի հեշտ միջոց է միաժամանակյա և շղթայական իրադարձությունները կարգավորելու համար, սակայն ալիքը լավագույն կատարումը չի ապահովում: Ալիքի տակ բարդ արգելափակող տրամաբանություն կա: Այսպիսով, ես որոշ ճշգրտումներ կատարեցի կատարման մեջ, նորից կիրառելով կողպեքներ և ատոմային արժեքներ, երբ փոխարինում էի ալիքները՝ արդյունավետությունը օպտիմալացնելու համար:

  Բացի այդ, Գոլանգում աղբահավաքը չի կառավարվում, ինչը երբեմն կասկածելիորեն երկար դադարներ է առաջացնում։ Սա մեծապես խանգարում է իրական ժամանակի հոսքային հավելվածին:

  COG

  Նախագիծը օգտագործում է գոյություն ունեցող բաց կոդով Golang VP8/H264 գրադարանը՝ մեդիա սեղմման համար, իսկ Libretro-ն՝ խաղերի էմուլյատորների համար: Այս բոլոր գրադարանները պարզապես Go-ում օգտագործվող C գրադարանի փաթաթիչներ են COG. Որոշ թերություններ թվարկված են Դեյվ Չեյնիի այս գրառումը. Խնդիրներ, որոնք ես հանդիպեցի.

  • CGO-ում վթարի ենթարկվելու անկարողություն, նույնիսկ Golang RecoveryCrash-ով;
  • կատարողականի խոչընդոտները հայտնաբերելու ձախողում, երբ մենք չենք կարողանում բացահայտել CGO-ում մանրամասն խնդիրներ:

  Ամփոփում

  Ես հասա իմ նպատակին՝ հասկանալու ամպային խաղերի ծառայությունները և ստեղծել մի հարթակ, որն օգնում է ինձ խաղալ նոստալգիկ ռետրո խաղեր իմ ընկերների հետ առցանց: Այս ծրագիրը հնարավոր չէր լինի իրականացնել առանց Pion գրադարանի և Pion համայնքի աջակցության: Ես անչափ շնորհակալ եմ դրա ինտենսիվ զարգացման համար: WebRTC-ի և Pion-ի կողմից տրամադրված պարզ API-ներն ապահովում էին անխափան ինտեգրում: Հայեցակարգի իմ առաջին ապացույցը հրապարակվեց նույն շաբաթ, չնայած ես նախնական գիտելիքներ չունեի գործընկերների հետ (P2P) հաղորդակցության մասին:

  Չնայած ինտեգրման հեշտությանը, P2P հոսքը իսկապես շատ բարդ ոլորտ է համակարգչային գիտության մեջ: Նա պետք է զբաղվի երկարաժամկետ ցանցային ճարտարապետությունների բարդությամբ, ինչպիսիք են IP-ն և NAT-ը, որպեսզի ստեղծի հավասարակցական նստաշրջան: Այս նախագծի վրա աշխատելիս ես ձեռք բերեցի շատ արժեքավոր գիտելիքներ ցանցերի և կատարողականի օպտիմալացման մասին, ուստի ես խրախուսում եմ բոլորին փորձել ստեղծել P2P արտադրանք՝ օգտագործելով WebRTC:

  CloudRetro-ն ապահովում է օգտագործման բոլոր դեպքերը, որոնք ես սպասում էի իմ տեսանկյունից՝ որպես ռետրո խաղացող: Այնուամենայնիվ, կարծում եմ, որ նախագծում կան շատ ոլորտներ, որոնք ես կարող եմ բարելավել, օրինակ՝ ցանցն ավելի հուսալի և արդյունավետ դարձնելը, ավելի որակյալ խաղային գրաֆիկայի ապահովումը կամ օգտատերերի միջև խաղերը կիսելու հնարավորությունը: Ես քրտնաջան աշխատում եմ այս ուղղությամբ: Խնդրում ենք հետևել նախագիծը և աջակցեք, եթե ձեզ դուր է գալիս:

Source: www.habr.com