John23 ha scritto:
Forse non riesco a spiegarmi come vorrei, ora ho una chat cosi composta:
Allora, lo so che "farà male", ma alta concorrenza e java non vanno d'accordo, nel senso che "nel mondo normale" difficilmente si usa java per questa tipologia di problemi (non perchè java in sè abbia qualcosa di male, è solo che è pesantissimo rispetto a soluzioni senza JVM)
Edit: intendo "altissima concorrenza", quindi è un giudizio tecnico, non di tipo "religioso", e dò per scontato che sia chiaro il perchè.
Lato client (2 thread):
-Thread1--> apertura socket verso server, while(true){invio messaggi al server }
-Thread2-->while(true){ lettura messaggi ricevuti dal server e stampa a video}
Scritto così è busy waiting: cioè il processo client continua a testare all'infinito l'arrivo di un messaggio dal server
Lato server:
Viene creata una nuova Thread per ogni connessione e esegue :
Come giustamente segnalato un thread (java poi) è assolutamente troppo pesante per una gestione ragionevolmente scalabile
Il problema è che il Server con ad esempio 100.000 utenti connessi dovrebbe aprire e mantenere sul server 100.000 Thread, quindi vorrei trovare una implementazione alternativa per diminuire il carico di lavoro sul server.
Semplice, ti basta un singolo thread server (o magari diciamo 4-8 se riesci [cosa che non credo proprio, ma non sono così esperto di java] un'affinità per eventuali CPU fisiche) perchè vuoi farne tanti?
L'unica implementazione che mi viene in mente è quella in cui ho 2 Server e ogni utente viene connesso a uno di questi due server con un load balancer.
Lascerei perdere, decisamente, una suddivisione siffatta.
Se pensi al meccanismo di base di nginx e apache vedi come il primo è enormemente più "leggero" del secondo proprio quando ci sono fork massivi.
Quindi di fatto non è l'implementazione più adatta, quale adottare?
La risposta "giusta" è... skype.
Cioè un client monolitico eseguibile (niente java) che colloquia con uno (o più server) specifici, a loro volta monolitici (niente java)
Mi rendo conto di non aver chiesto a priori se stai facendo una chat web oppure no.
Riguardo il discorso 1-client<=>1 porta TCP server, ovviamente, puoi sempre fare tutti-i-client<=>1 singola porta TCP, esattamente come funziona HTTP sulla porta 80 per tanti client diversi.
Non ti so dare informazioni precise sulla funzionalità per java di un approccio del genere, ti serve qualcuno più esperto di me.
Dal punto di vista IP hai problemi (o meglio ce l'ha il client) se deve gestire con un singolo IP più di 65K connessioni (può avvenire qualcosa del genere forse per le reti fastweb)
Altrimenti ogni connessione è qualificata da una quadrupla: IP server:portaserver, IP client:portaclient
I primi due sono fissi (anche se in realtà nulla vieta di dare più IP ad un sigolo server), ma gli ultimi due sono tipicamente diversi, il terzo è uguale nel caso di uso di NAT (ad esempio un router casereccio).
Spero di essere stato sufficientemente esaustivo.