Newsgroup: it.comp.lang.delphi
Titolo: Dubbio...

Ciao a tutti,
sarà una domanda molto... ma dico molto cretina...
ma ieri ho visto un programma Client / Server, dove l'eseguibile
risiedeva sul server, e tutti i client tramite un collegamento
lanciavano
quell'eseguibile....
Alchè io ho detto : "ma che è sta roba?"
Il programmatore mi ha spiegato che lui ha installato sui client solo
ciò che serve per eseguire il programma : dll, ocx, odbc etc etc...
poi, per evitare che per ogni aggiornamento del programma debba farsi
il giro su tutti i client, ha preferito adottare questa "FUNZIONANTE"
soluzione..
Così facendo, gli basta andare sul server e sostituire il vecchio
eseguibile con
il nuovo...
La domanda è : "dove è il problema?"
se il problema non c'è ... perchè io non l'ho mai fatto ?
Aiutatemi a capire questa ("per me") strana disposizione delle cose...
Grazie.
Rino

 Aiutatemi a capire questa ("per me") strana disposizione delle cose...
Non so che cosa tu ci veda di strano...
La soluzione di tenere il client del programma in un posto unico (in modo
da aggiornarla solo lě) l'ho adottata anch'io ed č perfettamente valida.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

l'unico problema è che in una grande realtà metti 30, 40 client che
utilizzano l'eseguibile, nel momento che devi eseguire l'aggiornamento
devi essere sicuro che tutti gli utenti siano scollegati, altrimenti il
file non può essere sovrascritto, ciao.

se sono questi gli unici svantaggi...
credo proprio che fino ad oggi... ho sbagliato tutto...

 devi essere sicuro che tutti gli utenti siano scollegati[...]
Questo problema si pone ugualmente, nel caso di un aggiornamento
distribuito.


 credo proprio che fino ad oggi... ho sbagliato tutto...
Scusa, ma non capisco cosa ci trovi di tanto strano...


 Aiutatemi a capire questa ("per me") strana disposizione delle cose...
In un prodotto che sto sviluppando ho realizzato un installer light
chiamato bootstrap che in pratica si collega al server, verifica se e'
disponibile una versione piu' aggiornata del client ed in tal caso lo
scarica e poi lo avvia (od avvia la versione gia' aggiornata presente
in locale).
L'idea di base, come quella del software che hai visto, e' quella di
centralizzare gli aggiornamenti dei client. In reti con decine se non
centinaia di client, fare un aggiornamento puo' voler dire passare le
nottate a saltare da un PC ad un altro semplicemente per avviare
l'installer di aggiornamento.
Il vantaggio di avere un tool come il bootstrap che ho descritto e'
quella di scaricare dalla rete il client solo quando serve piuttosto
che ad ogni avvio.
-- 
I am what I am, I do what I can
Do. Or do not. There is not try.

 in locale).
Ma non conviene semplicemente mettere un collegamento all'eseguibile sul  
server ?
Io ho sempre fatto cosi'.
(sempre che abbia capito :))
-- 
===============================================================
Alberto Rubinelli - A2 SISTEMI  Opera 8.50
Via Costantino Perazzi 22 - 28100 NOVARA - ITALY
Tel 0321 640149  Fax 0321 391769 BBS 0321 392320
Mail: 
alb...@retrocomputing.net
  ICQ : 49872318
Skype : albertorubinelli
Visita il mio museo di computers - Visit my old computers museum
 
http://www.oldcomputers.it
---------------------------------------------------------------

 server ?
In teoria sì.


