შესავალი

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

როგორც მისი აპლიკაციის მაგალითი, ჩვენ გადავწყვიტეთ მულტიმოთამაშიანი თამაშის პორტირება ინტერნეტში და ავირჩიეთ Teeworlds. Teeworlds არის მულტიმოთამაშიანი 2D რეტრო თამაში მოთამაშეთა მცირე, მაგრამ აქტიური თემით (მათ შორის მე!). ის მცირეა როგორც გადმოწერილი რესურსების, ასევე CPU და GPU მოთხოვნების თვალსაზრისით - იდეალური კანდიდატი.

მუშაობს Teeworlds ბრაუზერში

ჩვენ გადავწყვიტეთ გამოვიყენოთ ეს პროექტი ექსპერიმენტებისთვის ზოგადი გადაწყვეტილებები ქსელის კოდის ინტერნეტში გადატანისთვის. ეს ჩვეულებრივ კეთდება შემდეგი გზებით:

• XMLHttpმოთხოვნა/მოტანა, თუ ქსელის ნაწილი შედგება მხოლოდ HTTP მოთხოვნებისგან, ან
• ვებ -სოკეტები.

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

არსებობს მესამე გზა - გამოიყენეთ ქსელი ბრაუზერიდან: WebRTC.

RTCDataChannel იგი მხარს უჭერს როგორც საიმედო, ასევე არასანდო გადაცემას (ამ უკანასკნელ შემთხვევაში ის ცდილობს გამოიყენოს UDP, როგორც სატრანსპორტო პროტოკოლი, როდესაც ეს შესაძლებელია) და შეიძლება გამოყენებულ იქნას როგორც დისტანციურ სერვერთან, ასევე ბრაუზერებს შორის. ეს ნიშნავს, რომ ჩვენ შეგვიძლია მთელი აპლიკაციის პორტირება ბრაუზერში, სერვერის კომპონენტის ჩათვლით!

თუმცა, ამას დამატებითი სირთულე მოჰყვება: სანამ ორი WebRTC თანატოლი შეძლებს კომუნიკაციას, მათ უნდა შეასრულონ შედარებით რთული ხელის ჩამორთმევა დასაკავშირებლად, რაც მოითხოვს რამდენიმე მესამე მხარის ერთეულს (სასიგნალო სერვერს და ერთ ან მეტ სერვერს. STUN/ᲛᲝᲑᲠᲣᲜᲔᲑᲐ).

იდეალურ შემთხვევაში, ჩვენ გვსურს შევქმნათ ქსელის API, რომელიც იყენებს WebRTC-ს შიდა, მაგრამ რაც შეიძლება ახლოს იქნება UDP Sockets ინტერფეისთან, რომელსაც არ სჭირდება კავშირის დამყარება.

ეს მოგვცემს საშუალებას ვისარგებლოთ WebRTC–ით აპლიკაციის კოდისთვის რთული დეტალების გამოვლენის გარეშე (რომლის შეცვლაც რაც შეიძლება ნაკლებად გვინდოდა ჩვენს პროექტში).

მინიმალური WebRTC

WebRTC არის API-ების ნაკრები, რომელიც ხელმისაწვდომია ბრაუზერებში, რომელიც უზრუნველყოფს აუდიო, ვიდეო და თვითნებური მონაცემების peer-to-peer გადაცემას.

კავშირი თანატოლებს შორის მყარდება (მაშინაც კი, თუ არსებობს NAT ერთ ან ორივე მხარეს) STUN და/ან TURN სერვერების გამოყენებით მექანიზმის საშუალებით, რომელსაც ეწოდება ICE. თანატოლები ცვლის ICE ინფორმაციას და არხის პარამეტრებს SDP პროტოკოლის შეთავაზებისა და პასუხის საშუალებით.

Ვაუ! რამდენი აბრევიატურა ერთდროულად? მოკლედ ავხსნათ რას ნიშნავს ეს ტერმინები:

