Newsgroup: it.comp.lang.visual-basic
Titolo: Quanti e quali utenti hanno avviato l'applicativo

Vorrei aggiungere un controllo all'applicativo, per evitare che da
diverse postazioni di rete, lo stesso utente possa lanciare più volte
la  procedura.
Quindi all'avvio dovrei verificare se l'utente è già entrato nella
procedura.
E' possibile questo ?
Grazie.

Frank ha scritto:

Hazzzoooo se è possibile!!! :-)
Basta che utilizzi una tabella di un db in rete, dove inserisci i dati 
di coloro che lo utilizzano...poi con semplici query controlli se 
l'utente è presente nella tabella!!
Quando esce dall'applicativo, altra query di eliminazione dalla tabella!
Il gioco è fatto!
P.S. puoi usare un db come un file di testo ecc....

 Quando esce dall'applicativo, altra query di eliminazione dalla tabella!
E se il programma esce in modo abnormale? che fai?
-- 
I bet the human brain is a kludge.  - Marvin Minsky
News 2000 [v 2.06] - 
http://www.akapulce.net/socket2000


Si formatta il server :)
Per essere sicuri bisognerebbe avere un activex-exe sul server che monitora 
l'attività delle app client.
Ciao 

Fabio scriveva il 30/06/2006 :

O un qualunque dbms server, che fornisce lo stato delle connessioni dei 
vari host.
Ciao
Alberto
-- 
A questo punto hanno trovato un muro,
un muro duro, molto molto duro,
che siamo noi.

 
Se succede, è "naturale" che lo stato nella tabella è "anormale", come
del resto l'applicazione :-)

 del resto l'applicazione :-)
Quindi a quel punto l'utente può andare a casa :)
Ciao 

 E se il programma esce in modo abnormale? che fai?
basta un app che controlli i client accesi pingandoli , se non risponde al 
ping allora lo cancella dalla lista.
al limite lo si fa anche con un batch dos usando un file di testo come db. 

 come db.
A mio avviso è molto difficile. Ci vorrebbe una specie di
App.PrevInstanceOverLAN ;-) .
L'unica cosa simile che ho visto è il meccanismo di controllo delle licenze di
InstallShield: se si ha la licenza per N postazioni, appena si avvia la N+1
esima, appare un messaggio di blocco.
Ho idea che il programma utilizzi direttamente una porta TCP o UDP per
verificare il numero totale delle altre istanze in esecuzione presenti in rete.
Questa forse potrebbe essere una tecnica applicabile anche nel caso di Frank.
Bye
Raf
-----------------------------------------------------
Funk: cooler than the other side of the pillow.

 App.PrevInstanceOverLAN ;-) .
Semplicemente, nell'applicazione client, un piccolo server proprietario 
che risponde ad una specie di ping, anche esso proprietario, da un 
programma server ed il gioco è fatto...

Grazie per le informazioni.
Per il momento abbandono l'dea.

 esima, appare un messaggio di blocco.
Bastardi mi han copiato ! Chiedo i diritti ? :p 

 Per il momento abbandono l'dea.
guarda, sinceramente e' una cavolata, se hai le basi di programmazione gli 
unici argomenti da approfondire sono :
1) "creare un servizio in vb"
2) Usare winsock (basta che cerchi "chat winsock vb" )
3) fantasia per gestirti la logica delle licenze ! 

 3) fantasia per gestirti la logica delle licenze ! 
Senza tirare in ballo il winsock penso che, volendo insistere su 
questo progetto, probabilmente potrebbe essere utile un approccio del
genere:
Il prg aggiorna ad intervalli regolari (che so, 5...10minuti) una 
tabella di utenti in uso, con l'ora e la data. Se all'avvio del 
programma in tale tabella è presente l'utente con una distanza di 
tempo inferiore all'intervallo predetto vuol dire che c'è già un 
utente identico che lo sta usando. In caso di crash cmq basterebbe 
attendere quei 5..10 minuti per poter rientrare nell'applicazione.
-- 
IBM: Incredibly Bad Merchandising
News 2002 [v 2.07] / StopDialer / PopDuster - 
http://www.socket2000.com
Akapulce portal: 
http://www.akapulce.net

 Bastardi mi han copiato ! Chiedo i diritti ? :p
Non è la stessa cosa: non c'è nessun server, è più un concetto simile al
peer-to-peer.
Ogni programma all'avvio invia una sorta di "broadcast". Se qualcuno gli
risponde, esce.
Altrimenti significa che è l'unico in esecuzione e si mette a sua volta in
ascolto. Se riceve un "broadcast" risponde, costringendo chi viene dopo a
terminare.
Così non serve nemmeno la lista degli IP dei clients (e poi, altro problema, chi
la tiene?).
Questo in teoria, in pratica però farlo in VB6 eh, non so se è proprio una
passeggiata.


 attendere quei 5..10 minuti per poter rientrare nell'applicazione.
Poi però devi affrontare il problema di dove mantenere la tabella (che deve
essere *sempre* accessibile a tutti i PC client).
Se questo ti costringe ad installare o ad usare un DBMS solo per questo, o anche
solo a bazzicare nei "territori" degli amministratori di rete (condivisione
cartelle su un server, permessi etc. etc.), beh allora prima di scartare winsock
ci farei più di un pensierino!


 essere *sempre* accessibile a tutti i PC client).
Il problema è già risolto in partenza visto che diamo per scontato 
che il prg avviato da remoto possa accedere al db di lavoro, 
altrimenti non c'è nemmeno da preoccuparsene in caso contrario no?
-- 
IBM: I'd Be Misinforming


 altrimenti non c'è nemmeno da preoccuparsene in caso contrario no?
