Newsgroup: it.comp.lang.visual-basic
Titolo: Cos'è (per davvero) un "Server"?

Immaginiamo un programma che deve funzionare come "Server".
Non importa quello che deve fare, una sola cosa è certa: Deve rispondere a
uno, nessuno o centomila clients che fanno a spintoni per saltare in testa
alla fila, come se fossero davanti a uno sportello di un ufficio postare
alla fine del mese.
Il mio amletico dubbio è questo: Anche un "buon Server" non può far altro
che rispondere come l'impiegato postale che sta dietro al vetro, cioè "non
spingete, uno alla volta, avanti il prossimo", oppure un "buon Server" può
"moltiplicarsi" per essere presente, attivo e sveglio a più sportelli
contemporaneamente?
Insomma, il PC (ammettiamone uno solo) che ospita e fa girare il programma
Server, può solo contare sulla sua velocità per sbrogliare più in fretta la
fila, l'unica fila, oppure può (e come? caspiterina!) "multitaskare" il
programma e dar retta a tutte le sue beghe/file?
Non capisco, mi sembra troppo facile, eppure qualcosa mi sfugge!

 ha scritto nel messaggio
news:Si_w8.79395$m41.1...@twister2.libero.it...
OK, mi sono dimenticato di indicare che è palesemente OT, ma ... se non lo
chiedo qui, dove lo chiedo???

 programma e dar retta a tutte le sue beghe/file?
premessa: non so *niente* di client/server nè tantomeno di threads, vado
come solito per deduzione... in genere ci azzecco, ma non è detto :)
la risposta in teoria te la sei dato da solo con quel "multitaskare"...
immaginati il prog, fa partire diciamo 10 threads, ognuno del quale fà
girare una istanza di un qualcosa (oggetto | classe | form | programma) in
grado di riconoscere una richiesta in entrata e di dare una risposta. nel
programma vi è un solo punto di entrata ed uno solo di uscita. le richieste
entrano una accodata all'altra, il prog le smista (le assegna a una delle 10
cose in grado di elaborarle), quindi ne elabora 10 contamporaneamente, e
mette le altre in attesa. ricevuto l'output da un qualsiasi thread lo invia
tramite l'unica uscita al richiedente e libera il thread in questione, che a
questo punto sarà pronto per iniziare un'altra elaborazione. in questo modo
si eseguono 10 operazioni nel tempo in cui se ne farebbe una...
ci sono sicuramente metodi migliori, che però non avrei idea di come
realizzare materialmente... mettiamo sempre 10 thread, ognuno però questa
volta con una uscita ed una entrata. il prog riceva una richiesta ed
indirizza il richiedente sul primo thread, ne riceve una seconda e la
indirizza al secondo e così via. al termine dell'elaborazione ogni thread
darà autonomamente una risposta al richiedente con cui sarà collegato e si
libererà per altre elaborazioni.
questo in teoria potrebbe funzionare...
mi sa che ho detto un mucchio di str****te... correggetemi, mi raccomando!
:)
ciao e buona notte a tutti, assa.
--
Sito Comune
http://www.it-lang-vb.net/
p.s. mi accorgo solo adesso inserendo la firma che forse tu volevi soltanto
un esempio di prog multithread... mmm... se non ricordo male ce n'è uno sul
sito comune; ah, sempre se non ricordo male funge solo con vb5.
bye bye

 tutte le sue beghe/file?
Dipende da come è stato progettato e sviluppato il programma server.
Possono esserci più processi oppure più thread, uno  per ogni client.
Tieni però presente che su un computer mono processore può essere
eseguito un solo processo (ed un solo thread) alla volta, per cui in
ogni caso, in un preciso istante sarà comunque servito un solo client.
Ciao.
--
BSD is for UNIX-lovers -- linux is for Windows-haters.

 > Immaginiamo un programma che deve funzionare come "Server".