• Session Traversal Utilities for NAT (STUN) — პროტოკოლი NAT-ის გვერდის ავლით და წყვილის მისაღებად (IP, პორტი) მონაცემთა პირდაპირ ჰოსტთან გაცვლისთვის. თუ ის მოახერხებს დავალების შესრულებას, მაშინ თანატოლებს შეუძლიათ დამოუკიდებლად გაცვალონ მონაცემები ერთმანეთთან.
• გადაკვეთა რელეების გამოყენებით NAT-ის გარშემო (ᲛᲝᲑᲠᲣᲜᲔᲑᲐ) ასევე გამოიყენება NAT გადასასვლელად, მაგრამ ის ამას ახორციელებს მონაცემების გადაგზავნა პროქსის მეშვეობით, რომელიც ხილულია ორივე თანატოლისთვის. ის ამატებს შეყოვნებას და უფრო ძვირია განსახორციელებლად, ვიდრე STUN (რადგან იგი გამოიყენება მთელი საკომუნიკაციო სესიის განმავლობაში), მაგრამ ზოგჯერ ეს ერთადერთი ვარიანტია.
• ინტერაქტიული კავშირის დამყარება (ICE) გამოიყენება ორი თანატოლის დასაკავშირებლად საუკეთესო შესაძლო მეთოდის შესარჩევად, რომელიც ეფუძნება უშუალოდ თანატოლებთან დაკავშირების შედეგად მიღებულ ინფორმაციას, ასევე STUN და TURN სერვერების ნებისმიერი რაოდენობის მიერ მიღებულ ინფორმაციას.
• სესიის აღწერილობის პროტოკოლი (SDP) არის კავშირის არხის პარამეტრების აღწერის ფორმატი, მაგალითად, ICE კანდიდატები, მულტიმედიური კოდეკები (აუდიო/ვიდეო არხის შემთხვევაში) და ა.შ... ერთ-ერთი თანატოლი აგზავნის SDP შეთავაზებას, მეორე კი პასუხობს SDP პასუხით. . ამის შემდეგ იქმნება არხი.

ასეთი კავშირის შესაქმნელად, თანატოლებმა უნდა შეაგროვონ ინფორმაცია, რომელსაც მიიღებენ STUN და TURN სერვერებიდან და გაცვალონ ისინი ერთმანეთთან.

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

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

გამარტივებული WebRTC ხელის ჩამორთმევის მიმდევრობის დიაგრამა

Teeworlds ქსელის მოდელის მიმოხილვა

Teeworlds ქსელის არქიტექტურა ძალიან მარტივია:

• კლიენტი და სერვერის კომპონენტები ორი განსხვავებული პროგრამაა.
• კლიენტები შედიან თამაშში რამდენიმე სერვერიდან ერთ-ერთთან დაკავშირებით, რომელთაგან თითოეული მასპინძლობს მხოლოდ ერთ თამაშს ერთდროულად.
• თამაშში ყველა მონაცემთა გადაცემა ხდება სერვერის საშუალებით.
• სპეციალური სამაგისტრო სერვერი გამოიყენება ყველა საჯარო სერვერის სიის შესაგროვებლად, რომლებიც ნაჩვენებია თამაშის კლიენტში.

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

მოიშორეთ სერვერები

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

თუმცა, იმისათვის, რომ სისტემა იმუშაოს, ჩვენ კვლავ უნდა გამოვიყენოთ გარე არქიტექტურა:

• ერთი ან მეტი STUN სერვერი: ჩვენ გვაქვს რამდენიმე უფასო არჩევანი.
• მინიმუმ ერთი TURN სერვერი: აქ არ არის უფასო ვარიანტები, ასე რომ ჩვენ შეგვიძლია დავაყენოთ საკუთარი ან გადავიხადოთ სერვისი. საბედნიეროდ, უმეტეს შემთხვევაში, კავშირი შეიძლება დამყარდეს STUN სერვერების საშუალებით (და უზრუნველყოს ნამდვილი p2p), მაგრამ TURN საჭიროა როგორც დამხმარე ვარიანტი.
• სიგნალიზაციის სერვერი: დანარჩენი ორი ასპექტისგან განსხვავებით, სიგნალიზაცია არ არის სტანდარტიზებული. რაზე იქნება რეალურად პასუხისმგებელი სასიგნალო სერვერი, გარკვეულწილად დამოკიდებულია აპლიკაციაზე. ჩვენს შემთხვევაში, კავშირის დამყარებამდე აუცილებელია მცირე რაოდენობის მონაცემების გაცვლა.
• Teeworlds Master Server: მას იყენებენ სხვა სერვერები თავიანთი არსებობის რეკლამირებისთვის და კლიენტების მიერ საჯარო სერვერების მოსაძებნად. მიუხედავად იმისა, რომ ეს არ არის საჭირო (კლიენტებს ყოველთვის შეუძლიათ ხელით დაუკავშირდნენ სერვერს, რომლის შესახებაც იციან), კარგი იქნება, რომ მოთამაშეებს შეეძლოთ მონაწილეობა მიიღონ თამაშებში შემთხვევით ადამიანებთან.

ჩვენ გადავწყვიტეთ გამოგვეყენებინა Google-ის უფასო STUN სერვერები და თავად განვათავსეთ ერთი TURN სერვერი.

ბოლო ორი პუნქტისთვის ჩვენ გამოვიყენეთ Firebase:

