Signalisatsioon on tihedalt seotud meie soketite elluviimisega, mis on kirjeldatud j\u00e4rgmises jaotises.<\/li>\n<\/ul>\n\n![\"Kandime](\"\/wp-content\/uploads\/2019\/09\/5e30bc22643f8baecf850053bf69e130.jpg\")
\nServerite loetelu m\u00e4ngus ja kodulehel<\/i><\/p>\nSokettide elluviimine<\/h1>\n
\nSoovime luua API, mis on v\u00f5imalikult l\u00e4hedane Posix UDP soketitele, et minimeerida vajalike muudatuste hulka.<\/p>\n
Samuti soovime rakendada minimaalset, mis on vajalik lihtsaimaks andmevahetuseks \u00fcle v\u00f5rgu.<\/p>\n
N\u00e4iteks ei vaja me t\u00f5elist marsruutimist: k\u00f5ik peers asuvad \u00fches \"virtuaalses LANis\", mis on seotud konkreetse Firebase andmebaasi instantsiga.<\/p>\n
Seet\u00f5ttu ei vaja me ainulaadseid IP-aadresse: piisab, kui kasutada peerside unikaalsete Firebase v\u00f5tmearvude (sarnane domeeninimedele) p\u00f5hjal ainulaadset tuvastamist ning iga peer m\u00e4\u00e4rab iga v\u00f5tme jaoks kohalikult \"vale\" IP-aadressi, mille tuleb teisendada. See vabastab meid t\u00e4ielikult globaalsete IP-aadresside m\u00e4\u00e4ramise vajadusest, mis on mitte trivialne \u00fclesanne.<\/p>\n
Siin on minimaalne API, mille 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 sokettide APIle, kuid tal on m\u00f5ned olulised erinevused: tagasikutsumise registreerimine, kohalike IP-de m\u00e4\u00e4ramine ja \"liskontakt\"<\/strong>.<\/p>\nTagasikutsumise registreerimine<\/h2>\n
\nIeven kui algne programm kasutab mittesaggivat sisend-v\u00e4ljundit, tuleb koodi veebibrauseris k\u00e4ivitamiseks refaktoreerida.<\/p>\n
Selle p\u00f5hjuseks on see, et brauseri s\u00fcndmuste ts\u00fckkel on programmilt varjatud (olgu see siis JavaScript v\u00f5i WebAssembly).<\/p>\n
Kohalikus keskkonnas saame kirjutada koodi 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) \/\/ ei rohkem andmeid saadaval\n break;\n ...\n }\n ...\n}<\/code><\/pre>\n\nKui s\u00fcndmuste ts\u00fckkel on meie jaoks varjatud, tuleb see muuta millekski selliseks:<\/p>\n
auto cb = []() { \/\/ see kutsub v\u00e4lja, kui uus teave on saadaval\n while(true) {\n int r = readfrom(...); \/\/ proovi lugeda\n if (r < 0 && errno == EWOULDBLOCK) \/\/ ei rohkem andmeid saadaval\n break;\n ...\n }\n ...\n};\nrecvCallback(cb); \/\/ registreeri tagasikutsumine<\/code><\/pre>\n<\/p>\n
Kohalike IP-de m\u00e4\u00e4ramine<\/h2>\n
\nS\u00f5lmide identifikaatorid meie \"v\u00f5rgus\" ei ole IP-aadressid, vaid Firebase'i v\u00f5tmed (need on stringid, mis n\u00e4evad v\u00e4lja nii: -LmEC50PYZLCiCP-vqde<\/code> ).<\/p>\nSee on mugav, kuna me ei vaja mehhanismi IP-de m\u00e4\u00e4ramiseks ja nende unikaalsuse kontrollimiseks (ka nende utiliseerimine p\u00e4rast kliendi v\u00e4ljal\u00fclitamist), kuid sageli on vajalik s\u00fcnkroniseerida peer'e numbrilise v\u00e4\u00e4rtuse j\u00e4rgi.<\/p>\n
Just selleks kasutatakse funktsioone resolve<\/code> ja reverseResolve<\/code>: rakendus saab somehow stringi v\u00f5tme v\u00e4\u00e4rtuse (kasutaja sisendi v\u00f5i meister-serveri kaudu) ja suudab selle sisendada IP-aadressiks sisemiselt kasutamiseks. Puuduvad ka API teised osad selle lihtsuse huvides saavad selle v\u00e4\u00e4rtuse stringi asemel.<\/p>\nSee meenutab DNS-i otsingut, ainult et see toimub kliendi kohapeal.<\/p>\n
Teisis\u00f5nu, IP-aadresse ei saa jagada erinevate klientide vahel, ja kui on vajalik mingi globaalne identifikaator, siis tuleb see genereerida muul viisil.<\/p>\n
Laine\u00fchendus<\/h2>\n
\nUDP ei vaja \u00fchendust, kuid nagu oleme n\u00e4inud, peab WebRTC enne kahe peer'i andmevahetuse alustamist l\u00e4bi viima pika \u00fchendamisprotsessi.<\/p>\n
Kui soovime tagada sama abstraktsiooni taseme, (sendto<\/code>\/recvfrom<\/code> suvaliste peer'idega eelneva \u00fchendamiseta), siis peame API-s l\u00e4bi viima \"laisk\" (edasi l\u00fckatud) \u00fchendamise.<\/p>\nNii toimub tavap\u00e4rane andmevahetus \"serveri\" ja \"kliendi\" vahel UDP kasutamisel ning mida peab meie teek t\u00e4itma:<\/p>\n
\n- Server kutsub \u00fcles
bind()<\/code>, et teavitada operatsioonis\u00fcsteemi, et soovib saada pakette m\u00e4\u00e4ratud sadamasse.<\/li>\n<\/ul>\n\nSelle asemel avaldame Firebase'is avatud sadama serveri v\u00f5tme all ja kuulame selle aladressi s\u00fcndmusi.<\/p>\n
\n- Server kutsub \u00fcles
recvfrom()<\/code>, v\u00f5ttes vastu pakette, mis tulevad mistahes hostilt selle sadama sisse.<\/li>\n<\/ul>\n\nMeie juhul peame kontrollima sissetulevate pakettide j\u00e4rjekorda, mis on saadetud sellele sadamale.<\/p>\n
Igal sadamal on oma j\u00e4rjekord, ja me lisame WebRTC datagrammidesse alg- ja l\u00f5ppsadama, et teada, kuhu suunata uus pakk, kui see saabub.<\/p>\n
Kutse on mittesurmav, seega kui pakette ei ole, siis tagastame lihtsalt -1 ja seadistame errno=EWOULDBLOCK<\/code>.<\/p>\n\n- Klient saab mitmete v\u00e4liste vahendite kaudu serveri IP ja sadama ning kutsub v\u00e4lja
sendto()<\/code>. Samuti tehakse sisemine kutse bind()<\/code>, seega j\u00e4rgnev recvfrom()<\/code> saab vastuse ilma selge 'bind' teostamiseta.<\/li>\n<\/ul>\n\nKliendile antakse stringi v\u00f5ti ja kasutatakse funktsiooni resolve()<\/code> IP-aadressi saamiseks.<\/p>\nSellel etapil alustame WebRTC \"k\u00e4epigistust\", kui kaks peer'it ei ole veel omavahel \u00fchendatud. Erinevatele pordile \u00fchendused kasutavad sama WebRTC DataChannel'i.<\/p>\n
Samuti teeme kaudse bind()<\/code>, et server saaks \u00fchenduse j\u00e4rgmisel korral taastada, sendto()<\/code> kui see mingil p\u00f5hjusel suleti.<\/p>\nServer saab teate kliendi \u00fchendusest, kui klient salvestab oma SDP pakkumise serveri sadama teabe alla Firebase'is ning server vastab seal samas oma vastusega.<\/p>\n
\nAlloleval skeemil on n\u00e4idatud s\u00f5numite liikumise n\u00e4ide soketite skeemi ja esimesed s\u00f5numid kliendilt serverisse edastamisel:<\/p>\n
![\"Kandime](\"\/wp-content\/uploads\/2019\/09\/7dc48e816c09e33daf28c307cad0c258.jpg\")
\nT\u00e4ielik \u00fchenduse loomise etapi skeem kliendi ja serveri vahel<\/i><\/p>\nKokkuv\u00f5te<\/h1>\n
\nKui olete l\u00f5puni lugenud, siis ilmselt huvitab teid teooria praktikas. M\u00e4ngu saab m\u00e4ngida aadressil