ღია კოდის ღრუბლოვანი თამაში WebRTC-ზე: p2p, მულტიპლეერი, ნულოვანი შეყოვნება

პროგრამული უზრუნველყოფა, როგორც სერვისი, ინფრასტრუქტურა, როგორც სერვისი, პლატფორმა, როგორც სერვისი, საკომუნიკაციო პლატფორმა, როგორც სერვისი, ვიდეო კონფერენცია, როგორც სერვისი, რაც შეეხება ღრუბლოვან თამაშს, როგორც სერვისს? უკვე იყო რამდენიმე მცდელობა შექმნათ ღრუბლოვანი თამაშები (Cloud Gaming), როგორიცაა Stadia, რომელიც ახლახან გამოუშვა Google-მა. სტადია არ არის ახალი WebRTC-ში, მაგრამ შეუძლიათ სხვებსაც გამოიყენონ WebRTC ანალოგიურად?

ტანჰ ნგუენმა გადაწყვიტა გამოეცადა ეს შესაძლებლობა თავის ღია კოდის პროექტზე CloudRetro. CloudRetro დაფუძნებულია Pion-ზე, პოპულარული WebRTC ბიბლიოთეკა Go-ზე დაფუძნებული (მადლობა ნაჩვენებია Pion-ის განვითარების გუნდისგან ამ სტატიის მომზადებაში დახმარებისთვის). ამ სტატიაში Thanh გთავაზობთ მიმოხილვას მისი პროექტის არქიტექტურაზე და ასევე საუბრობს იმაზე, თუ რა სასარგებლო რამ ისწავლა და რა გამოწვევები წააწყდა მუშაობის დროს.

Entry

შარშან, როდესაც Google-მა Stadia გამოაცხადა, გონება გამიბრაზდა. იდეა იმდენად უნიკალური და ინოვაციურია, რომ გამუდმებით მაინტერესებდა, როგორ იყო ეს შესაძლებელი არსებული ტექნოლოგიით. ამ თემის უკეთ გაგების სურვილმა მიბიძგა შემექმნა ღია კოდის ღრუბლოვანი თამაშის ჩემი საკუთარი ვერსია. შედეგი უბრალოდ ფანტასტიკური იყო. ქვემოთ მინდა გაგიზიაროთ ჩემს წელზე მუშაობის პროცესი პროექტი.

TLDR: მოკლე სლაიდ ვერსია მაჩვენებლებით

რატომ არის ღრუბლოვანი თამაში მომავალი

მე მჯერა, რომ Cloud Gaming მალე გახდება არა მხოლოდ თამაშების, არამედ კომპიუტერული მეცნიერების სხვა სფეროების შემდეგი თაობა. Cloud gaming არის კლიენტის/სერვერის მოდელის მწვერვალი. ეს მოდელი აძლიერებს backend-ის მენეჯმენტს და ამცირებს ფრონტენდის მუშაობას დისტანციურ სერვერზე თამაშის ლოგიკის ჰოსტინგით და კლიენტისთვის სურათების/აუდიო ნაკადით. სერვერი ახორციელებს მძიმე დამუშავებას, ასე რომ კლიენტი აღარ იქნება ტექნიკის შეზღუდვების წყალობაზე.

Google Stadia არსებითად გაძლევთ საშუალებას ითამაშოთ AAA თამაშები (ანუ მაღალი დონის ბლოკბასტერ თამაშები) ისეთ ინტერფეისზე, როგორიცაა YouTube. იგივე მეთოდოლოგია შეიძლება გამოყენებულ იქნას სხვა მძიმე ოფლაინ აპლიკაციებზე, როგორიცაა ოპერაციული სისტემა ან 2D/3D გრაფიკული დიზაინი და ა.შ. ასე რომ, ჩვენ შეგვიძლია მათი თანმიმდევრულად გაშვება დაბალი სპეციფიკაციის მოწყობილობებზე მრავალ პლატფორმაზე.

ამ ტექნოლოგიის მომავალი: წარმოიდგინეთ, თუ Microsoft Windows 10 მუშაობდა Chrome ბრაუზერზე?

ღრუბლოვანი თამაში ტექნიკურად რთულია