• Teeworlds სამაგისტრო სერვერი დანერგილია ძალიან მარტივად: როგორც ობიექტების სია, რომელიც შეიცავს ინფორმაციას (სახელი, IP, რუკა, რეჟიმი, ...) თითოეული აქტიური სერვერის შესახებ. სერვერები აქვეყნებენ და განაახლებს საკუთარ ობიექტს, კლიენტები კი იღებენ მთელ სიას და აჩვენებენ მას მოთამაშეს. ჩვენ ასევე ვაჩვენებთ სიას მთავარ გვერდზე, როგორც HTML, რათა მოთამაშეებმა უბრალოდ დააწკაპუნონ სერვერზე და პირდაპირ თამაშში გადაიყვანონ.
• სიგნალიზაცია მჭიდროდ არის დაკავშირებული ჩვენს სოკეტების განხორციელებასთან, რომელიც აღწერილია შემდეგ ნაწილში.

სერვერების სია თამაშის შიგნით და მთავარ გვერდზე

სოკეტების დანერგვა

ჩვენ გვინდა შევქმნათ API, რომელიც მაქსიმალურად ახლოს იქნება Posix UDP Sockets-თან, რათა მინიმუმამდე მივიყვანოთ საჭირო ცვლილებების რაოდენობა.

ჩვენ ასევე გვინდა განვახორციელოთ საჭირო მინიმუმი, რომელიც საჭიროა მონაცემთა უმარტივესი გაცვლისთვის ქსელში.

მაგალითად, ჩვენ არ გვჭირდება რეალური მარშრუტიზაცია: ყველა თანატოლი არის ერთსა და იმავე „ვირტუალურ LAN-ზე“, რომელიც დაკავშირებულია Firebase მონაცემთა ბაზის კონკრეტულ მაგალითთან.

ამიტომ, ჩვენ არ გვჭირდება უნიკალური IP მისამართები: უნიკალური Firebase გასაღების მნიშვნელობები (დომენის სახელების მსგავსი) საკმარისია თანატოლების ცალსახად იდენტიფიცირებისთვის და თითოეული თანატოლი ადგილობრივად ანიჭებს "ყალბ" IP მისამართებს თითოეულ გასაღებს, რომელიც უნდა ითარგმნოს. ეს მთლიანად გამორიცხავს გლობალური IP მისამართის მინიჭების აუცილებლობას, რაც არატრივიალური ამოცანაა.

აქ არის მინიმალური API, რომელიც უნდა განვახორციელოთ:

// Create and destroy a socket
int socket();
int close(int fd);
// Bind a socket to a port, and publish it on Firebase
int bind(int fd, AddrInfo* addr);
// Send a packet. This lazily create a WebRTC connection to the 
// peer when necessary
int sendto(int fd, uint8_t* buf, int len, const AddrInfo* addr);
// Receive the packets destined to this socket
int recvfrom(int fd, uint8_t* buf, int len, AddrInfo* addr);
// Be notified when new packets arrived
int recvCallback(Callback cb);
// Obtain a local ip address for this peer key
uint32_t resolve(client::String* key);
// Get the peer key for this ip
String* reverseResolve(uint32_t addr);
// Get the local peer key
String* local_key();
// Initialize the library with the given Firebase database and 
// WebRTc connection options
void init(client::FirebaseConfig* fb, client::RTCConfiguration* ice);

API არის მარტივი და მსგავსი Posix Sockets API-ს, მაგრამ აქვს რამდენიმე მნიშვნელოვანი განსხვავება: ზარების აღრიცხვა, ადგილობრივი IP-ების მინიჭება და ზარმაცი კავშირები.

ზარების რეგისტრაცია

მაშინაც კი, თუ თავდაპირველი პროგრამა იყენებს არადაბლოკვის I/O-ს, კოდი უნდა იყოს რეფაქტორირებული, რომ იმუშაოს ვებ ბრაუზერში.

ამის მიზეზი ის არის, რომ ბრაუზერში ღონისძიების ციკლი დამალულია პროგრამისგან (იქნება ეს JavaScript თუ WebAssembly).

მშობლიურ გარემოში შეგვიძლია ასეთი კოდის დაწერა

while(running) {
  select(...); // wait for I/O events
  while(true) {
    int r = readfrom(...); // try to read
    if (r < 0 && errno == EWOULDBLOCK) // no more data available
      break;
    ...
  }
  ...
}

თუ ღონისძიების მარყუჟი ჩვენთვის დამალულია, მაშინ ის უნდა გადავაქციოთ შემდეგნაირად:

auto cb = []() { // this will be called when new data is available
  while(true) {
    int r = readfrom(...); // try to read
    if (r < 0 && errno == EWOULDBLOCK) // no more data available
      break;
    ...
  }
  ...
};
recvCallback(cb); // register the callback

ლოკალური IP მინიჭება

