Въведение

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

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

Работещата в браузера Teeworlds

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

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

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

Съществува и трети начин — да използваме мрежата от браузера: WebRTC.

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

Обаче с това свързана допълнителна трудност: преди двата пира WebRTC да могат да обменят данни, те трябва да преминат през относително сложна процедура на „рукопожатие“ за свързване, за което се изискват няколко трети страни (сигнален сървър и един или повече сървъри STUN/TURN).

В идеалния случай бихме искали да създадем мрежов 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, порт) за директен обмен на данни с хоста. Ако успее да изпълни задачата си, пирите могат да си обменят данни помежду си.
Traversal Using Relays around NAT (TURN) също се използва за заобикаляне на NAT, но прави това, пренасочвайки данни през прокси, видимо за двамата пири. Той добавя закъснение и е по-скъп за изпълнение в сравнение с STUN (тъй като се използва през цялата продължителност на връзката), но понякога е единствената възможна опция.
Interactive Connectivity Establishment (ICE) се използва за избор на най-добрия възможен начин за свързване на двама пира на база информация, получена при пряка връзка между пирите, както и информация, получена от многобройни STUN и TURN сървъри.
Session Description Protocol (SDP) е формат за описание на параметрите на свързване, като кандидати ICE, мултимедийни кодеци (в случая на аудио/видеоканал) и т.н. Един от пирите изпраща SDP предложение, а другият отговаря със SDP отговор. След това се създава канал.

За да създадат такава връзка, пирите трябва да съберат информацията, получена от STUN и TURN сървърите, и да я обменят помежду си.

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

Сигналният сървър може да бъде много прост, тъй като единствената му задача е да пренасочва данни между пирите в етапа на „поздравяване“ (както е показано на схемата по-долу).

Оптимизирана схема на последователността „поздравяване“ WebRTC

Преглед на мрежовия модел Teeworlds

Мрежовата архитектура на Teeworlds е много проста:

Компонентите на клиента и сървъра са две различни програми.
Клиентите влизат в играта, свързвайки се с един от няколкото сървъра, всеки от които хоства само една игра в даден момент.
Цялата предаване на данни в играта се извършва чрез сървъра.
Специален майстор-сървър се използва за събиране на списъка с всички публични сървъри, които се показват в игровия клиент.

Благодарение на използването на WebRTC за обмен на данни, можем да преместим сървърния компонент на играта в браузъра, където се намира клиентът. Това ни дава прекрасна възможност…

Да се отървем от сървърите

Липсата на сървърен логика има приятно предимство: можем да разположим цялото приложение като статично съдържание на Github Pages или на собственото си оборудване зад Cloudflare, осигурявайки си бързо зареждане и висока наличност безплатно. По същество, можем да забравим за тях, и ако имаме късмет и играта стане популярна, няма да е необходимо да модернизираме инфраструктурата.

Въпреки това, за да работи системата, ще трябва да използваме външна архитектура:

Един или повече STUN сървъра: имаме избор от няколко безплатни варианта.
Поне един TURN сървър: тук безплатни опции няма, така че можем или да настроим наш, или да плащаме за услуга. За щастие, по-голямата част от времето връзката може да бъде установена чрез STUN сървъри (и да осигури истински p2p), но TURN е необходим като резервен вариант.
Сигнален сървър: за разлика от другите два аспекта, сигнализирането не е стандартизирано. Какво точно ще отговаря сигналният сървър зависи донякъде от приложението. В нашия случай, преди установяване на връзката е необходимо да обменим малък обем данни.
Майстор-сървър Teeworlds: той се използва от други сървъри, за да уведомят за своето съществуване, и от клиентите, за да търсят публични сървъри. Въпреки че не е задължителен (клиентите винаги могат да се свържат ръчно с известен им сървър), би било добре да го има, за да могат играчите да участват в игри с непознати.

Решихме да използваме безплатните STUN сървъри на Google, а един TURN сървър разположихме самостоятелно.

За последните две точки използвахме Firebase:

Мастър-сървърът Teeworlds е реализиран много просто: като списък от обекти, съдържащи информация (име, IP, карта, режим и др.) за всеки активен сървър. Сървърите публикуват и актуализират собствените си обекти, а клиентите вземат целия списък и го показват на играча. Освен това, ние показваме списъка на началната страница като HTML, за да може играчът просто да кликне върху сървъра и директно да влезе в играта.
Сигналирането е тясно свързано с нашата реализация на сокетите, описана в следващия раздел.

Списък на сървърите в играта и на началната страница

Реализация на сокетите

Искаме да създадем API, колкото се може по-близо до Posix UDP сокети, за да минимизираме необходимите промени.

Също така искаме да реализираме необходимия минимум за най-простия обмен на данни по мрежата.

Например, не ни трябва истинска маршрутизация: всички пирове са в една "виртуална 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 сокети, но има няколко важни различия: регистрация на колбек функции, назначаване на локални IP адреси и "лениво" свързване.

Регистрация на колбек функции

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

Причината за това е, че цикълът на събития в браузъра е скрит от програмата (било то JavaScript или WebAssembly).

В родна среда можем да пишем код по следния начин

докато(работи) {
  select(...); // изчакайте I/O събития
  докато(истина) {
    int r = readfrom(...); // опитайте да прочетете
    if (r < 0 && errno == EWOULDBLOCK) // няма повече налични данни
      break;
    ...
  }
  ...
}

Ако цикълът на събития е скрит за нас, трябва да го преобразуваме в нещо подобно:

auto cb = []() { // това ще бъде извикано, когато нови данни са налични
  докато(истина) {
    int r = readfrom(...); // опитайте да прочетете
    if (r < 0 && errno == EWOULDBLOCK) // няма повече налични данни
      break;
    ...
  }
  ...
};
recvCallback(cb); // регистрирайте колбек функцията

Назначаване на локални 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, ако двата пира все още не са свързани помежду си. Връзките към различни портове на един и същ пир използват един и същ DataChannel WebRTC.

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

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

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

Пълна схема на етапа на свързване между клиента и сървъра.