Signaalimine on tihedalt seotud meie soklite rakendusega, mida kirjeldatakse j\u00e4rgmises jaotises.<\/li>\n<\/ul>\n\n![\"Kandideerime](\"\/wp-content\/uploads\/2019\/09\/5e30bc22643f8baecf850053bf69e130.jpg\")
\nServerite loend m\u00e4ngus ja avalehel<\/i><\/p>\nSoklite rakendamine<\/h1>\n
\nSoovime luua API, mis oleks v\u00f5imalikult l\u00e4hedane Posix UDP sokkidele, et minimeerida vajalike muudatuste arvu.<\/p>\n
Samuti soovime rakendada vajalikku miinimumi, mis on vajalik k\u00f5ige lihtsama andmevahetuse jaoks \u00fcle v\u00f5rgu.<\/p>\n
N\u00e4iteks me ei vaja t\u00f5elist suunamist: k\u00f5ik peer\u2019id asuvad \u00fches \u201evirtuaalses LANis\u201c, mis on seotud konkreetse Firebase'i andmebaasi eksemplariga.<\/p>\n
Seet\u00f5ttu ei ole meil unikaalsed IP-aadressid vajalikud: piisab, kui kasutada unikaalseid Firebase v\u00f5tme v\u00e4\u00e4rtusi (sarnaselt domeeninimedele), ning iga peer m\u00e4\u00e4rab igale v\u00f5tmele kohalikult \"vale\" IP-aadressi, mida tuleb konverteerida. See vabastab meid globaalsete IP-aadresside m\u00e4\u00e4ramisest, mis on mitte triviaalne \u00fclesanne.<\/p>\n
Siin on minimaalne API, mille me peame rakendama:<\/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 on lihtne ja sarnaneb Posix Sockets API-le, kuid on mitmeid olulisi erinevusi: tagasikutsumiste registreerimine, kohalike IP-de m\u00e4\u00e4ramine ja \"laiska\" \u00fchendamine<\/strong>.<\/p>\nTagasikutsumiste registreerimine<\/h2>\n
\nIsegi kui algne programm kasutab mittesummutavat I\/O-d, tuleb kood veebibrauseris t\u00f6\u00f6tamiseks refaktoorida.<\/p>\n
Selle p\u00f5hjuseks on see, et brauseris on s\u00fcndmuste ts\u00fckkel programmist varjatud (\u00fcksk\u00f5ik kas see on JavaScript v\u00f5i WebAssembly).<\/p>\n
Kohalikus keskkonnas saame koodi kirjutada j\u00e4rgmiselt<\/p>\n
while(running) {\n select(...); \/\/ oota I\/O s\u00fcndmusi\n while(true) {\n int r = readfrom(...); \/\/ proovi lugeda\n if (r < 0 && errno == EWOULDBLOCK) \/\/ enam andmeid ei ole k\u00e4ttev\u00f5etav\n break;\n ...\n }\n ...\n}<\/code><\/pre>\n\nKui s\u00fcndmuste ts\u00fckkel on meie jaoks varjatud, tuleb see muuta millegi sarnaseks:<\/p>\n
auto cb = []() { \/\/ see this will be called when new data is available\n while(true) {\n int r = readfrom(...); \/\/ try to read\n if (r < 0 && errno == EWOULDBLOCK) \/\/ no more data available\n break;\n ...\n }\n ...\n};\nrecvCallback(cb); \/\/ register the callback<\/code><\/pre>\n<\/p>\n
Kohalikud IP-aadressid<\/h2>\n
\nMeie 'v\u00f5rgus' olevate s\u00f5lmede identifikaatorid ei ole IP-aadressid, vaid Firebase'i v\u00f5tmed (need on stringid, mis n\u00e4evad v\u00e4lja sellised: -LmEC50PYZLCiCP-vqde<\/code> ).<\/p>\nSee on mugav, sest me ei vaja mehhanismi IP-de m\u00e4\u00e4ramiseks ja nende unikaalsuse kontrollimiseks (samuti nende utiliseerimiseks p\u00e4rast kliendi lahti\u00fchendamist), kuid tihti on vajalik identifitseerida peer'e numbriliste v\u00e4\u00e4rtuste j\u00e4rgi.<\/p>\n
Just selle jaoks kasutatakse funktsioone resolve<\/code> ja reverseResolve<\/code>: rakendus saab t\u00f5lkida v\u00f5tme stringi v\u00e4\u00e4rtuse (kasutaja sisendi kaudu v\u00f5i master-serveri kaudu) ja v\u00f5ib selle sisemiselt IP-aadressiks muuta. API \u00fclej\u00e4\u00e4nud osa saab samuti selle v\u00e4\u00e4rtuse stringina, et lihtsustada kasutamist.<\/p>\nSee on sarnane DNS-otsingule, kuid toimub kliendi kohal.<\/p>\n
See t\u00e4hendab, et IP-aadressid ei saa olla erinevate klientide jaoks \u00fchised ja kui on vajalik mingi globaalne identifikaator, tuleb see genereerida muul viisil.<\/p>\n
Laisk \u00fchendus<\/h2>\n
\nUDP ei n\u00f5ua \u00fchendust, kuid nagu me oleme n\u00e4inud, enne andmete edastamise alustamist kahe peer'i vahel n\u00f5uab WebRTC pikka \u00fchendusprotsessi.<\/p>\n
Kui soovime tagada sama abstraktsiooni taseme, (sendto<\/code>\/recvfrom<\/code> ilma eelneva \u00fchenduseta juhuslike peer'idega), peame teostama \"laiska\" (edasil\u00fckatud) \u00fchendamist API sees.<\/p>\nNii toimub tavaline andmevahetus \"serveri\" ja \"kliendi\" vahel UDP kasutamisel ning mida peaks meie teek tegema:<\/p>\n
\n- Server kutsub v\u00e4lja
bind()<\/code>, et teavitada operatsioonis\u00fcsteemi soovist saada pakette m\u00e4\u00e4ratud porti.<\/li>\n<\/ul>\n\nSelle asemel avaldame Firebase'is avatud portaali serveri v\u00f5tme all ja kuulame s\u00fcndmusi selle alampuus.<\/p>\n
\n- Server kutsub v\u00e4lja
recvfrom()<\/code>, et v\u00f5tta vastu pakette, mis saadetakse sellele portile mistahes hostilt.<\/li>\n<\/ul>\n\nMeie puhul tuleb kontrollida sissetulevat pakettide j\u00e4rjekorda, mis on saadetud sellele portile.<\/p>\n
Igal pordil on oma j\u00e4rjekord ning me lisame WebRTC datagrammidele algusesse alg- ja l\u00f5pp-pordid, et teada, kuhu suunata uus pakett.<\/p>\n
V\u00e4ljakutse on mitteblokeeriv, seega, kui pakette pole, tagastame lihtsalt -1 ja m\u00e4\u00e4rame errno=EWOULDBLOCK<\/code>.<\/p>\n\n- Kliendil on v\u00e4liste allikate kaudu IP ja serveri port, ning ta kutsub
sendto()<\/code>. Samuti toimub see ajal sisemine kutse bind()<\/code>, seega j\u00e4rgnev recvfrom()<\/code> saab vastuse ilma selge bind-kutsumise protsessita.<\/li>\n<\/ul>\n\nMeie puhul saab klient v\u00e4liselt stringi v\u00f5tme ja kasutab funktsiooni resolve()<\/code> IP-aadresse saamiseks.<\/p>\nSelles etapis alustame WebRTC \"k\u00e4tlemist\", kui kaks peer-i veel ei ole \u00fcksteisega \u00fchendatud. \u00dchendused \u00fche peer-i erinevatele portidele kasutavad sama WebRTC DataChannelit.<\/p>\n
Me teostame ka kaudset bind()<\/code>, et server saaks j\u00e4rgmises sendto()<\/code> kui see mingil p\u00f5hjusel suletakse.<\/p>\nServerile antakse teada kliendi \u00fchendusest, kui klient salvestab oma SDP pakkumise serveri porti informatsiooniga Firebase'is, ja server vastab seal oma vastusega.<\/p>\n
\nAlltoodud skeemil on n\u00e4idatud s\u00f5numite liikumine socket-skeemi ja kliendi jaoks serveri esimese s\u00f5numi edastamine:<\/p>\n
![\"Kandideerime](\"\/wp-content\/uploads\/2019\/09\/7dc48e816c09e33daf28c307cad0c258.jpg\")
\nKliendi ja serveri vahelise \u00fchenduse etapi t\u00e4ielik skeem<\/i><\/p>\nKokkuv\u00f5te<\/h1>\n
\nKui olete l\u00f5puni lugenud, siis on teil ilmselt huvi n\u00e4ha teooriat praktikas. M\u00e4ngu saab m\u00e4ngida aadressil