Come funziona la comunicazione tra un server di chat e un client?

Non so come funzionano di solito , ma quando ne ho implementato uno, ho scelto il tuo primo approccio e ha funzionato bene. Questo è anche il modo in cui IRC funziona, quindi può essere ridimensionato in modo adeguato a un numero ragionevole di utenti.

Se stai aprendo un nuovo socket per ogni messaggio, ci sarebbe un problema in termini di come il server invia messaggi ai client, che potrebbero trovarsi dietro ai firewall e incapaci di accettare le confezioni in entrata. Il polling è possibile e so che alcuni dei primi clienti di chat web hanno fatto questo, ma credo che questo approccio sia ora molto raro.

Una terza opzione sta usando UDP, dove il costo di mantenere un socket aperto è inferiore (perché non c'è alcuna connessione di cui si debba mantenere lo stato). Non so se alcuni sistemi di chat popolari lo facciano comunque.

Un'immagine da IBM , dove puoi trovare anche informazioni utili:

Di seguito c'è una semplice spiegazione di come funzionano i socket (quindi molto di più sta accadendo durante, ma ho scoperto solo le parti di base)

Un server definisce un socket e associa un indirizzo IP e una porta ad esso. Se l'associazione ha esito positivo, inizia ad ascoltare quel socket per le connessioni in entrata. Un client invia una richiesta di connessione all'IP e alla porta correlati e il server socket che ascolta quella porta lo accetta. Dopo che il server accetta una richiesta client, viene stabilita una connessione.

È possibile inviare e ricevere dati tramite tale connessione (passaggio 5, 6) mentre la connessione è attiva. Se la connessione client è chiusa, il server deve accettarlo nuovamente (passaggio 4). Il passo accept viene eseguito una volta per ogni nuova connessione e tale connessione non deve essere accettata nuovamente mentre era attiva.

Un server dovrebbe avere un IP e una porta specifici in modo che il client possa collegarlo. Un server non è in grado di connettersi a un client poiché il client non ha alcun socket associato a un IP e una porta specifici per l'ascolto delle connessioni in ingresso.

------------        ----------       ------------
| Client 1 | -----> | Server | <---  | Client 2 |
------------        ----------       ------------

Client 1 invia un messaggio, il messaggio dovrebbe essere ricevuto dal server poiché solo servers può accept connessioni (quindi, un client non può stabilire una connessione con un altro client poiché un altro client non può accettare alcuna connessione in ingresso ). Il server riceve il messaggio e lo invia a client 2 Poiché un server non è in grado di stabilire una connessione con un client, Client 2 deve essere già connesso. Altrimenti il server dovrebbe attendere il client 2 per stabilire una connessione in modo che possa inviare dati.

Da quel punto di vista, tutti i client dovrebbero essere connessi al server e mantenere attive tali connessioni. Un Client potrebbe avere una connessione attiva mentre stava comunicando e chiudere quella connessione per un po 'di tempo dopo che era inattiva per un tempo specifico. Ma il client deve stabilire connessioni al server e controlla se ha dati in attesa di essere trasferito a se stesso. Quindi mantenere la connessione attiva sembra un approccio migliore.

Esistono protocolli come TCP e UDP e si definisce il socket come socket TCP o UDP. Ma questi protocolli hanno molti dettagli e per semplicità, posso ricordare che il protocollo TCP è controllato da errori e controlla se i dati inviati sono ricevuti dall'applicazione ricevente (i servizi di messaggistica istantanea ti hanno detto se il tuo messaggio è stato inviato o meno, quindi questo è TCP). UDP non ha un meccanismo di controllo degli errori (quindi si invia semplicemente il pacchetto ma non si conferma se è consegnato o meno).