La segnalazione \u00e8 strettamente legata alla nostra implementazione dei socket, descritta nel prossimo capitolo.<\/li>\n<\/ul>\n\nElenco dei server all'interno del gioco e sulla homepage<\/i><\/p>\nImplementazione dei socket<\/h1>\n
\nVogliamo creare un'API il pi\u00f9 vicina possibile ai socket UDP Posix, per ridurre al minimo le modifiche necessarie.<\/p>\n
Vogliamo anche implementare il minimo necessario richiesto per il pi\u00f9 semplice scambio di dati in rete.<\/p>\n
Ad esempio, non abbiamo bisogno di vera routing: tutti i peer si trovano all'interno di una 'LAN virtuale' collegata a una specifica istanza del database Firebase.<\/p>\n
Pertanto, non abbiamo bisogno di indirizzi IP unici: per la identificazione unica dei peer \u00e8 sufficiente utilizzare valori unici delle chiavi Firebase (simile ai nomi di dominio), e ogni peer assegna localmente degli indirizzi IP \"falsi\" a ciascuna chiave da convertire. Questo ci libera completamente dalla necessit\u00e0 di una assegnazione globale di indirizzi IP, che \u00e8 un compito non banale.<\/p>\n
Ecco l'API minima che dobbiamo implementare:<\/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\nL'API \u00e8 semplice e simile all'API dei Posix Sockets, ma presenta alcune differenze importanti: registrazione dei callback, assegnazione di IP locali e connessione \"pigra\"<\/strong>.<\/p>\nRegistrazione dei callback<\/h2>\n \nAnche se il programma originale utilizza input\/output non bloccante, il codice deve essere rifattorizzato per l'esecuzione nel browser.<\/p>\n
La ragione \u00e8 che il ciclo degli eventi nel browser \u00e8 nascosto al programma (che sia JavaScript o WebAssembly).<\/p>\n
Nell'ambiente nativo, possiamo scrivere il codice in questo modo<\/p>\n
while(running) {\n select(...); \/\/ aspetta eventi I\/O\n while(true) {\n int r = readfrom(...); \/\/ prova a leggere\n if (r < 0 && errno == EWOULDBLOCK) \/\/ non ci sono pi\u00f9 dati disponibili\n break;\n ...\n }\n ...\n}<\/code><\/pre>\n\nSe il ciclo degli eventi \u00e8 nascosto per noi, dobbiamo trasformarlo in qualcosa di simile:<\/p>\n
auto cb = []() { \/\/ questo sar\u00e0 chiamato quando sono disponibili nuovi dati\n while(true) {\n int r = readfrom(...); \/\/ prova a leggere\n if (r < 0 && errno == EWOULDBLOCK) \/\/ non ci sono pi\u00f9 dati disponibili\n break;\n ...\n }\n ...\n};\nrecvCallback(cb); \/\/ registra il callback<\/code><\/pre>\n<\/p>\n
Assegnazione degli IP locali<\/h2>\n \nGli identificatori dei nodi nella nostra \"rete\" non sono indirizzi IP, ma chiavi Firebase (sono stringhe che appaiono cos\u00ec: -LmEC50PYZLCiCP-vqde<\/code> ).<\/p>\nQuesto \u00e8 comodo, perch\u00e9 non abbiamo bisogno di un meccanismo per assegnare IP e controllarne l'unicit\u00e0 (cos\u00ec come per la loro dismissione dopo la disconnessione del cliente), ma spesso \u00e8 necessario identificare i peer tramite un valore numerico.<\/p>\n
\u00c8 proprio per questo che vengono utilizzate le funzioni resolve<\/code> e reverseResolve<\/code>: l'applicazione ottiene in qualche modo un valore stringa della chiave (attraverso l'immissione dell'utente o tramite un server principale) e pu\u00f2 convertirlo in un indirizzo IP per uso interno. Il resto dell'API riceve anche per semplicit\u00e0 questo valore al posto della stringa.<\/p>\n\u00c8 simile a una ricerca DNS, solo che viene eseguita localmente sul client.<\/p>\n
Cio\u00e8, gli indirizzi IP non possono essere condivisi tra diversi clienti, e se \u00e8 necessario un identificatore globale, allora deve essere generato in un altro modo.<\/p>\n
Connessione pigra<\/h2>\n \nUDP non richiede una connessione, ma, come abbiamo visto, prima di iniziare a trasferire dati tra due peer, WebRTC richiede un lungo processo di connessione.<\/p>\n
Se vogliamo garantire lo stesso livello di astrazione, (sendto<\/code>\/recvfrom<\/code> con peer casuali senza una connessione preliminare), dobbiamo eseguire una connessione \u00abpigra\u00bb (ritardata) all'interno dell'API.<\/p>\nEcco cosa accade durante uno scambio di dati normale tra un \u00abserver\u00bb e un \u00abclient\u00bb quando si utilizza UDP, e cosa deve fare la nostra libreria:<\/p>\n
\nIl server chiama bind()<\/code>, per informare il sistema operativo che desidera ricevere pacchetti sulla porta specificata.<\/li>\n<\/ul>\n\nInvece, pubblicheremo una porta aperta in Firebase con la chiave del server e ascolteremo gli eventi nel suo sottoalbero.<\/p>\n
\nIl server chiama recvfrom()<\/code>, accettando in questa porta pacchetti provenienti da qualsiasi host.<\/li>\n<\/ul>\n\nNel nostro caso, dobbiamo controllare la coda dei pacchetti in arrivo inviati a questa porta.<\/p>\n
Ogni porta ha la sua coda, e noi aggiungiamo in testa ai datagrammi WebRTC le porte sorgente e destinazione, per sapere in quale coda deviare il nuovo pacchetto al suo arrivo.<\/p>\n
La chiamata \u00e8 non bloccante, quindi se non ci sono pacchetti, restituiamo semplicemente -1 e poniamo errno=EWOULDBLOCK<\/code>.<\/p>\n\nIl client ottiene l'IP e la porta del server tramite mezzi esterni e invoca sendto()<\/code>. Viene inoltre effettuata una chiamata interna bind()<\/code>, quindi la successiva recvfrom()<\/code> ricever\u00e0 una risposta senza un'esplicita esecuzione di bind.<\/li>\n<\/ul>\n\nNel nostro caso, il client ottiene esternamente una chiave in formato stringa e utilizza la funzione resolve()<\/code> per ottenere l'indirizzo IP.<\/p>\nA questo punto, iniziamo il \u00abhandshake\u00bb WebRTC, se i due peer non sono gi\u00e0 connessi tra loro. Le connessioni a porte diverse dello stesso peer utilizzano lo stesso DataChannel WebRTC.<\/p>\n
Inoltre, eseguiamo un collegamento indiretto bind()<\/code>, affinch\u00e9 il server possa ripristinare la connessione nel caso in cui questa si fosse chiusa per qualche motivo. sendto()<\/code> Il server viene informato della connessione del client quando il client registra la propria offerta SDP sotto le informazioni sulla porta del server in Firebase e il server risponde con la propria risposta.<\/p>\nNello schema mostrato di seguito \u00e8 illustrato un esempio del flusso dei messaggi per lo schema dei socket e la trasmissione del primo messaggio dal client al server:<\/p>\n
\nSchema completo della fase di connessione tra client e server<\/p>\n
Se sei arrivato fino a qui, probabilmente sei curioso di vedere la teoria in azione. Puoi giocare su<\/i><\/p>\nConclusione<\/h1>\n
\nteeworlds.leaningtech.com , prova!<\/a><\/noindex>, prova!<\/p>\n