Sygnalizacja jest \u015bci\u015ble zwi\u0105zana z nasz\u0105 implementacj\u0105 gniazd, opisan\u0105 w nast\u0119pnym rozdziale.<\/li>\n<\/ul>\n\nLista serwer\u00f3w w grze i na stronie g\u0142\u00f3wnej<\/i><\/p>\nImplementacja gniazd<\/h1>\n
\nChcemy stworzy\u0107 API jak najbli\u017csze do gniazd Posix UDP, aby zminimalizowa\u0107 ilo\u015b\u0107 wymaganych zmian.<\/p>\n
Chcemy r\u00f3wnie\u017c zaimplementowa\u0107 minimalny zestaw funkcji wymaganych do najprostszej wymiany danych przez sie\u0107.<\/p>\n
Na przyk\u0142ad, nie potrzebujemy prawdziwego routingu: wszystkie w\u0119z\u0142y znajduj\u0105 si\u0119 w jednej \"wirtualnej LAN\", po\u0142\u0105czonej z konkretnym egzemplarzem bazy danych Firebase.<\/p>\n
W zwi\u0105zku z tym nie potrzebujemy unikalnych adres\u00f3w IP: do unikalnej identyfikacji w\u0119z\u0142\u00f3w wystarcz\u0105 unikalne warto\u015bci kluczy Firebase (analogicznie do nazw domen), a ka\u017cdy w\u0119ze\u0142 lokalnie przypisuje \"fa\u0142szywe\" adresy IP do ka\u017cdego klucza, kt\u00f3ry wymaga konwersji. Ca\u0142kowicie eliminuje to potrzeb\u0119 globalnego przypisywania adres\u00f3w IP, co jest zadaniem nie\u0142atwym.<\/p>\n
Oto minimalne API, kt\u00f3re musimy zaimplementowa\u0107:<\/p>\n
\/\/ Create and destroy a socket\nint socket();\nint close(int fd);\n\/\/ Bind a socket to a port, and publish it on Firebase\nint bind(int fd, AddrInfo* addr);\n\/\/ Send a packet. This lazily create a WebRTC connection to the \n\/\/ peer when necessary\nint sendto(int fd, uint8_t* buf, int len, const AddrInfo* addr);\n\/\/ Receive the packets destined to this socket\nint recvfrom(int fd, uint8_t* buf, int len, AddrInfo* addr);\n\/\/ Be notified when new packets arrived\nint recvCallback(Callback cb);\n\/\/ Obtain a local ip address for this peer key\nuint32_t resolve(client::String* key);\n\/\/ Get the peer key for this ip\nString* reverseResolve(uint32_t addr);\n\/\/ Get the local peer key\nString* local_key();\n\/\/ Initialize the library with the given Firebase database and \n\/\/ WebRTc connection options\nvoid init(client::FirebaseConfig* fb, client::RTCConfiguration* ice);<\/code><\/pre>\n\nAPI jest proste i podobne do API gniazd Posix, ale ma kilka istotnych r\u00f3\u017cnic: rejestracja wywo\u0142a\u0144 zwrotnych, przypisanie lokalnych adres\u00f3w IP i \u201eleniwe\u201d \u0142\u0105czenie<\/strong>.<\/p>\nRejestracja wywo\u0142a\u0144 zwrotnych<\/h2>\n \nNawet je\u015bli oryginalny program u\u017cywa asynchronicznego wej\u015bcia-wyj\u015bcia, aby uruchomi\u0107 go w przegl\u0105darce, kod musi zosta\u0107 zrefaktoryzowany.<\/p>\n
Powodem tego jest to, \u017ce p\u0119tla zdarze\u0144 w przegl\u0105darce jest ukryta przed programem (czy to JavaScript, czy WebAssembly).<\/p>\n
W \u015brodowisku natywnym mo\u017cemy pisa\u0107 kod w ten spos\u00f3b<\/p>\n
while(running) {\n select(...); \/\/ czekaj na zdarzenia I\/O\n while(true) {\n int r = readfrom(...); \/\/ pr\u00f3buj odczyta\u0107\n if (r < 0 && errno == EWOULDBLOCK) \/\/ nie ma wi\u0119cej dost\u0119pnych danych\n break;\n ...\n }\n ...\n}<\/code><\/pre>\n\nJe\u015bli p\u0119tla zdarze\u0144 jest dla nas ukryta, to musimy przekszta\u0142ci\u0107 j\u0105 w co\u015b podobnego:<\/p>\n
auto cb = []() { \/\/ to zostanie wywo\u0142ane, gdy nowe dane b\u0119d\u0105 dost\u0119pne\n while(true) {\n int r = readfrom(...); \/\/ pr\u00f3buj odczyta\u0107\n if (r < 0 && errno == EWOULDBLOCK) \/\/ nie ma wi\u0119cej dost\u0119pnych danych\n break;\n ...\n }\n ...\n};\nrecvCallback(cb); \/\/ zarejestruj wywo\u0142anie zwrotne<\/code><\/pre>\n<\/p>\n
Przypisanie lokalnych adres\u00f3w IP<\/h2>\n \nIdentyfikatory w\u0119z\u0142\u00f3w w naszej \"sieci\" nie s\u0105 adresami IP, lecz kluczami Firebase (s\u0105 to ci\u0105gi, kt\u00f3re wygl\u0105daj\u0105 tak: -LmEC50PYZLCiCP-vqde<\/code> ).<\/p>\nJest to wygodne, poniewa\u017c nie potrzebujemy mechanizmu do przydzielania adres\u00f3w IP i sprawdzania ich unikalno\u015bci (ani ich utylizacji po dezaktywacji klienta), ale cz\u0119sto konieczne jest identyfikowanie peer\u00f3w za pomoc\u0105 warto\u015bci numerycznej.<\/p>\n
W\u0142a\u015bnie dlatego u\u017cywa si\u0119 funkcji resolve<\/code> i reverseResolve<\/code>: aplikacja w jaki\u015b spos\u00f3b uzyskuje ci\u0105gowy klucz (poprzez wprowadzenie przez u\u017cytkownika lub za pomoc\u0105 serwera g\u0142\u00f3wnego) i mo\u017ce zamieni\u0107 go na adres IP do u\u017cytku wewn\u0119trznego. Pozosta\u0142a cz\u0119\u015b\u0107 API r\u00f3wnie\u017c dla uproszczenia otrzymuje zamiast tego warto\u015b\u0107 jako ci\u0105g.<\/p>\nPrzypomina to zapytanie DNS, ale odbywa si\u0119 lokalnie u klienta.<\/p>\n
Oznacza to, \u017ce adresy IP nie mog\u0105 by\u0107 wsp\u00f3\u0142dzielone przez r\u00f3\u017cnych klient\u00f3w, a je\u015bli potrzebny jest jaki\u015b globalny identyfikator, trzeba go wygenerowa\u0107 w inny spos\u00f3b.<\/p>\n
Leniwe po\u0142\u0105czenie<\/h2>\n \nUDP nie wymaga po\u0142\u0105czenia, ale, jak widzieli\u015bmy, przed rozpocz\u0119ciem przesy\u0142ania danych mi\u0119dzy dwoma peerami, WebRTC wymaga d\u0142ugiego procesu nawi\u0105zywania po\u0142\u0105czenia.<\/p>\n
Je\u015bli chcemy zapewni\u0107 ten sam poziom abstrakcji, (sendto<\/code>\/recvfrom<\/code> z dowolnymi peerami bez wcze\u015bniejszego po\u0142\u0105czenia), musimy wykona\u0107 \u201eleniwe\u201d (od\u0142o\u017cone) po\u0142\u0105czenie wewn\u0105trz API.<\/p>\nOto, co si\u0119 dzieje podczas zwyk\u0142ej wymiany danych mi\u0119dzy \u201eserwerem\u201d a \u201eklientem\u201d w przypadku u\u017cycia UDP i co musi zrobi\u0107 nasza biblioteka:<\/p>\n
\nSerwer wywo\u0142uje bind()<\/code>, aby poinformowa\u0107 system operacyjny, \u017ce chce otrzymywa\u0107 pakiety na okre\u015blonym porcie.<\/li>\n<\/ul>\n\nZamiast tego opublikujemy otwarty port w Firebase pod kluczem serwera i b\u0119dziemy nas\u0142uchiwa\u0107 zdarze\u0144 w jego poddrzewie.<\/p>\n
\nSerwer wywo\u0142uje recvfrom()<\/code>, odbieraj\u0105c na ten port pakiety przychodz\u0105ce z dowolnego hosta.<\/li>\n<\/ul>\n\nW naszym przypadku nale\u017cy sprawdza\u0107 kolejk\u0119 przychodz\u0105cych pakiet\u00f3w wysy\u0142anych na ten port.<\/p>\n
Ka\u017cdy port ma swoj\u0105 w\u0142asn\u0105 kolejk\u0119, a my dodajemy na pocz\u0105tku datagram\u00f3w WebRTC porty \u017ar\u00f3d\u0142owy i docelowy, aby wiedzie\u0107, do kt\u00f3rej kolejki przekierowa\u0107 nowy pakiet przy jego przybyciu.<\/p>\n
Wywo\u0142anie jest nieblokuj\u0105ce, dlatego je\u015bli nie ma pakiet\u00f3w, po prostu zwracamy -1 i ustawiamy errno=EWOULDBLOCK<\/code>.<\/p>\n\nKlient uzyskuje w jaki\u015b spos\u00f3b IP i port serwera z zewn\u0119trznych \u017ar\u00f3de\u0142 i wywo\u0142uje sendto()<\/code>. R\u00f3wnocze\u015bnie wykonywane jest wewn\u0119trzne wywo\u0142anie bind()<\/code>, dlatego p\u00f3\u017aniejszy recvfrom()<\/code> otrzyma odpowied\u017a bez jawnego wykonywania bind.<\/li>\n<\/ul>\n\nW naszym przypadku klient otrzymuje zewn\u0119trzny klucz tekstowy i korzysta z funkcji resolve()<\/code> w celu uzyskania adresu IP.<\/p>\nNa tym etapie rozpoczynamy \u201eu\u015bcisk d\u0142oni\u201d WebRTC, je\u015bli dwa peer-y jeszcze si\u0119 ze sob\u0105 nie po\u0142\u0105czy\u0142y. Po\u0142\u0105czenia na r\u00f3\u017cnych portach jednego peer-a korzystaj\u0105 z tego samego DataChannel WebRTC.<\/p>\n
Wykonujemy r\u00f3wnie\u017c po\u015bredni bind()<\/code>, aby serwer m\u00f3g\u0142 przywr\u00f3ci\u0107 po\u0142\u0105czenie w nast\u0119pnym sendto()<\/code> na wypadek, gdyby z jakiego\u015b powodu si\u0119 ono zamkn\u0119\u0142o.<\/p>\nSerwer jest powiadamiany o po\u0142\u0105czeniu klienta, gdy klient zapisuje swoj\u0105 ofert\u0119 SDP pod informacj\u0105 o porcie serwera w Firebase, a serwer tam r\u00f3wnie\u017c odpowiada swoj\u0105 odpowiedzi\u0105.<\/p>\n
\nNa poni\u017cszym schemacie pokazano przyk\u0142ad ruchu wiadomo\u015bci dla schematu socket\u00f3w i przesy\u0142ania od klienta do serwera pierwszej wiadomo\u015bci:<\/p>\n
Pe\u0142ny schemat etapu po\u0142\u0105czenia mi\u0119dzy klientem a serwerem.<\/i><\/p>\nPodsumowanie<\/h1>\n
\nJe\u015bli dotar\u0142e\u015b do ko\u0144ca, zapewne jeste\u015b ciekaw teorii w dzia\u0142aniu. Mo\u017cesz zagra\u0107 w gr\u0119 na teeworlds.leaningtech.com<\/a><\/noindex>, spr\u00f3buj!<\/p>\n