Aiutatemi a capire questa ("per me") strana disposizione delle cose...
Secondo la mia modesta esperienza il problema sta nel fatto che facendo in
modo che i client
vadano a cercarsi ogni volta l'eseguibile o gli eseguibili sul server si
genera un maggior traffico
di rete e di conseguenza tutto il programma girerà più lentamente.
Ho provato a fare questo esperimento in una azienda che aveva 15 client
collegati ad un server.
Tutti i client andavano ad eseguire il programma che si trovava sul server.
In questo caso tutti gli utenti si lamentavano dell'eccessiva lentezza del
programma.
A questo punto ho pensato di spostare gli eseguibili sui singoli client. In
questo caso sono riuscito
a migliorare di molto le prestazioni.
Ci sono programmi poi che spesso devono far uso di file temporanei da
utilizzare per le elaborazioni
più complesse.
Io ho l'abitudine di mettere anche i file temporanei sul client così evito
il più possibile la generazione
del traffico.
Normalmente non solo è consigliabile mettere gli eseguibili sul client, ma è
anche consigliabile
strutturare i programmi in modo tale che il client invii meno richieste
possibili al server, sempre
allo scopo di generare un traffico di rete non esagerato.
Per esempio in un gestionale che deve occuparsi di fare l'esplosione di una
distinta base a più
livelli (operazione che può richiedere un algoritmo abbastanza complesso), è
preferibile fare in
modo che sia il server, mediante una stored procedure, a risolvere il
problema e non affidare
invece l'algoritmo al client che potrebbe essere costretto ad inviare molte
richieste al server
(probabilmente attraverso delle query) prima di ottenere un risultato.
Non so se sono stato abbastanza chiaro oppure ho generato ancora più
confusione, comunque
ho sperimentato sulla mia pelle che è bene tenere gli eseguibili sui client.
Marco D.T.

 ha scritto nel messaggio 
news:1134554426....@g43g2000cwa.googlegroups.com...


 (sempre che abbia capito :))
Mi sembra di aver scritto il vantaggio di una soluzione come quella
indicata:
[mi quoto]
Il vantaggio di avere un tool come il bootstrap che ho descritto e'
quella di scaricare dalla rete il client solo quando serve piuttosto
che ad ogni avvio.
[/mi quoto]
Oltre al fatto che non e' necessario che tutti i client siano fermi per
effettuare un aggiornamento (scaricarenno il nuovo client alla
successiva attivazione).


Oltre al fatto che non e' necessario che tutti i client siano fermi[...]
Neanche nell'altro caso.

 devi essere sicuro che tutti gli utenti siano scollegati[...]
Questo problema si pone ugualmente, nel caso di un aggiornamento
distribuito.
[/quoto]
La seconda frase l'hai scritta tu, ho sbagliato l'interpretazione?


La seconda frase l'hai scritta tu, ho sbagliato l'interpretazione?
Ovviamente.  E' ovvio che se devi installare un aggiornamento
distribuito, ovvero su ogni macchina, devi far uscire l'utente dal
sistema, aggiornare e poi farlo rientrare.

Andrea Laforgia wrote:

Nel sistema che ho proposto questo non e' necessario in quanto il
client viene aggiornato automaticamente al successivo avvia, ossia
l'amministratore non deve far chiudere all'utente il client,
aggiornarlo e farglielo riaprire.


Nel sistema che ho proposto questo non e' necessario[...]
E io ti ripeto per l'ennesima volta che neanche nel caso tu abbia un
file condiviso sul server, a cui accedono per collegamento i client
hai bisogno di far uscire gli utenti.  Puoi cancellare il file .exe e
mettere su la versione nuova, nonostante i client abbiano attiva
quella vecchia.  Quello che diceva Brunello, in sostanza, non è vero.

 quella vecchia.  Quello che diceva Brunello, in sostanza, non è vero.
Ossia dici che se apri un EXE da una condivisione netbios windows non
ne blocchera' l'eliminazione? Ne sei davvero sicuro?


ne blocchera' l'eliminazione? 
Infatti č cosě.

 ha scritto nel messaggio 
news:7t41q152cejqqu9ek...@4ax.com...

Sarebbe meglio pero' che tu imparassi a esporre i concetti da subito 
anziche' doverteli cavare ogni volta con 10 messaggi.
Era evidente che il punto della discussione era questo.
Anziche' dire "si" "no" e basta spiega da subito (che e' quello che fanno 
tutti).
Eviti di perdere tempo tu, noi e meno post inutili per tutti.
Grazie. 

 ho sperimentato sulla mia pelle che è bene tenere gli eseguibili sui client.
Quoto alla grande: io ho l'esperienza del gestionale che rivendiamo, il
zucchetti g1 (una ciofeca che viaggia ancora in bde...) che installa i
client su ogni macchina e quella che fa da server non viene presa di
assalto e non rallenta mai.
Ciao
-- 
Morde. 
ICLDweb: 
http://www2.samatel.com/icld/

 moduli di codice in esso contenuto.
