Newsgroup: it.comp.lang.delphi
Titolo: Com'e' andata a finire ...

Ciao a tutti,
       rieccomi a voi con il temporaneo epilogo di "File in esecuzione sul 
server".
Sara' un po lunga ... quindi mi scuso in anticipo con coloro che leggeranno 
perche' qualche minuto lo perderanno (magari per un qualcosa che gia' 
sanno), ma dopo tutti i consigli/dritte ricevute questo e' il minimo (e 
magari sara' utile a qualcun altro).
In breve, un file residente su un server viene lanciato da uno shortcut dai 
desktop in rete.
Problemi, capire quanti sono connessi e in quale postazione per evitare 
aperture doppie.
Dopo lunga discussione qui sul news sono arrivato a questa soluzione, rozza 
ma funzionate !!!
Ho dovuto mettere in piedi un piccolo monitor residente su server che parte 
all'avvio del server stesso, oppure manualmente basta che venga lanciato 
(anche fuori dalla finesra con il server). Nel monitor c'e' un componente 
TServerSoket che rimane in ascolto.
Lato programma, c'e' un componente TClientSoket.
Ecco quello che accade.
Programma : Viene eseguito e fa un controllo sul drive per capire se e' una 
esecuzione locale o in rete. Se e' locale setto IsLocal a True altrimenti a 
false. Se non e' locale il soket cerca di connetersi al server, se non 
avviene la connessione stop.
A connessione avvenuta controllo sul db degli utenti connessi chi si e' 
connesso, se non c'e' l'utente in questione aggiungo un record riportando il 
nome del login e il nome del pc con il suo ip. Se c'e' l'utente e' gia' 
loggato si avvisa dov'e' loggato ed esce. Se in numero dei record e' 
superiore a quelli permessi, altro avviso ed esce.
Se e' un'esecuzione ci si appoggia sull'evento OnDisconnect. Se viene 
eseguito siggnifica che il server ha avuto dei problemi, si e' spento?? 
hanno chiuso il monitor ?? Bho, pero' il collegamento si e' interrotto 
quindi ...... abort su tutto ed esce brutalmente, il server e' giu' quindi 
dove scrivo ??
Tutto fila liscio, fine del programma, elimino il recod dell'utente in 
questione, disconnessione dal monitor, uecita regolare.
Chiudo brutalmente il programma, dal monitor tramite il soket so chi e' 
caduto e cancello dal db quell'utente.
Monitor: Viene eseguito, controlla il db degli utenti, se ci sono controllo 
se uno di quegli utenti e' in locale (sta lavorando sul server), se il glag 
rete e' attivo allora lo cancello perche' il programma in rete puo' solo 
girare se il monitor e' attivo, quindi e' presumibile che qell'utente(i) 
hanno avuro problemi oppure hanno spento il pc togliendo la spina.
Rimane in ascolto per probabili connessioni e quando queste avvengono ..... 
non fa niente sta li ed aspetta.
Se il programma (client) termina con successo eseue la sconnessione e 
l'utente e' cancellato dal db dal client stesso, se la connessione termina 
per altri motivi e' il monitor che elimina il record da db degli utenti.
Su una rete domestica di 1 server con xp professional (quindi niente window 
server) con 3 pc in rete (di cui un portatile toshiba satellite con xp 
professional sp3 e gli altri due xp home) funziona bene anche cercando le 
situazioni impossibili (togliere la spina ad un pc, spegnere il router, 
killare il processodel monitor, killare il processo del client ecc...) e 
tutto rimane gestibile (certo si puo' fare di piu' anche graficamente o 
mettere mille avvisi su tutto).
Lunedi' provo il tutto su una rete piu' vera con 1 server (windows server 
2003) 4 pc xp professional e 3 terminali hp .... vedro' come si comporta (un 
grazie per chi mi presta questa rete !!!!).
Come di consueto, sono qui ad ascoltare tutto cio' che puo' farmi 
migliorare.
Ringrazio tutti, ma proprio tutti coloro che mi hanno sostenuto e che per 
motivi di tempo non ho potuto ringraziare di persona.
Alla prossima, Ciao, Daniele
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4570 (20091103) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com

 aperture doppie.
Non capisco il perch�. Perch� le aperture doppie non sono consentite?
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4573 (20091104) __________


 dall'altra parte
Questa non � una spiegazione. PERCHE' non si dovrebbe poter aprire? che
problema c'�? E' una questione commerciale o tecnica? Insomma, io starei
attento prima di implementare accrocchi strani e potenzialmente inutili. 
Gestire connessioni permanenti con TCP/IP significa anche gestire tutti i
potenziali errori (a questo punto meglio UDP per una sorta di semplice
"keep alive"). Che succede infatti se un client non riesce a connettersi
al server? che succede se si connette ma il server non riesce a scrivere
su db? che succede se la connessione cade in qualunque istante?
Perch� imbarcarsi nella creazione di un sistema c/s di controllo del
genere quando la richiesta a monte potrebe essere insensata? 
Forse � meglio far capire ai responsabili che limitare il numero di
accessi per utente non � la soluzione al problema. La soluzione � avere un
server robusto e implementare l'applicazione in maniera tale da poter
risolvere gli eventuali conflitti di concorrenza.
In ogni caso, se proprio devi buttati in quest'impresa, forse la cosa
migliore � evitare qualsiasi sistema client server di monitoraggio (TCP o
UDP che sia). Fai s� che al momento del login, il client verifichi se
esista, in una tabella ACCESSO_SISTEMA, un record relativo allo username
dell'utente. Se lo trova e il campo timestamp del record � anteriore a un
certo numero di minuti (configurabile), vuol dire che quell'accesso �
andato in time-out, quindi cancella il record e si comporta come se il
record non esistesse (vedi sotto). Se lo trova ma il campo timestamp del
record � ancora nell'intervallo valido prima del time-out, segnala che un
utente � gi� loggato e non fa accedere l'utente al sistema. Se non trova
il record, lo inserisce con il campo timestamp valorizzato. Ogni X minuti,
poi, con X < time-out, ogni client aggiorna il proprio record, aggiornando
il campo timestamp. Se un client non trova il proprio record, all'atto
dell'update, si disconnette per time-out.
Questa soluzione � pensata al volo, non ci ho ragionato molto su. Verifica
se possa essere applicabile al tuo caso.


 se possa essere applicabile al tuo caso.
Bella davvero, la ragiono su e faccio sapere ....
Grazie e ciao, Daniele 