თამაში არის ერთ-ერთი ის იშვიათი სფერო, სადაც მომხმარებლის მუდმივი, სწრაფი რეაგირებაა საჭირო. თუ გვერდებზე დაწკაპუნებისას ზოგჯერ ვაწყდებით 2 წამის შეფერხებას, ეს მისაღებია. ცოცხალი ვიდეო ნაკადები, როგორც წესი, ჩერდება რამდენიმე წამით, მაგრამ მაინც გვთავაზობს გონივრულ გამოყენებადობას. თუმცა, თუ თამაში ხშირად ჩამორჩება 500 ms-ით, ის უბრალოდ შეუძლებელია. ჩვენი მიზანია მივაღწიოთ უკიდურესად დაბალ შეყოვნებას ისე, რომ შეყვანისა და მედიას შორის უფსკრული იყოს რაც შეიძლება მცირე. ამიტომ, ვიდეო ნაკადის ტრადიციული მიდგომა აქ არ გამოიყენება.

ზოგადი ღრუბლოვანი თამაშის შაბლონი

ღია კოდის პროექტი CloudRetro

გადავწყვიტე შემექმნა ღრუბლოვანი თამაშის სატესტო ნიმუში, რათა გამეგო, შესაძლებელი იყო თუ არა ეს ყველაფერი ქსელის ასეთი მკაცრი შეზღუდვით. მე ავირჩიე Golang კონცეფციის დასამტკიცებლად, რადგან ეს იყო ენა, რომელსაც ყველაზე კარგად ვიცნობდი და კარგად იყო შესაფერისი ამ განხორციელებისთვის მრავალი სხვა მიზეზის გამო, როგორც მოგვიანებით აღმოვაჩინე. Go მარტივია და ძალიან სწრაფად ვითარდება; არხები Go-ში შესანიშნავია მრავალნაკადის მართვისთვის.

პროექტი CloudRetro.io არის ღია კოდის ღრუბლოვანი სათამაშო სერვისი რეტრო თამაშებისთვის. პროექტის მიზანია ტრადიციულ რეტრო თამაშებში ყველაზე კომფორტული სათამაშო გამოცდილების მიტანა და მულტიფლეიერის დამატება.
პროექტის შესახებ მეტი შეგიძლიათ გაიგოთ აქ: https://github.com/giongto35/cloud-game.

CloudRetro ფუნქციონირება

CloudRetro იყენებს რეტრო თამაშებს ღრუბლოვანი თამაშების ძალის დემონსტრირებისთვის. რაც საშუალებას გაძლევთ მიიღოთ მრავალი უნიკალური სათამაშო გამოცდილება.

• თამაშის პორტაბელურობა
  • მყისიერი დაკვრა გვერდის გახსნისას; არ არის საჭირო ჩამოტვირთვა ან ინსტალაცია
  • მუშაობს მობილური ბრაუზერში, ამიტომ არ არის საჭირო პროგრამული უზრუნველყოფა მის გასაშვებად

