Newsgroup: it.comp.java
Titolo: Tanti THREAD quanti CLIENT ?

Ciao a tutti, stavo leggendo un articolo su Programazione.it, scritto da
Cristiano Sadun :"Listening pattern: implementazione in Java per Thread
generici ".
Leggendolo mi sono accorto di una problematica.
Un server che accetta (N) client, tipicamente lancia un Thread per ogni
nuovo client.
Ma se entrano molti client? Mettiamo 5000 e + client? Lancio 5000 Thread?
Non penso che sia una gran furbata. Ci sono altre tecniche? O quella è
l'unica strada?

 Ci sono altre tecniche?
Avere 'n' server (cioe' un numero fisso di server in attesa) e
gestirsi delle "code", dove il primo che arriva e' il primo servito.
Davide

 wrote in 
news:afrl1g$3dl4$
1...@stargate1.inet.it
:

Alternative sono thread pooling (che mette in attesa richieste finche' non 
si libera un thread) e/o pipelining (in cui lo stesso thread esegue passi 
distinti e non mutuamente influenti di richieste per client diversi), o 
altre cose del genere. Il pooling e' facile, le altre no.
Del resto, un server "tradizionale" fa in genere una fork di un *processo* 
per ogni richiesta, quindi almeno con threads risparmi qualcosa.. ;-)
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

 avere un server dimensionato in modo da reggerli tutti.
Non c'è il rischio che tanti Thread alla fine possano aumentare in maniera
considerevole il rischio di instabilità, conflitti etc.?

 considerevole il rischio di instabilitŕ, conflitti etc.?
No se non ci sono dei buchi nel codice.
Pensaci un'attimo: quanti servizi sta' facendo funzionare in questo
momento il tuo computer ?
Davide

 per ogni richiesta, quindi almeno con threads risparmi qualcosa.. ;-)
Yeeeeeeee!!!! Sempre peggiooooooo.
Mi sa che l'argomento č Out of Range.
Ciao e grazie mille. Se hai qualche link da suggerirmi o testi a
riguardo.......

E' vero che se il sistema delle sincronizzazioni č fatto bene, questi
problemi non DOVREBBERO sussistere, anche perché a pensarci bene, io ho
cercato di strutturare gli oggetti lanciati dal server per gestire i client,
in modo tale, da bloccarsi (mediante wait e notifyAll) quando non devono
fare operazioni.
Forse mi sto fasciando la testa prima di essermela rotta.
Ora provo a fare il mio programma, cosě come avevo pensato in origine e come
mi hai suggerito di continuare a fare, poi provo a metterlo sotto stress e
vedo che succede.
Se non mi risenti, vuol dire che lo stress ha formattato il PC (cosa
toricamente impossibile in Java vero? Dimmi di si ti prego, menti almeno).
Ciao e grazie mille. ;)

 Se non mi risenti, vuol dire che lo stress ha formattato il PC
Il tuo stress o quello sul computer ? Quello sul computer al massimo
lo blocca. Per quanto riguarda il tuo, io in questi giorni sto' rifacendo
la cucina e devo dire che, andare a casa, prendere un grosso martello e
prendere a martellate oggetti inanimati e' un'ottima valvola di sfogo...
Davide

>oggetti inanimati e' un'ottima valvola di sfogo...
Ti serve una mano a rifare la cucina? ;)

 Ti serve una mano a rifare la cucina? ;)
Veramente ho quasi finito, mi manca di allacciare la piastra di
cottura.
Davide

 Non riesco a vede alternative.
In genere funziona cosi': il server e' in ascolto su una socket, e arrivano 
due richieste. Il s/o ne mette una in coda e da' l'altra al server (in 
java, una ServerSocket.accept() ritorna improvvisamente una (client) 
Socket) Il quale reagisce, facendo qualcosa di *molto* veloce per servire 
la richiesta e si rimette subito in ascolto.
A meno di casi banali, il qualcosa di molto veloce consiste in : forkare il 
processo (tipico di server scritti in C/C++ qualche tempo fa o con 
linguaggi senza thread nativi) e lasciare al processo figlio il processing 
della richiesta (mentre il padre torna appunto immediatamente in ascolto); 
creare un thread, passargli la richiesta (in java, la client socket 
ritornata dall'accept()) e tornare immediatamente in ascolto; accodare la 
richiesta ad una lista di richieste da servire che viene monitorata da uno 
o piu' processi/thread separati e (indovina) tornare immediatamente in 
ascolto. E via dicendo.
Ma alla fin fine, con ogni metodo l'idea e' che o servi la richiesta 
immediatamente (per quanto possibile) - che ti porta a n-richieste/n-
thread; oppure la metti in coda finche' non si libera una risorsa di 
gestione (tipicamente, con un pool di 5 thread e una lista di 10 
richieste.. 5 di queste risulteranno "lente"). Il pooling aiuta in ogni 
caso perche' e' spesso piu' veloce riconfigurare un thread esistente per 
servire una nuova richiesta rispetto a crearne uno ex-novo.


Grazie mille.
Se decidi di scrivere qualche articolo su questo argomento, fammi sapere.
Ancora mille grazie.

 ha scritto nel messaggio
news:Xns923F669972AE7cr...@130.133.1.4...


Mettiamo caso che ogni nuova connessione, venga messe in una Pila/Vettore o
quello che volete, come faccio a verificare se un client ha inviato qualcosa
senza blocare il polling? Se uso la funzione read dei socket, questa blocca
il codice, quindi dovrei prima poter testare se è arrivato qualcosa, poi
andarmela a leggere.
Ma se arriva qualcosa da un client, quando il polling su quella socket è già
passato? Viene bufferizzato in automatico da Java? Se si fino a che punto?
Questa tematica secondo me è molto interessante, penso che sia il caso di
approfondirla.
Sarebbe un bel tema per le FAQ, visto il numero di argomenti che tocca.

 che punto? 
La gestione degli arrivi e' un servizio di sistema operativo. Il tuo codice 
esegue un'accept() (in java, su una ServerSocket) che si mette in attesa e 
ritorna appunto una Socket indipendente per una richieta. Se ci sono piu' 
richieste in coda, l'accept() successiva non attendera' nulla ma ritornera' 
subito. 


 ha scritto nel messaggio
news:afs437$8n0u$1...@stargate1.inet.it...