Grazie Assa della tua risposta. Quello che esprimi è chiaro... al 99%. Non
capisco questo: Se la CPU è una sola, come fa a dar retta ai 10 "cloni" (o
tasks) contemporaneamente? Temo che, in realtà, dia retta a un solo task per
volta. Se questo riesce a sbrigare la faccenda alla svelta, magari
parcheggiando la richiesta per rivederla in attesa di tempi migliori (quando
sarà inattivo), può dare la sensazione di favorire il multitasking, ma nella
realtà no. Insomma, la CPU e il SO fanno una singola cosa per volta o no? Io
credo di sì. Mi sto abbrustolendo il cervello!

"H.P.L." <u...@vaila.ble> ha scritto nel messaggio
news:W%_w8.51021$vF6.1...@news2.tin.it...

Ecco, questo mi piaceva sapere (e che mi torna). Quindi ... (mi si perdoni
l'apparente bestemmia), ogni Server, di fatto, è solo una gran bufala, nel
senso che, per quanto servente sia, più che fare una cosa per volta non può
fare. In altre parole: Ogni computer, con qualsiasi programma e pur con
grande velocità, non riesce MAI a fare due cose in assoluta contemporaneità
(tranne qualche operazione +-*/ in caso di multiprocessore). Dico bene?

 multiprocessore). Dico bene?
Sì e no. Per quanto sia vero che comunque viene eseguito un solo
thread alla volta (su macchine mono processore), creare un server
multithread è comunque estremamente vantaggioso (e pertanto non una
bufala), perché sarà il SO a gestire l'esecuzione dei vari thread,
gestione che è una delle cose più complesse e difficili da realizzare.


 ai 10 "cloni" (o tasks) contemporaneamente?
qui serve un po' di teoria di sistemi operativi :-)
I thread non eseguono solo operazioni matematiche (CPU burst), ma anche 
operazioni di I/O (I/O burst). Mentre un thread sta facendo una delle 
due cose non può fare l'altra, per cui quando un thread inizia un burst 
di I/O, il sistema operativo ferma l'esecuzione e ne avvia un altro, 
così la CPU non rimane mai inattiva. Questo vale anche per altri tipi 
di operazioni bloccanti, come le funzioni di sincronizzazione. Thread 
multipli significa avere sempre qualcosa di attivo da qualche parte
Poi c'è quella piccola entità invisibile chiamata "scalabilità", quella 
proprietà di un programma che fa sì che moltiplicando per dieci le 
risorse vengono moltiplicate per dieci le prestazioni, e che fa sì che 
il programma sia adatto per dieci come per dieci milioni di utenti 
senza modifiche. In questo caso significa che il tuo server, se è 
multithread, non necessiterà di alcuna modifica quando, da un vecchio 
Pentium polveroso chiuso in uno sgabuzzino, verrà aggiornato ad un 
Itanium con otto CPU, e potrà automaticamente trarne tutti i vantaggi 
possibili

 gestione che è una delle cose più complesse e difficili da realizzare.
H.P.L., ne sono convinto e grazie, ma ho bisogno di capire: Un PC (mettici
quello che vuoi) in un certo istante può, secondo te, fare due o più cose
(anche semplici istruzioni) diverse con assoluta contemporaneità?
Mi spiego meglio: Supponiamo di avere due task dello stesso programma che
stanno in attesa di richieste. E' vero o non è vero che due richieste
contemporanee verranno gestite (magari anche solo accettate e non
completamente "esaudite") una DOPO l'altra?
E ora mi faccio del male e mi brucio tutti i capelli: E' vero o non è vero
che PERSINO le due richieste NON POSSONO essere assolutamente contemporanee,
nel senso che "pervengono" al Server comunque in fila indiana?

 possibili
Va bene! Domanda secca: In VB si può scrivere un programma multi3d? Basta
dichiarare le opportune proprietà nel progetto? (mi pare che ci sia qualcosa
del genere).
Perchè tutto questo? Perchè voglio capire se posso fare "il mio Server". La
questione, certamente pretenziosa, nasce da una semplice considerazione: Se
il mio gestionale riesce a prestare attenzione a 1 o a 10 utenti (certo, con
prestazioni diverse), quindi a "servire" questi clients, perchè non fare un
programma che, al posto di contabilità, bolle e fatture, possa fare altro,
continuando a "servire" i clients?

 "pervengono" al Server comunque in fila indiana?