• თამაშის სესიების გაზიარება შესაძლებელია მრავალ მოწყობილობაში და შეინახება ღრუბელში შემდეგი შესვლისთვის
• თამაშის სტრიმინგი შესაძლებელია, ან მისი თამაში ერთდროულად რამდენიმე მომხმარებელმა შეიძლება:
  • Crowdplay, როგორიცაა TwitchPlayPokemon, მხოლოდ მეტი პლატფორმა და უფრო რეალურ დროში
  • ონლაინ თამაშები ოფლაინ. ბევრ მომხმარებელს შეუძლია თამაში ქსელის დაყენების გარეშე. Samurai Shodown-ს ახლა შეუძლია 2 მოთამაშის თამაში CloudRetro ქსელში

  
  ონლაინ მრავალმოთამაშიანი თამაშის დემო ვერსია სხვადასხვა მოწყობილობებზე

  ინფრასტრუქტურის

  მოთხოვნები და ტექნოლოგიის დასტა

  ქვემოთ მოცემულია მოთხოვნების ჩამონათვალი, რომლებიც მე დავაწესე პროექტის დაწყებამდე.

  1. ერთი მოთამაშე
  ეს მოთხოვნა შეიძლება აქ არ ჩანდეს ძალიან მნიშვნელოვანი ან აშკარა, მაგრამ ეს არის ჩემი ერთ-ერთი მთავარი გამოსავალი, ის საშუალებას აძლევს ღრუბლოვან თამაშს მაქსიმალურად შორს დარჩეს ტრადიციული ნაკადის სერვისებისგან. თუ ჩვენ ყურადღებას გავამახვილებთ ერთმოთამაშიან თამაშზე, ჩვენ შეგვიძლია მოვიშოროთ ცენტრალიზებული სერვერი ან CDN, რადგან არ გვჭირდება სტრიმინგი მასებში. იმის ნაცვლად, რომ ატვირთოთ ნაკადები sink სერვერზე ან პაკეტები გადაიტანოთ ცენტრალიზებულ WebSocket სერვერზე, სერვისის ნაკადები მიეწოდება პირდაპირ მომხმარებელს Peer-to-peer WebRTC კავშირის საშუალებით.

  2. დაბალი შეყოვნების მედია ნაკადი
  Stadia-ს შესახებ რომ ვკითხულობ, ხშირად ვხედავ ზოგიერთ სტატიაში მოხსენიებულ WebRTC-ს. მივხვდი, რომ WebRTC არის გამორჩეული ტექნოლოგია და შესანიშნავია ღრუბლოვანი თამაშების გამოსაყენებლად. WebRTC არის პროექტი, რომელიც უზრუნველყოფს ვებ ბრაუზერებსა და მობილურ აპლიკაციებს რეალურ დროში კომუნიკაციით მარტივი API-ის საშუალებით. ის უზრუნველყოფს peer-to-peer კავშირს, ოპტიმიზებულია მედიისთვის და აქვს ჩაშენებული სტანდარტული კოდეკები, როგორიცაა VP8 და H264.

  მე უპირატესობა მიანიჭე მომხმარებლის საუკეთესო გამოცდილების უზრუნველყოფას, ვიდრე მაღალი ხარისხის გრაფიკის შენარჩუნებას. ალგორითმში გარკვეული დანაკარგები მისაღებია. Google Stadia-ს აქვს დამატებითი ნაბიჯი სერვერზე გამოსახულების ზომის შემცირების მიზნით, ხოლო ჩარჩოები უფრო მაღალ ხარისხზე გადაიცემა თანატოლებზე გადაცემამდე.

  3. განაწილებული ინფრასტრუქტურა გეოგრაფიული მარშრუტით
  არ აქვს მნიშვნელობა რამდენად ოპტიმიზირებულია შეკუმშვის ალგორითმი და კოდი, ქსელი მაინც არის გადამწყვეტი ფაქტორი, რომელიც ყველაზე მეტად უწყობს ხელს შეყოვნებას. არქიტექტურას უნდა ჰქონდეს მომხმარებელთან ყველაზე ახლოს სერვერის დაწყვილების მექანიზმი, რათა შემცირდეს ორმხრივი დრო (RTT). არქიტექტურას უნდა ჰქონდეს 1 კოორდინატორი და რამდენიმე ნაკადი სერვერი, რომლებიც განაწილებულია მთელ მსოფლიოში: აშშ დასავლეთი, აშშ აღმოსავლეთი, ევროპა, სინგაპური, ჩინეთი. ყველა ნაკადი სერვერი უნდა იყოს მთლიანად იზოლირებული. სისტემას შეუძლია შეცვალოს მისი განაწილება, როდესაც სერვერი უერთდება ან ტოვებს ქსელს. ამრიგად, დიდი ტრაფიკით, დამატებითი სერვერების დამატება საშუალებას იძლევა ჰორიზონტალური მასშტაბირება.

  4. ბრაუზერის თავსებადობა
  ღრუბლოვანი თამაში საუკეთესოა, როდესაც ის ყველაზე ნაკლებს მოითხოვს მომხმარებლებისგან. ეს ნიშნავს, რომ შესაძლებელია ბრაუზერში გაშვება. ბრაუზერები ხელს უწყობენ მომხმარებლებისთვის რაც შეიძლება კომფორტულს გახადონ თამაშების გამოცდილება, რაც მათ იცავს პროგრამული უზრუნველყოფისა და აპარატურის ინსტალაციისგან. ბრაუზერები ასევე ხელს უწყობენ მრავალ პლატფორმის ფუნქციონირებას მობილურ და დესკტოპ ვერსიებს შორის. საბედნიეროდ, WebRTC კარგად არის მხარდაჭერილი სხვადასხვა ბრაუზერში.

  5. თამაშის ინტერფეისისა და სერვისის ნათელი გამიჯვნა
  მე ვუყურებ ღრუბლოვან სათამაშო სერვისს, როგორც პლატფორმას. ყველას უნდა შეეძლოს რაიმეს დაკავშირება პლატფორმასთან. ახლა გავერთიანდი LibRetro ღრუბლოვანი თამაშების სერვისით, რადგან LibRetro გთავაზობთ ულამაზესი თამაშის ემულატორის ინტერფეისს რეტრო თამაშებისთვის, როგორიცაა SNES, GBA, PS.

  6. ოთახები მულტიმოთამაშისთვის, ბრბოს თამაშისთვის და თამაშთან გარე კავშირისთვის (deep-link).
  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 შექმნილია იმისთვის, რომ უზრუნველყოს მაღალი ხარისხის peer-to-peer კავშირები მშობლიურ მობილურ აპებსა და ბრაუზერებზე მარტივი API-ების გამოყენებით.

  NAT Traversal

  WebRTC ცნობილია თავისი NAT Traversal ფუნქციონირებით. WebRTC შექმნილია თანატოლებთან ურთიერთობისთვის. მისი მიზანია იპოვოთ ყველაზე შესაფერისი პირდაპირი მარშრუტი, თავიდან აიცილოს NAT კარიბჭეები და ფეიერვოლები თანატოლებთან კომუნიკაციისთვის პროცესის საშუალებით, რომელსაც ე.წ. ICE. როგორც ამ პროცესის ნაწილი, WebRTC API პოულობს თქვენს საჯარო IP მისამართს STUN სერვერების გამოყენებით და გადასცემს მას სარელეო სერვერზე (ᲛᲝᲑᲠᲣᲜᲔᲑᲐ) როცა პირდაპირი კავშირის დამყარება შეუძლებელია.

  თუმცა, CloudRetro სრულად არ იყენებს ამ ფუნქციას. მისი თანატოლთა შორის კავშირები არ არსებობს მომხმარებლებს შორის, არამედ მომხმარებლებსა და ღრუბლოვან სერვერებს შორის. მოდელის სერვერის მხარეს აქვს ნაკლები პირდაპირი კომუნიკაციის შეზღუდვები, ვიდრე ტიპიური მომხმარებლის მოწყობილობა. ეს საშუალებას გაძლევთ წინასწარ გახსნათ შემომავალი პორტები ან გამოიყენოთ საჯარო IP მისამართები პირდაპირ, რადგან სერვერი არ დგას NAT-ის უკან.

  ადრე მინდოდა გადამექცია პროექტი Cloud Gaming-ისთვის თამაშის განაწილების პლატფორმად. იდეა იყო თამაშის შემქმნელებს მიეცეთ საშუალება მიეწოდებინათ თამაშები და სტრიმინგის რესურსები. და მომხმარებლები უშუალოდ დაუკავშირდნენ პროვაიდერებს. ამ დეცენტრალიზებული გზით, CloudRetro არის მხოლოდ ჩარჩო მესამე მხარის ნაკადის რესურსების მომხმარებლებთან დასაკავშირებლად, რაც მას უფრო მასშტაბურს ხდის, როდესაც ის აღარ არის ჰოსტინგი. WebRTC NAT Traversal-ის როლი აქ ძალიან მნიშვნელოვანია, რათა ხელი შეუწყოს თანატოლებთან კავშირის ინიციალიზაციას მესამე მხარის ნაკადის რესურსებზე, რაც გაუადვილებს შემქმნელს ქსელთან დაკავშირებას.

  ვიდეო შეკუმშვა

  ვიდეო შეკუმშვა არის მილსადენის შეუცვლელი ნაწილი და დიდად უწყობს ხელს გლუვ ნაკადს. მიუხედავად იმისა, რომ არ არის აუცილებელი VP8/H264 ვიდეო კოდირების ყველა დეტალის ცოდნა, ცნებების გაგება დაგეხმარებათ გაეცნოთ ნაკადის ვიდეოს სიჩქარის ვარიანტებს, გამართოთ მოულოდნელი ქცევა და შეცვალოთ შეყოვნება.

  ნაკადის სერვისისთვის ვიდეოს შეკუმშვა რთულია, რადგან ალგორითმმა უნდა უზრუნველყოს, რომ კოდირების მთლიანი დრო + ქსელის გადაცემის დრო + დეკოდირების დრო რაც შეიძლება დაბალი იყოს. გარდა ამისა, კოდირების პროცესი უნდა იყოს თანმიმდევრული და უწყვეტი. ზოგიერთი კოდირების კომპეტენცია არ გამოიყენება - მაგალითად, ჩვენ არ შეგვიძლია უპირატესობა მიანიჭოთ კოდირების ხანგრძლივ პერიოდს ფაილის მცირე ზომისა და დეკოდირების დროს, ან გამოვიყენოთ არათანმიმდევრული შეკუმშვა.

  ვიდეო შეკუმშვის იდეა არის ინფორმაციის არასაჭირო ნაწილის აღმოფხვრა, ხოლო მომხმარებლებისთვის სიზუსტის მისაღები დონის შენარჩუნება. ცალკეული სტატიკური გამოსახულების ჩარჩოების დაშიფვრის გარდა, ალგორითმი ადგენს მიმდინარე კადრებს წინა და მომდევნო ჩარჩოებიდან, ასე რომ მხოლოდ მათი განსხვავება იგზავნება. როგორც Pacman-ის მაგალითიდან ჩანს, მხოლოდ დიფერენციალური წერტილები გადაიცემა.

  
  ვიდეო ჩარჩოების შედარება Pacman-ის მაგალითის გამოყენებით

  აუდიო შეკუმშვა

  ანალოგიურად, აუდიო შეკუმშვის ალგორითმი გამოტოვებს მონაცემებს, რომლებიც ვერ აღიქვამს ადამიანებს. Opus ამჟამად საუკეთესო შესრულების აუდიო კოდეკია. იგი შექმნილია აუდიო ტალღის გადასაცემად შეკვეთილი დატაგრამის პროტოკოლით, როგორიცაა RTP (Real Time Transport Protocol). მისი შეყოვნება უფრო დაბალია ვიდრე mp3 და aac, ხოლო ხარისხი უფრო მაღალია. შეყოვნება ჩვეულებრივ არის დაახლოებით 5-66,5ms.

  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-ს აქვს მრავალი კომპონენტი, რომელიც მუშაობს პარალელურად. თითოეული კომპონენტი მართავს თავის მდგომარეობას და ურთიერთობს არხებით. გოლანგის შერჩევითი მტკიცება აიძულებს ერთი ატომური მოვლენის დამუშავებას ყოველ ჯერზე თამაშში (თამაშის ტიკი). ეს ნიშნავს, რომ ამ დიზაინისთვის ჩაკეტვა არ არის საჭირო. მაგალითად, როდესაც მომხმარებელი ინახავს, ​​საჭიროა თამაშის მდგომარეობის სრული სურათი. ეს მდგომარეობა უნდა დარჩეს უწყვეტი, შედით სისტემაში შენახვის დასრულებამდე. თითოეული თამაშის ტიკის დროს, backend-ს შეუძლია გაუმკლავდეს მხოლოდ შენახვის ან შეყვანის ოპერაციას, რაც პროცესის ძაფს უსაფრთხოს ხდის.

  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-out

  ეს Golang შაბლონი იდეალურად ერგება ჩემს CrowdPlay-ს და Multiple Player-ის გამოყენებას. ამ ნიმუშის მიხედვით, ერთ ოთახში მომხმარებლის ყველა შეყვანა ჩაშენებულია ცენტრალურ შესასვლელ არხში. თამაშის მედია შემდეგ განლაგებულია ყველა მომხმარებლისთვის იმავე ოთახში. ამ გზით ჩვენ მივაღწევთ თამაშის მდგომარეობის გაყოფას სხვადასხვა მომხმარებლის რამდენიმე თამაშის სესიას შორის.

  
  სინქრონიზაცია სხვადასხვა სესიებს შორის

  გოლანგის ნაკლოვანებები

  გოლანგი არ არის სრულყოფილი. არხი ნელია. დაბლოკვასთან შედარებით, Go არხი უბრალოდ უფრო მარტივი გზაა ერთდროული და ნაკადიანი მოვლენების დასამუშავებლად, მაგრამ არხი არ იძლევა საუკეთესო შესრულებას. არხის ქვეშ არის რთული დაბლოკვის ლოგიკა. ასე რომ, მე შევიტანე გარკვეული კორექტირება განხორციელებაში, ხელახლა გამოვიყენე საკეტები და ატომური მნიშვნელობები არხების გამოცვლისას შესრულების ოპტიმიზაციის მიზნით.

  გარდა ამისა, გოლანგში ნაგვის შემგროვებელი უმართავია, რაც ზოგჯერ საეჭვოდ ხანგრძლივ პაუზებს იწვევს. ეს დიდად ერევა რეალურ დროში ნაკადის აპლიკაციაში.

  COG

  პროექტი იყენებს არსებულ ღია კოდის Golang VP8/H264 ბიბლიოთეკას მედიის შეკუმშვისთვის და Libretro-ს თამაშის ემულატორებისთვის. ყველა ეს ბიბლიოთეკა უბრალოდ არის C ბიბლიოთეკის შეფუთვა Go-ში COG. ზოგიერთი უარყოფითი მხარე ჩამოთვლილია დეივ ჩეინის ეს პოსტი. პრობლემები, რომლებიც შემხვდა:

  • CGO-ში ავარიის დაჭერის შეუძლებლობა, თუნდაც Golang RecoveryCrash-ით;
  • შესრულების შეფერხებების გამოვლენის შეუსრულებლობა, როდესაც ჩვენ ვერ ვახერხებთ CGO-ში დეტალური პრობლემების აღმოჩენას.

  დასკვნა

  მე მივაღწიე ჩემს მიზანს, გამეგო ღრუბლოვანი თამაშების სერვისები და შევქმნა პლატფორმა, რომელიც მეხმარება ჩემს მეგობრებთან ერთად ნოსტალგიური რეტრო თამაშების ონლაინ თამაში. ეს პროექტი შეუძლებელი იქნებოდა პიონის ბიბლიოთეკისა და პიონის საზოგადოების მხარდაჭერის გარეშე. ძალიან მადლობელი ვარ მისი ინტენსიური განვითარებისთვის. WebRTC-ისა და Pion-ის მიერ მოწოდებული მარტივი API-ები უზრუნველყოფენ უწყვეტ ინტეგრაციას. კონცეფციის ჩემი პირველი მტკიცებულება გამოქვეყნდა იმავე კვირაში, მიუხედავად იმისა, რომ წინასწარ არ მქონდა ცოდნა თანატოლებთან (P2P) კომუნიკაციის შესახებ.

  ინტეგრაციის სიმარტივის მიუხედავად, P2P ნაკადი მართლაც ძალიან რთული სფეროა კომპიუტერულ მეცნიერებაში. მას უნდა გაუმკლავდეს გრძელვადიანი ქსელის არქიტექტურის სირთულეს, როგორიცაა IP და NAT, რათა შექმნას Peer-to-peer სესია. ამ პროექტზე მუშაობისას, მე მივიღე ბევრი ღირებული ცოდნა ქსელის და შესრულების ოპტიმიზაციის შესახებ, ამიტომ ყველას მოვუწოდებ, სცადონ P2P პროდუქტების შექმნა WebRTC-ის გამოყენებით.

  CloudRetro ითვალისწინებს გამოყენების ყველა შემთხვევას, რასაც ველოდი ჩემი, როგორც რეტრო მოთამაშის პერსპექტივიდან. თუმცა, ვფიქრობ, რომ პროექტში ბევრი სფეროა, რომელთა გაუმჯობესებაც შემიძლია, მაგალითად, ქსელის უფრო საიმედო და ეფექტურობა, თამაშის უფრო მაღალი ხარისხის გრაფიკის უზრუნველყოფა, ან თამაშების მომხმარებლებს შორის გაზიარების შესაძლებლობა. ამაზე ბევრს ვმუშაობ. Გთხოვ გამომყევი პროექტი და მხარი დაუჭირეთ თუ მოგწონთ.

წყარო: www.habr.com