Questo sito utilizza cookies solo per scopi di autenticazione sul sito e nient'altro. Nessuna informazione personale viene tracciata. Leggi l'informativa sui cookies.
Username: Password: oppure
Delphi - Problema OnDisconnect TserverSocket.
Forum - Delphi - Problema OnDisconnect TserverSocket.

Avatar
smanettone83 (Normal User)
Pro


Messaggi: 124
Iscritto: 20/10/2010

Segnala al moderatore
Postato alle 12:10
Martedì, 02/11/2010
Ciao a tutti.
Ho un piccolo problema che non riesco a risolvere... Spero che possiate aiutarmi.
In pratica in un server creato da me con compoenti TServerSocket  ho inserito una listbox dove vengono riportati tutti i nomi dei client connessi, e fin qui tutto ok.... quando un client si disconnette automaticamente nella listbox del server viene eliminato il suo nominativo... in fin qui ci siamo ancora.... il problema ora sta nel fatto che se ad esempio un client si diconnette brutalmente perche ad esempio e' caduta la linea oppure il programma viene terminato dal taskmanager, il server non riesce ad intercettare questo evento e di conseguenza il nominativo di questo client rimane inserito nella listbox e non viene rimosso.... Come posso fare per intereccetare questi eventi particolari?
Spero di essere stato chiaro....
Grazie a chiunque per una risposta.

PM
Avatar
a_butta (Member)
Expert


Messaggi: 578
Iscritto: 16/03/2010

Up
0
Down
V
Segnala al moderatore
Postato alle 15:28
Martedì, 02/11/2010
Se ho ben capito, tu imposti un comando che cancelli l'utente nella listbox ogni qual volta esso si disconnetta, diciamo "volontariamente" dal server.
Non potresti semplicemente mettere un comando automatico del server da ripetere con una frequenza di tot secondi, che verifichi la reale connessione dei client ad esso?

PM
Avatar
gigisoft (Member)
Guru


Messaggi: 696
Iscritto: 11/10/2008

Up
0
Down
V
Segnala al moderatore
Postato alle 16:08
Martedì, 02/11/2010
Testo quotato

Postato originariamente da a_butta:

Se ho ben capito, tu imposti un comando che cancelli l'utente nella listbox ogni qual volta esso si disconnetta, diciamo "volontariamente" dal server.
Non potresti semplicemente mettere un comando automatico del server da ripetere con una frequenza di tot secondi, che verifichi la reale connessione dei client ad esso?



si, mi sembra la soluzione piu' adeguata, una specie di scambio di messaggi del tipo:

Server: Client 192.0.0.1, ci sei?
Client: Client 192.0.0.1, eccomi.

da ripetere, che so, ogni 4 - 5 secondi

Ultima modifica effettuata da gigisoft il 02/11/2010 alle 16:09
PM
Avatar
smanettone83 (Normal User)
Pro


Messaggi: 124
Iscritto: 20/10/2010

Up
0
Down
V
Segnala al moderatore
Postato alle 19:18
Martedì, 02/11/2010
Grazie per il consiglio ragazzi ci avevo gia pensato a questo...Ho solo un dubbio.... non c'e' pericolo che creando un ciclo del genere si possa intrecciare tutto il testo ricevuto dal socket tra i vari client?
ES: se un utente nello stesso identico secondo che il server sta inviando il quesito "ci sei" scrive qualcosa? secondo voi non si crea casino??? io temo di si....

spero che abbiate capito

PM
Avatar
a_butta (Member)
Expert


Messaggi: 578
Iscritto: 16/03/2010

Up
0
Down
V
Segnala al moderatore
Postato alle 20:12
Martedì, 02/11/2010
In teoria no perchè comunque i due segnali dovrebbero viaggiare asincronicamente (la probabilità che vengano inviati contemporaneamente è molto bassa anche se non nulla in effetti) con la differenza che uno è "visibile", l'altro no ed è solo finalizzato al server in sè.

Se vuoi completamente evitare problemi di questo genere, mi vengono in mente due modi:
1) semplicemente metti un "timeout" dopo il quale un utente viene automaticamente disconnesso per inattività: se il client ad esempio non scrive per 15 minuti allora il server lo cancella dalla lista. Questo metodo è il più semplice a mio avviso, ma molto poco elegante e funzionale.