A me viene in mente il comportmente di viruscan enterprise della mcafee: ne
ho potuto constatare l'ottima architettura installandolo su due server
aziendali. Lui ti puo' far fare dal server, mediante accesso come admin su
una macchina client, un deploy del software che lui chiama "agent".
Sostanzialmente questo programmino una volta che viene lanciato dal client,
si collega al server e scarica l'effettivo client, e gli aggiornamenti ogni
ora. Il tutto in maniera assolutamente trasparente all'utente. 
Poi dal server io posso controllare lo stato di tutti i client (gli
"agent"): se sono aggiornati, se hanno trovato i virus, e da li' poi posso
entrare nel dettaglio della singola macchina: versione installata del
client, numero di rilevazioni di virus, quali virus, ecc. ecc.
Questo non per fare pubblicità alla mcafee ma per spiegare quanto sia
veramente bello lavorare con un'architettura simile.
Zero sforzi, fai tutto dal server e piloti i client (o meglio gli "agent"
che stanno sui client) dicendogli anche quando aggiornarsi.
Una cosa cosi' non so quanto sia complessa da implementare via software,
fattosta' che se c'e' qualcuno qui dentro che ne sa di piu' e vuole far
partire qualche progetto in tal guisa, io sono disposto quantomeno a
partecipare.
Ciao a tutti , vado a fare una pausa caffè. A che belo u caffe', tutti in
carcere u sanno fa.. (perdonami salvati per il mio napoletano
lumbardizzato)
^___^


 Infatti č cosě.
Scusa Andrea se mi intrometto nella Vs. discussione.
Io installo il mio EXE sul server e lo condivido dai client in rete.
Se cerco di aggiornarlo (sempre sul server), cancellarlo o rinominarlo,
Windows (qualunque versione dal 95 a 2003 server) mi blocca sempre.
Ora o non ho capito quale č il trucco oppure c'č qualcosa che non mi torna.
Visto che ritengo che tu abbia molta piů esperienza di me , saresti cosi
gentile da dirmi come fai ?
Sono anni che corro da un ufficio all'altro quando davo fare aggiornamenti e 
spesso anche a telefonare agli utenti vigliacco se escono dalle procedure.
Grazie
Saluti
Marco

 Io installo il mio EXE sul server e lo condivido dai client in rete.
Se tu imposti sui client un collegamento al .exe e lo esegui, sul client,
tramite collegamento, Windows te lo fa cancellare tranquillamente.


 -- 
Ciao,
io ho provato e riprovato quanto affermi, ma a me esce questa segnalazione :
Impossibile eliminare (nome del file EXE). Accesso negato.
Controllare che il disco non sia pieno o protetto da scrittura e che il file 
non sia attualmente in uso.
Il server su cui è caricato il file EXE è un PC W98se mentre il client (il 
PC da cui ti scrivo) è XP SP2.
Ho fatto un collegamento dal mio PC al file EXE che si trova sull'altro.
L'ho aperto dal mio PC
Mi sono spostato sul server ed ho provato a cancellare il file EXE ed è 
uscita la segnalazione.
Io per server intendo un PC che fa da contenitore di dati, eseguibile + 
tutti gli archivi relativi al programma e per client un PC che fa partire 
l'eseguibile che sta sul server e poi utilizza gli archivi che si trovano 
sempre sul server.
Probabilmente nella mia tanta ignoranza sto interpretando male quanto 
affermi, ma qualsiasi prova io faccia non riesco a "cancellare 
tranquillamente" l'eseguibile.
Inoltre, se posso permetermi, a me non piacerebbe aggiornare l'eseguibile e 
sapere che ci sono client che continuano a lavorare con una versione non 
aggiornata, mi potrebbe creare problemi in seguito. Io credo, sempre nella 
mia tanta ignoranza, che tu utilizzi una tecnica diversa o che per te il 
conceto di server e client (nel contesto che stiamo trattando) sia diverso 
dal mio e sono certo (senza nessuna ironia, voglio essere chiaro) che sia io 
a sbagliare da qualche parte.
Se hai tempo e voglia di darmi qualche delucidazione, ti ringrazio in 
anticipo.
Grazie
Marco

 sempre sul server.
Non so come funzionino le cose sul 98, ma tra due XP è possibilissimo
cancellare un file .exe da una condivisione, pur avendo aperto il
programma sulla macchina remota.



