въведение

нашата компания Наклонени технологии предоставя решения за пренасяне на традиционни настолни приложения към мрежата. Нашият C++ компилатор весели се генерира комбинация от WebAssembly и JavaScript, която предоставя и лесно взаимодействие с браузъра, и висока производителност.

Като пример за използването му решихме да пренесем мултиплейър игра за мрежата и избрахме Teeworlds. Teeworlds е ретро XNUMXD мултиплейър игра с малка, но активна общност от играчи (включително мен!). Малък е както по отношение на ресурсите за изтегляне, така и по отношение на изискванията за CPU и GPU – идеален кандидат.

Работи в браузъра Teeworlds

Решихме да използваме този проект, за да експериментираме общи решения за пренасяне на мрежов код към мрежата. Това обикновено се прави по следните начини:

• XMLHttpRequest/fetch, ако мрежовата част се състои само от HTTP заявки, или
• WebSockets.

И двете решения изискват хостване на сървърен компонент от страната на сървъра и нито едно от тях не позволява да се използва като транспортен протокол. UDP. Това е важно за приложения в реално време като софтуер за видеоконференции и игри, тъй като доставката на пакети и поръчката на протокола гарантира TCP може да попречи на ниската латентност.

Има и трети начин - да използвате мрежата от браузъра: WebRTC.

RTCDataChannel поддържа както надеждно, така и ненадеждно предаване (в последния случай се опитва да използва UDP като транспортен протокол, когато е възможно) и може да се използва както с отдалечен сървър, така и между браузъри. Това означава, че можем да пренесем цялото приложение към браузъра, включително сървърния компонент!

Това обаче идва с допълнителна трудност: преди два WebRTC партньора да могат да комуникират, те трябва да извършат сравнително сложно ръкостискане, за да се свържат, което изисква множество обекти на трети страни (сървър за сигнализиране и един или повече ЗАШЕМЕТЯВАНЕ/ВЪРВЕТЕ).

В идеалния случай бихме искали да създадем мрежов API, който използва вътрешно WebRTC, но е възможно най-близо до интерфейса на UDP Sockets, който не се нуждае от установяване на връзка.

Това ще ни позволи да се възползваме от WebRTC, без да се налага да излагаме сложни детайли на кода на приложението (който искахме да променим възможно най-малко в нашия проект).

Минимум WebRTC

WebRTC е набор от API, налични в браузърите за предаване на аудио, видео и произволни данни от тип peer-to-peer.

Връзката между партньорите се установява (дори ако има NAT от едната или двете страни) с помощта на STUN и/или TURN сървъри чрез механизъм, наречен ICE. Партньорите обменят ICE информация и параметри на канала чрез офертата и отговора на SDP протокола.

Еха! Колко съкращения наведнъж. Нека накратко обясним какво означават тези термини:

• Помощни програми за преминаване на сесия за NAT (ЗАШЕМЕТЯВАНЕ) - протокол за заобикаляне на 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: използва се от други сървъри за обявяване на съществуването му и от клиенти за намиране на публични сървъри. Въпреки че не е задължително (клиентите винаги могат да се свържат ръчно със сървър, който познават), би било хубаво да го има, за да могат играчите да играят игри с произволни хора.

Решихме да използваме безплатните STUN сървъри на Google и сами внедрихме един 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 е прост и подобен на API на Posix Sockets, но с няколко важни разлики: регистриране на обратно извикване, локално 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 присвояване

Идентификаторите на възлите в нашата „мрежа“ не са 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() ще получи отговора без изрично изпълнение на bind.

В нашия случай клиентът външно получава ключ от низ и използва функцията resolve() за да получите IP адрес.

В този момент започваме WebRTC ръкостискането, ако двамата партньори все още не са свързани един с друг. Връзките към различни портове на един и същи партньор използват един и същ WebRTC DataChannel.

Правим и индиректни bind()така че сървърът да може да се свърже отново след това sendto() в случай че се затвори по някаква причина.

Сървърът се уведомява за връзката на клиента, когато клиентът напише своята SDP оферта под информацията за порта на сървъра във Firebase и сървърът отговаря с отговора си и там.

Диаграмата по-долу показва пример за поток от съобщения за схемата на сокета и първото съобщение от клиента към сървъра:

Пълна диаграма на фазата на свързване между клиент и сървър

Заключение

Ако сте прочели до тук, може да ви е интересно да видите теорията в действие. Играта може да се играе на teeworlds.leaningtech.com, опитай!

Приятелски мач между колеги

Кодът на мрежовата библиотека е свободно достъпен на Github. Присъединете се към разговора в нашия канал решетка!

Източник: www.habr.com