ჩვენს "ქსელში" კვანძების ID არ არის IP მისამართები, არამედ Firebase გასაღებები (ისინი არის სტრიქონები, რომლებიც ასე გამოიყურება: -LmEC50PYZLCiCP-vqde ).

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

ეს არის ზუსტად ის, რისთვისაც გამოიყენება ფუნქციები. resolve и reverseResolve: აპლიკაცია როგორღაც იღებს გასაღების სტრიქონის მნიშვნელობას (მომხმარებლის შეყვანის ან ძირითადი სერვერის მეშვეობით) და შეუძლია მისი გადაყვანა IP მისამართად შიდა გამოყენებისთვის. დანარჩენი API ასევე იღებს ამ მნიშვნელობას სტრიქონის ნაცვლად სიმარტივისთვის.

ეს მსგავსია DNS-ის ძიებასთან, მაგრამ შესრულებულია ადგილობრივად კლიენტზე.

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

ზარმაცი კავშირი

UDP არ საჭიროებს კავშირს, მაგრამ როგორც ვნახეთ, WebRTC მოითხოვს ხანგრძლივ დაკავშირების პროცესს, სანამ ის შეძლებს მონაცემთა გადაცემას ორ თანატოლს შორის.

თუ ჩვენ გვსურს მივაწოდოთ აბსტრაქციის იგივე დონე, (sendto/recvfrom თვითნებურ თანატოლებთან წინასწარი კავშირის გარეშე), მაშინ მათ უნდა შეასრულონ "ზარმაცი" (დაგვიანებული) კავშირი API-ში.

ეს არის ის, რაც ხდება "სერვერსა" და "კლიენტს" შორის ნორმალური კომუნიკაციის დროს UDP-ის გამოყენებისას და რა უნდა გააკეთოს ჩვენმა ბიბლიოთეკამ:

• სერვერის ზარები bind()აცნობოს ოპერაციულ სისტემას, რომ მას სურს მიიღოს პაკეტები მითითებულ პორტზე.

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

• სერვერის ზარები recvfrom(), ამ პორტის ნებისმიერი ჰოსტიდან შემოსული პაკეტების მიღება.

ჩვენს შემთხვევაში, ჩვენ უნდა შევამოწმოთ ამ პორტში გაგზავნილი პაკეტების შემომავალი რიგი.

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

ზარი არ არის დაბლოკილი, ასე რომ, თუ პაკეტები არ არის, ჩვენ უბრალოდ ვაბრუნებთ -1 და ვაყენებთ errno=EWOULDBLOCK.

• კლიენტი იღებს სერვერის IP-ს და პორტს გარკვეული გარე საშუალებებით და ზარებს sendto(). ეს ასევე ახდენს შიდა ზარს. bind(), შესაბამისად შემდგომი recvfrom() მიიღებს პასუხს ცალსახად შესრულების გარეშე.

ჩვენს შემთხვევაში, კლიენტი გარედან იღებს სტრიქონის კლავიშს და იყენებს ფუნქციას resolve() IP მისამართის მისაღებად.

ამ ეტაპზე, ჩვენ ვიწყებთ WebRTC ხელის ჩამორთმევას, თუ ორი თანატოლი ჯერ არ არის დაკავშირებული ერთმანეთთან. ერთიდაიგივე თანატოლის სხვადასხვა პორტებთან კავშირები იყენებს იმავე WebRTC DataChannel-ს.

ჩვენ ასევე ვასრულებთ არაპირდაპირ bind()რათა სერვერმა შეძლოს ხელახლა დაკავშირება შემდეგში sendto() თუ რაიმე მიზეზით დაიხურა.

სერვერს ეცნობება კლიენტის კავშირის შესახებ, როდესაც კლიენტი წერს თავის SDP შეთავაზებას სერვერის პორტის ინფორმაციის ქვეშ Firebase-ში და სერვერი პასუხობს იქ თავისი პასუხით.

ქვემოთ მოცემული დიაგრამა გვიჩვენებს შეტყობინებების ნაკადის მაგალითს სოკეტის სქემისთვის და პირველი შეტყობინების გადაცემა კლიენტიდან სერვერზე:

კლიენტსა და სერვერს შორის კავშირის ფაზის სრული დიაგრამა

დასკვნა

თუ აქამდე წაიკითხეთ, ალბათ გაინტერესებთ თეორიის მოქმედებაში დანახვა. თამაშის თამაში შესაძლებელია teeworlds.leaningtech.com, სცადე!

ამხანაგური მატჩი კოლეგებს შორის

ქსელის ბიბლიოთეკის კოდი თავისუფლად არის ხელმისაწვდომი აქ Github. შეუერთდით საუბარს ჩვენს არხზე: Gitter!

წყარო: www.habr.com