2) Imposti una semplice variabile boolean collegata a un timer e alla ricezione di qualsiasi messaggio del client: parti dalla variabile impostata su true. Un timer scorre e fintantochè vede questa variabile impostata su TRUE lascia l'utente nella lista, altrimenti se è FALSE lancia un controllo (uno di quelli precedentemente discussi) e se non ritorna allora cancella l'utente, altrimenti se il client risponde in automatico vuol dire che è solo inattivo ma connesso e lo lascia lì. Un altro timer, quello dell'inattività ogni tot secondi (abbastanza ampio, cioè anche sui 10 o 20 secondi) imposta indipendentemente da qualsiasi fattore questa variabile in FALSE, come se passasse automaticamente il client in inattivo in modo da consentire il controllo da parte del primo. Ogni volta che il client manda un messaggio questa variabile viene impostata su true (indipendentemente dal suo attuale valore) di modo che anche se impostato su inattivo, il client ritorna attivo.
Questo metodo dovrebbe (credo :D) ridurre la possibilità di collisioni di segnale anche se dal punto di vista dell'elaborazione non è proprio immediata.

Questo è ciò che la mia mente ha partorito :D. Spero di non aver dimenticato qualche inghippo, in tal caso chiedo scusa :D
Che ne pensi?

PM
Avatar
gigisoft (Member)
Guru


Messaggi: 696
Iscritto: 11/10/2008

Up
0
Down
V
Segnala al moderatore
Postato alle 21:21
Martedì, 02/11/2010
Testo quotato

Postato originariamente da smanettone83:

Grazie per il consiglio ragazzi ci avevo gia pensato a questo...Ho solo un dubbio.... non c'e' pericolo che creando un ciclo del genere si possa intrecciare tutto il testo ricevuto dal socket tra i vari client?
ES: se un utente nello stesso identico secondo che il server sta inviando il quesito "ci sei" scrive qualcosa? secondo voi non si crea casino??? io temo di si....

spero che abbiate capito



in realta' no, a patto che tu gestisca, a livello applicativo, la separazione tra messaggi di controllo e messaggi effettivi;
un altro modo puo' essere sfruttare i messaggi di echo request e echo reply messi a disposizione dal protocollo ICMP

PM
Avatar
smanettone83 (Normal User)
Pro


Messaggi: 124
Iscritto: 20/10/2010

Up
0
Down
V
Segnala al moderatore
Postato alle 21:27
Mercoledì, 03/11/2010
Testo quotato

Postato originariamente da a_butta:

In teoria no perchè comunque i due segnali dovrebbero viaggiare asincronicamente (la probabilità che vengano inviati contemporaneamente è molto bassa anche se non nulla in effetti) con la differenza che uno è "visibile", l'altro no ed è solo finalizzato al server in sè.

Se vuoi completamente evitare problemi di questo genere, mi vengono in mente due modi:
1) semplicemente metti un "timeout" dopo il quale un utente viene automaticamente disconnesso per inattività: se il client ad esempio non scrive per 15 minuti allora il server lo cancella dalla lista. Questo metodo è il più semplice a mio avviso, ma molto poco elegante e funzionale.

2) Imposti una semplice variabile boolean collegata a un timer e alla ricezione di qualsiasi messaggio del client: parti dalla variabile impostata su true. Un timer scorre e fintantochè vede questa variabile impostata su TRUE lascia l'utente nella lista, altrimenti se è FALSE lancia un controllo (uno di quelli precedentemente discussi) e se non ritorna allora cancella l'utente, altrimenti se il client risponde in automatico vuol dire che è solo inattivo ma connesso e lo lascia lì. Un altro timer, quello dell'inattività ogni tot secondi (abbastanza ampio, cioè anche sui 10 o 20 secondi) imposta indipendentemente da qualsiasi fattore questa variabile in FALSE, come se passasse automaticamente il client in inattivo in modo da consentire il controllo da parte del primo. Ogni volta che il client manda un messaggio questa variabile viene impostata su true (indipendentemente dal suo attuale valore) di modo che anche se impostato su inattivo, il client ritorna attivo.
Questo metodo dovrebbe (credo :D) ridurre la possibilità di collisioni di segnale anche se dal punto di vista dell'elaborazione non è proprio immediata.

Questo è ciò che la mia mente ha partorito :D. Spero di non aver dimenticato qualche inghippo, in tal caso chiedo scusa :D
Che ne pensi?



provo e ti faccio sapere grazie ;)

PM
Avatar
smanettone83 (Normal User)
Pro


Messaggi: 124
Iscritto: 20/10/2010

Up
0
Down
V
Segnala al moderatore
Postato alle 16:29
Giovedì, 04/11/2010
risolto con la seconda ipotesi grazie ;)

PM
Avatar
a_butta (Member)
Expert


Messaggi: 578
Iscritto: 16/03/2010

Up
0
Down
V
Segnala al moderatore
Postato alle 20:37
Giovedì, 04/11/2010
perfetto! Figurati!:k:

PM