OK,
farò ulteriori prove tra due XP, ero talmente convinto che non ho nemmeno 
fatto uno sforzo in questo senso.
Grazie per la tua attenzione.
Marco 

programma sulla macchina remota.
Non su 2000 o 2003.
-- 
Ore 18.30: premo invio.

successiva attivazione).
Rischi che utenti utilizzino però na versione vecchia del programma.
A me la cosa non piace.
Personalmente utilizzo questa soluzione:
eseguibile sul server.
Un operatore con diritti di amministratore può bloccare l'accesso al
programma (i sistemi sono vari) e può, dopo aver mandato un messaggio
d'avviso di sistema, forzare l'uscita degli utenti "pigri".
In questo modo è vero che obbligo tutti ad uscire dal programma ma non
corro il minimo problema di "versioning".


genera un maggior traffico
Scusa, ma è assurdo.
L'esecuzione dell'eseguibile sul server crea un traffico di N mega
all'avvio e poi basta.


Rischi che utenti utilizzino però na versione vecchia del programma.
dislessia allo stato puro :)
Leggasi: Rischi però che alcuni utenti utilizzino una versione vecchia
del programma.



Dalla mia esperienza QUOTO in toto.
Ciao
Marco 


Ciao,
č lo stesso dubbio che č venuto a me (e che ho espresso in altro post)
leggendo le soluzioni proposte per aggiornare l'eseguibile.
Meno male che trovo qualcun'altro che si pone lo stesso problema credevo di
essere "paranoico". :-D
Ciao
Marco

 d'avviso di sistema, forzare l'uscita degli utenti "pigri".
Praticamente uso lo stesso sistema, con la differenza che ho automatizzato  
tutta la procedura (download aggiornamenti automatico, avviso utenti, se  
dopo tot non escono vengono sbattuti fuori, poi aggiornamento, poi rientro  
automatico).
Ciao.Alberto.
-- 
===============================================================
Alberto Rubinelli - A2 SISTEMI  Opera 8.50
Via Costantino Perazzi 22 - 28100 NOVARA - ITALY
Tel 0321 640149  Fax 0321 391769 BBS 0321 392320
Mail: 
alb...@retrocomputing.net
  ICQ : 49872318
Skype : albertorubinelli
Visita il mio museo di computers - Visit my old computers museum
 
http://www.oldcomputers.it
---------------------------------------------------------------

 Non su 2000 o 2003.
Non ho né un 2000, né un 2003 sotto mano, ma ne dubito molto.



Esagera ! :-D
I miei clienti, già si spaventano, se utilizzo VNC e "gli muovo il mouse".
Io per gli aggiornamenti invio un CD-ROM (o un prossimo futuro glielo farò 
scaricare dal sito internet) con la versione aggiornata che "obbliga" tutti 
gli utenti ad uscire dalla procedura perchè la stessa si aggiorni (poi 
purtroppo c'è il solito pi..a che rientra nel programma prima che 
l'aggiornamento sia finito del tutto e crea casini, ma questo è un errore 
mio che non blocco tutti gli accessi fino al termine dell'aggiornamento. 
Altrimenti come faccio ad andare a trovare di persona le impiegate :-D ) .
Ciao
Marco 

 all'avvio e poi basta.
Ciò che ho riferito riguarda quello che ho osservato in prima persona su
diversi casi in cui gli
eseguibili si trovavano sul server.
Penso però di poter essere d'accordo con te nel dire che in molti casi ciò
che ho descritto
può essere considerato assurdo.
Infatti credo che l'eccessivo traffico di rete dipenda anche e soprattutto
da quanto è grande
il programma e da come è strutturato.
Un programma che è costituito da un solo EXE, per esempio di 3 Mega,
genererà un traffico
di 3 mega all'avvio e poi basta, proprio come tu affermi.
Credo però che sia diversa la situazioni in cui ci si trova di fronte ad un
programma molto
grande strutturato in Packages che non solo deve caricare l'EXE all'avvio
che può essere di
piccole dimensioni, ma deve anche caricare i diversi Packages a seconda
delle varie scelte
di menù effettuate dagli operatori.
Sicuramente ogni Packages non verrebbe caricato più di una volta, ma ci
sarebbe il problema
del traffico generato dal caricamento di diversi Packages in diversi momenti
della giornata.
In una rete con molti utenti puoi stare tranquillo, e parlo sempre per
osservazione diretta, che
si verificano diversi rallentamenti.
Io comunque non parlavo solo del problema degli eseguibili, ma mi riferivo
anche alla gestione
di eventuali tabelle temporanee e al traffico generato da richieste non
necessarie fatte al server.
I problemi di traffico naturalmente non è detto che siano dovuti solo ed
esclusivamente alla
locazione degli eseguibili o delle tabelle temporanee.
Ci possono essere tanti altri moltivi per cui si genera del traffico inutile
(altri software, problemi
hardware, hardware non dimensionato a dovere ecc ...) e, siccome non mi è
capitato mai di
vedere una macchina window completamente priva di problemi, se chi fa il
gestionale evita di
creare ulteriori e inutili rallentamenti sicuramente non sbaglia.
Marco D.T.

