Въведение

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

Като пример за прилагането му решихме да портим многопользователска игра за уеб и избрахме за това Teeworlds. Teeworlds е многопользователска двумерна ретро игра с малко, но активно общество от играчи (включително и мен!). Тя е малка както по отношение на изтегляне на ресурси, така и по искания към ЦП и 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 и параметри на каналите чрез offer и answer протокола 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 Offer („предложение“), а вторият отговаря с SDP Answer („отговор“). След това се създава канал.

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

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

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

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

Преглед на мрежовата архитектура на Teeworlds

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

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

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

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

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

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

Един или повече 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 адреси и „лениво“ свързване.

Регистриране на обратно извикване

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

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

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

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

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

auto cb = []() { // това ще бъде извикано, когато нови данни са налични
  while(true) {
    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()ще получи отговор без явното извършване на bind. recvfrom() ще получи отговор без явното изпълнение на bind.

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

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

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

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

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

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