La segnalazione \u00e8 strettamente correlata alla nostra implementazione dei socket, descritta nella sezione successiva.<\/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 simile possibile ai socket UDP Posix, per ridurre al minimo il numero di modifiche necessarie.<\/p>\n
Vogliamo anche implementare il minimo indispensabile necessario per il pi\u00f9 semplice scambio di dati in rete.<\/p>\n
Ad esempio, non abbiamo bisogno di una vera e propria instradamento: tutti i peer sono su una 'LAN virtuale' collegata a un'istanza specifica del database Firebase.<\/p>\n
Pertanto, non abbiamo bisogno di indirizzi IP unici: per l'identificazione univoca dei peer \u00e8 sufficiente utilizzare valori di chiave Firebase univoci (simile ai nomi di dominio), e ogni peer assegna localmente indirizzi IP 'falsi' a ciascuna chiave che deve essere trasformata. Questo ci libera completamente dalla necessit\u00e0 di assegnare indirizzi IP globali, il 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 socket Posix, 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 I\/O non bloccante, per l'esecuzione nel browser web il codice deve essere rifattorizzato.<\/p>\n
La ragione \u00e8 che il ciclo degli eventi nel browser \u00e8 nascosto al programma (sia esso JavaScript o WebAssembly).<\/p>\n
In 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, allora bisogna trasformarlo in qualcosa del genere:<\/p>\n
auto cb = []() { \/\/ questo verr\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 di IP locali<\/h2>\n \nGli identificatori dei nodi nella nostra \u00abrete\u00bb non sono indirizzi IP, ma chiavi Firebase (queste sono stringhe che sembrano cos\u00ec: -LmEC50PYZLCiCP-vqde<\/code> ).<\/p>\n\u00c8 comodo perch\u00e9 non abbiamo bisogno di un meccanismo per assegnare IP e verificarne l'unicit\u00e0 (e anche il loro smaltimento dopo la disconnessione del client), ma spesso \u00e8 necessario identificare i peer in base a un valore numerico.<\/p>\n
Questo \u00e8 esattamente ci\u00f2 per cui vengono utilizzate le funzioni resolve<\/code> e reverseResolve<\/code>: l'applicazione in qualche modo ottiene il valore stringa della chiave (tramite l'input dell'utente o un server master), e pu\u00f2 convertirlo in un indirizzo IP per utilizzo interno. Anche il resto dell'API per semplicit\u00e0 riceve invece questo valore al posto della stringa.<\/p>\nQuesto \u00e8 simile a una ricerca DNS, ma avviene localmente sul client.<\/p>\n
Cio\u00e8, gli indirizzi IP non possono essere condivisi tra diversi client, e se \u00e8 necessario un qualche identificatore globale, dovr\u00e0 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 trasmettere dati tra due peer, WebRTC richiede un lungo processo di connessione.<\/p>\n
Se vogliamo fornire lo stesso livello di astrazione, (sendto<\/code>\/recvfrom<\/code> a peer qualsiasi senza una connessione preliminare), dobbiamo eseguire una connessione \u00abpigra\u00bb (ritardata) all'interno dell'API.<\/p>\nEcco cosa accade durante uno scambio normale di dati tra un \u00abserver\u00bb e un \u00abclient\u00bb nel caso di utilizzo di 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 sotto la chiave del server e ascolteremo gli eventi nel suo sottoalbero.<\/p>\n
\nIl server chiama recvfrom()<\/code>, accettando su questa porta i pacchetti in arrivo da qualsiasi host.<\/li>\n<\/ul>\n\nNel nostro caso, \u00e8 necessario controllare la coda in ingresso dei pacchetti inviati a questa porta.<\/p>\n
Ogni porta ha la sua coda, e aggiungiamo all'inizio dei datagrammi WebRTC le porte sorgente e destinazione per sapere in quale coda reindirizzare quando arriva un nuovo pacchetto.<\/p>\n
La chiamata \u00e8 non bloccante, quindi se non ci sono pacchetti, restituiamo semplicemente -1 e impostiamo errno=EWOULDBLOCK<\/code>.<\/p>\n\nIl client ottiene tramite mezzi esterni l'IP e la porta del server e chiama sendto()<\/code>. Viene eseguita anche una chiamata interna, quindi il successivo bind()<\/code>ricever\u00e0 una risposta senza necessit\u00e0 di eseguire esplicitamente il bind. recvfrom()<\/code> ricever\u00e0 una risposta senza un'esecuzione esplicita del bind.<\/li>\n<\/ul>\n\nNel nostro caso, il cliente riceve esternamente una chiave in formato stringa e utilizza la funzione resolve()<\/code> per ottenere l'indirizzo IP.<\/p>\nA questo punto iniziamo il \"handshake\" di WebRTC, se i due peer non sono gi\u00e0 connessi tra loro. Le connessioni a porte diverse di un singolo peer utilizzano lo stesso DataChannel WebRTC.<\/p>\n
Inoltre, eseguiamo un'indiretta bind()<\/code>, in modo che il server possa ripristinare la connessione nel successivo sendto()<\/code> nel caso in cui essa si chiuda per qualche motivo.<\/p>\nIl server viene informato della connessione del cliente quando il cliente registra la sua offerta SDP sotto le informazioni sulla porta del server in Firebase, e il server risponde anch'esso con la sua risposta.<\/p>\n
\nNello schema mostrato qui sotto \u00e8 illustrato un esempio del flusso dei messaggi per lo schema dei socket e la trasmissione del primo messaggio dal cliente al server:<\/p>\n
Schema completo della fase di connessione tra cliente e server<\/i><\/p>\nConclusione<\/h1>\n
\nSe sei arrivato fino a qui, probabilmente ti interesser\u00e0 vedere la teoria in azione. Puoi giocare a teeworlds.leaningtech.com<\/a><\/noindex>, prova!<\/p>\n