Rimaneva però il punto che tu stesso avevi correttamente sollevato, 
ossia che il client si collegasse e poi non riuscisse più a raggiungere 
il db.
Allora, sul server occorre qualcosa di attivo, oppure occorre che ogni 
X secondi il client invii un keepalive, che potrebbe anche essere un 
normale Update sulla tabella degli host, in cui indica che alle ore xyz 
era connesso.
Se il client si disconnette regolarmente, elimina il record di sua 
competenza.
Se si disconnette male (crash sw, rete, ecc...), il record diventa 
lentamente 'vecchio'.
A questo punto, qualcuno o qualcosa dovrà accorgersene, possibilmente 
gestendo in qualche modo il fatto che ogni client ha una impostazione 
dell'ora di sistema tutta sua.
Ma, a questo punto, occorre installare qualcosa di 'vivo' sul server. E 
quindi tornano in ballo i dbms così come applicativi software che 
pinghino (che schifo...) con winsock.


 altrimenti non c'è nemmeno da preoccuparsene in caso contrario no?
Per aver l'esigenza di impedire più istanze in rete, evidentemente ci deve
essere una qualche risorsa condivisa da fruire singolarmente da parte del
programma, ma non è detto che sia un DB.
Ciao


 dell'ora di sistema tutta sua.
Se ne deve accorgere l'applicativo stesso... Volendo essere precisi 
sarebbe bene che l'applicativo aggiungesse alla tabella oltre all'ora
e all'utente anche un id casuale, diverso ogni volta, da controllare 
prima di riaggiornare il record. Se l'id non coincide con quello 
vecchio (registrato 5 o 10 minuti prima) significa che qualcuno sta 
accedendo da remoto con l'ora sregolata... In tal caso un bel msgbox 
"Stai usando la stessa utenza in contemporanea: l'applicazione verrà 
terminata." 
Quindi ricapitolando:
1) Avvio applicazione con accesso utente/password (o cmq una 
autenticazione)
2) Controllo del record relativo all'utente: è più vecchio del tempo 
di aggiornamento?
SI-Ok, l'applicativo parte, riscrive il nuovo record aggiornandolo 
con l'id casuale e l'ora.
NO-Uso contemporaneo, l'applicativo esce con messaggio.
Durante l'uso:
Scaduto il tempo rilegge il record. Contiene il vecchio ID?
SI-OK,riscrive il nuovo record aggiornandolo con un nuovo ID casuale 
e l'ora.
NO-Qualcuno fa il furbo! l'applicativo esce con messaggio.
-- 
IBM: I've Become Magnanimous


 (che schifo...) con winsock.
Io ribadisco che con un activex-exe si risolverebbe tutto in modo molto piů 
semplice e trasparente.
Ciao 

 procedura.
Sarebbe da provare pero' senza utilizzare Winsock o database io farei
molto piu' semplicemente una cosa di questo tipo:
-L'applicazione sicuramente stara' su una cartella di un server tipo
\\server\applicazione
-Crei una sottocartella tipo \\server\applicazione\LoggedUsers
-Quando l'applicazione parte fai in modo che crei un piccolo file
\\server\applicazione\LoggedUsers\nomeutente.tmp con un semplice
comando
   nFileLog = FreeFile
   Open nomefile for output as #nFileLog
   Print #nFileLog, datetime.date$
Pero' non esegui la Close lascia l'operazione di Open aperta
-Quando l'applicazione termina fai una
    Close #nFileLog
in modo che venga chiuso il file e rilasciato il lock (e poi magari lo
cancelli anche con una Kill ma non e' indispensabile per il tuo
obbiettivo)
-Se lanci due volte l'applicazione con lo stesso nome utente in teoria
(ma ripeto sarebbe da provare) la Open ti restituira' un errore, quindi
e' sufficiente che lo gestisci. Se la Open va a buon fine nessun altro
utente e' entrato con quel nome utente. Se la Open invece restituisce
un errore siginifica che l'utente e' gia' entrato nella procedura
(ovvero quello che volevi controllare). Quindi il pezzo di codice sopra
sara' qualcosa del tipo:
   on Error Resume Next
   nFileLog = FreeFile
   Open nomefile for output as #nFileLog
   If Err then
            msgbox "L'utente e' gia' entrato nella procedura"
   else
            Print #nFileLog, datetime.date$
   end if
se provi facci sapere come e' andata. Ciao ;-)

 NO-Qualcuno fa il furbo! l'applicativo esce con messaggio.
SI questo ok pero' ogni client avviato dovrebbe fare la pulizia della 
tabella per i crash ad esempio :
Tempo di aggiornamento 5minuti
1) "Select Tempo from tblAccessi "
2) if tempo + 1 minuto > 6 minuti then
    "CANCELLA IL RECORD PERCHE' QUEL CLIENT E' CRASHATO"
3) Quanti utenti ci sono ?
    Troppi -> Esci
4) Passa alla gestione di aggiornamento del proprio record con  " Select 
Tempo from tblAccessi  where ID = mioID"
cosi ogni macchina controlla le altre ed aggiorna solo se stessa.
Bueno...
-- 
-- 
-Gigio@work-
G2k Blog : 
http://www.g2kweb.it/?3098
G2k Snip Url : 
http://www.g2kweb.it/?3015
G2k Free Gallery : 
http://www.g2kweb.it/?218
 

 tabella per i crash ad esempio :
Non è necessario. Al successivo login si pulisce da sola.
-- 
Volume in Drive C:  TOO_LOUD!