Non ho né un 2000, né un 2003 sotto mano, ma ne dubito molto.
fai male a dubitarne


Un'altro problema di una situazione del genere e il maggior traffico di rete
che si viene a creare e una velocità inferiore nell'esecuzione del client...

sarà una domanda molto... ma dico molto cretina...
ma ieri ho visto un programma Client / Server, dove l'eseguibile
risiedeva sul server, e tutti i client tramite un collegamento
lanciavano
quell'eseguibile....
Alchè io ho detto : "ma che è sta roba?"
Il programmatore mi ha spiegato che lui ha installato sui client solo
ciò che serve per eseguire il programma : dll, ocx, odbc etc etc...
poi, per evitare che per ogni aggiornamento del programma debba farsi
il giro su tutti i client, ha preferito adottare questa "FUNZIONANTE"
soluzione..
Così facendo, gli basta andare sul server e sostituire il vecchio
eseguibile con
il nuovo...
La domanda è : "dove è il problema?"
Questa non è una rete.
Il principio è errato e il sistema collasserà.
Conosco già dei precedenti.
Il programmatore è semplicemente un po' pigro.
Saluti.


Miiiiiiiiiiiiiiiiiiiiiiiiiii .
Sei catastrofista di natura o hai una spegazione tecnica per questa 
affermazione ?
Visto che anche io lavoro con l'eseguibile sul server ed il collegamengo sui 
client e
da 17 anni a questa parte non ho visto "sistemi collassare",
vorrei sapere se sono stato solo molto fortunato,
perchè in questo caso magari un biglietto della lotteria quest'anno lo 
compro. :-D
Ciao
Marco 

 da 17 anni a questa parte non ho visto "sistemi collassare",
In effetti credo che se si arriva al collassamento i motivi sono da
ricercare altrove.
Il fatto di installare gli eseguibili sul server e fare in modo che i client
li eseguano sul
server perň puň non essere una buona cosa in alcune situazioni dando luogo a
problemi di traffico di rete.
Per maggior chiarezza vedi li mio post di ieri in risposta a Massimo Pini
che trovi
un po' piů indietro in questo stesso argomento.
Ciao.
Marco D.T.


Ciao Marco  (ADelphOi),
avevo letto il tuo post precedente e l'avevo anche capito (o quasi, così non 
pecco di immodestia) e di certo condiviso.
Non rispecchia la realtà in cui lavoro, ma disegna uno scenario possibile e 
quindi è un post che posso quotare.
Ma Max, afferma :
"Questa non è una rete.
Il principio è errato e il sistema collasserà.
Conosco già dei precedenti.
Il programmatore è semplicemente un po' pigro"
Questo non mi sta bene, se non me lo giustifica.
Lasciare in rete post di questo genere può generare confusione.
Io rientro nella categoria di quelli a cui piace informarsi e che di 
confusione nella testa ne ha già abbastanza.
Quando è possibile, richiedo di fare un poco di chiarezza nelle proprie 
affermazioni,
poi non è obbligatorio che Max la faccia, ma almeno chi leggerà il suo post 
sarà invogliato a porsi dei dubbi.
Ciao
Marco

 vorrei sapere se sono stato solo molto fortunato,
Niente panico! Sono stato troppo pessimista.
In via di principio farei viaggiare in rete solo i dati essenziali e non 
l'eseguibile.
A ogni modo parte delle colpe dei collassi della
rete è da imputare al cablaggio della stessa.
Comunque questa tecnica usata per 17 anni è
una bella garanzia.
Saluti.