Vero.
Il tutto, sempre, su macchine mono processore. Con più processori
potrebbero essere eseguite più richieste in contemporanea. Ho detto
potrebbero perché devi sempre tenere conto che non c'è solo il tuo
programma server in esecuzione.


 progetto? (mi pare che ci sia qualcosa del genere).
Risposta secca: no. Tentare di farlo è una buona fonte di problemi.
O utilizzi altri linguaggi o passi a 
VB.NET
 (ma mi pare di capire che
tu non lo voglia fare).



<CUT>
Risposta: NO.
Motivo: COM.
COM, che è quel signore che fa funzionare gli oggetti VB in modo magico, ti
limita da quasto punto di vista, ovvero non puoi generare più thread veri.
Perchè è difficile spiegarlo, ma cerca nella documentazione M$ qualcosa
relativo alle "virtual tables". In soldoni, non ci sono puntatori ai
componenti, ma solo a virtual tables: COM gestisce i tuoi oggetti e lo fa
nel modo migliore per cui è stato concepito. Punto.
Una delle novità di .NET è questa: puoi veramente avere più di un thread:
anzi tutti quelli che vuoi. Il problema è districarsi poi dal fatto che hai
componenti in più di un thread e questo, ti assicuro, è anche peggio.
Spero di averti un pò chiarito le idee, mi sembri isterico (scherzo) ;)
Ciao,
Dads.

 nel senso che "pervengono" al Server comunque in fila indiana?
Tutto quello che passa per una rete TCP/IP e' seriale, percio' non possono
giungere due richieste nello stesso *istante*, anche montando due schede di
rete, perchè nel bus PCI non possono comunicare in contemporanea.
CIAnO

programma e dar retta a tutte le sue beghe/file?
mi sembra che già hai
ottenuto risposte esaurienti ma se posso aggiungere qiualcosa il multitask
in realtà non è del programma, ma del winsock. 
Il programma resta uno
solo e l'array (o collection) di oggetti winsock si incrementa ad ogni
chiamata di un client. La velocità è strettamente dipendente dalle
prestazioni del computer che ospita il server.
Quello che è vincolante è
che ogni istanza aperta dal client non si può riutilizzare, può solo essere
chiusa. In pratica se lo stesso client apre e chiude 1000 connessioni,
vengono istanziati 1000 oggetti diversi (si potrebbero cancellare gli
oggetti chiusi, a patto che nessun altro sia in uso). Questo spiega ad
esempio gli split su IRC, che non sono altro che reset del server che ha
raggiunto il massimo delle istanze.
Fabio
--------------------------------
Inviato via 
http://usenet.iol.it
 

 completamente "esaudite") una DOPO l'altra?
Una CPU puo' eseguire svariate centinaia di milioni di istruzioni al
secondo. Sebbene non possa (generalmente) eseguire piu' operazioni
contemporaneamente, per l'umano livello di percezione, con un'opportuna
distribuzione delle "richieste" (alla quale pensa in genere il sistema
operativo), l'esecuzione sembrera' a tutti gli effetti contemporanea.
Lo stesso "ascolto" sulle porte, sulle chede, sulle periferiche, sia a
livello di BIOS che a livello di S.O. non e' altro
che un magnifico loop infinito (almeno finche' c'e' corrente!) e non ha
nulla di veramente contemporaneo.
Lokar

 pare che ci sia qualcosa del genere).
yes. Deve essere un ActiveX out-of-process (exe) non interattivo. Ogni 
istanza delle classi implementate dal tuo programma girerà in un thread 
a parte. Questo significa che non puoi fare un server di rete, ma solo 
un server DCOM. La limitazione della non interattività (ossia nessuna 
interfaccia grafica) credo sia perchè i componenti grafici non sono 
thread-safe. Ma un server non ha bisogno di interfaccia grafica, in 
fondo

 fondo
Dimenticandoti di dire che essendo "D" com, lo esegui su un'altra macchina,
ovvero un'altra CPU ovvero è veramente "multi"thread.
Peccato per proxy, stub e il marshaling.
Cmq in una unica macchina, multithreading e COM sono incompatibili.
Dads.