Newsgroup: it.comp.lang.delphi
Titolo: Indy9 - Verifica disconnessione

Ciao.
Ho due applicazioni con una form con un TIdTCPServer ed un TIdTCPClient su 
ciascuna.
I due prg, montati su due macchine in rete, si scambiano informazioni.
Brevemente, un client invia una stringa formattata al server remoto 
"presentandosi" come nuovo utente. Il server lo cataloga in una TList, lo 
disconnette e con il suo TIdTCPClient si collega al TIdTCPServer remoto e 
gli invia un array da analizzare. La macchina remota riceve lo stream e 
disconnette il client che gliel'ha inviata. Analizza il tutto (durante 
questa operazione non vi è più nessun collegamento tra le due macchine) 
quindi si ripresenta con un'altra stringa formattata che contiene 
informazioni sul lavoro eseguito e chiede un'altro stream. La cosa è 
ciclica.
Troppo confusa?  :-)  però parrebbe funzionare...
Il problema è che in fase di test al client remoto faccio solo leggere lo 
stream, visualizzarlo in un TMemo e chiedere il successivo. Ora succede che 
dopo qualche migliaia di letture il processo si interrompe con errore di 
porta in uso. Se inserisco un ciclo che non fa niente, subito dopo le 
disconnessioni dei due client, nessuna interruzione.
Quindi le connessioni - disconnessioni sono troppo veloci ed inducono 
errore.
Ho provato ad usare CheckForDisconnect ma con nessun risultato.
Qual'è l'operazione giusta per verificare (attendere) la disconnessione che 
libera la porta?
Preciso che nei TIdTCPClient non ho assegnato alcuna BoundPort.
Grazie
Valter

 disconnette il client che gliel'ha inviata.
Se ho capito bene su ogni macchina hai un server ed un client.
A che scopo, da quello che ho capito ti basta un serve al remoto ed un 
client al locale, eseguento tutta l'attivita' in
un'unica connessione.
Ciao Giorgio 

 un'unica connessione.
Mah, ho optato per questa soluzione perchè mi sembrava più facile gestire i 
vari eventi ma può darsi che sia meglio come suggerisci te. Sono ancora 
nelle prove...
In realtà l'idea è che siano numerosi i client che si collegheranno al 
server ed ognuno di essi dovrebbe ricevere dei dati da calcolare. In questo 
contesto, pensavo (lo penso ancora se non mi confermi il contrario) che, 
essendo le operazioni da svolgere abbastanza lunghe, fosse meglio 
disconnettere il client una volta in possesso dei dati e farlo ricollegare 
non appena pronto il risultato.
Però adesso ho predisposto un server e due client ma il secondo nel quale 
avvio l'applicazione blocca il server come se il server stesso non potesse 
gestire + di una connessione.
Hai suggerimenti o sai dove reperire dei demo nei quali + client si 
collegano ad un server contemporaneamente?
Grazie
Valter

disconnette il client che gliel'ha inviata.
Quando il client si collega al server, il canale di comunicazione tra
i due sistemi è già attivo: non serve disconnettersi e crearne uno
nuovo per la risposta.  Il client invia le informazioni e si mette in
ascolto, il server riceve le informazioni e risponde.  Punto.  Una
sola connessione, due trasferimenti dati (input e output), una sola
disconnessione.  
Il problema, a questo punto, può essere il numero di connessioni fatte
dal client nell'unità di tempo; occhio a dimensionare bene il server,
infatti, altrimenti rischi che esploda in termini di consumi di
memoria.  Immagino comunque che il server mandi al client una quantità
di informazioni tale da richiedere un certo tempo di elaborazione (in
SETI, ad esempio, i tempi di elaborazione lato client sono abbastanza
lunghi).
Nota a margine: avere un tcp server anche lato client può portare a
diversi problemi in quei sistemi protetti da router/firewall (vedi
applicazioni come i client ftp, che quando non sono in modalità
passiva, ascoltano su una porta anche sul client).  Se il client può
"uscire" e raggiungere il server, il canale di comunicazione già
esiste ed è quello che va sfruttato.

Tra i Msg del 13/9 c'e' un mio messaggio contenente il codice per un 
Client/Server completo di Thread.
Se lo usi fammi sapere che ti invio una lieve correzione da fare.
Lavora in modo bloccante, usando un thread per ogni connessione client. 
Anche il client lavora sotto Thread, cosi' durante le operazioni non blocchi 
l'applicazione.
Se usi le Indy 9 c'e' qualcosina da cambiare.
Ciao Giorgio 

gestire + di una connessione.
Il componente TIdTCPServer implementa una logica multithread; bisogna
vedere il tuo codice.

 vari eventi [...]
Grazie per i vostri chiarimenti.
Ok, converto il tutto eliminando il client locale ed il server remoto.
Darò un'occhiata alle vostre unit per schiarirmi le idee.
Valter

Grazie per i vostri chiarimenti.
Ti sto preparando un esempio...

 Se lo usi fammi sapere che ti invio una lieve correzione da fare.
Ti so dire.
Grazie
Valter

 diversi problemi in quei sistemi protetti da router/firewall [...]
Mi hai letto nel pensiero. Già mi chiedevo come aggirare l'ostacolo  :-)

 Ti sto preparando un esempio...
:-))

"Andrea Laforgia" <a.laf...@andrealaforgia.it.invalid> ha scritto nel 
messaggio news:5t3ah2p9brci1o8cb...@4ax.com...

sto guardando le tue unit trovate in rete e le ho adattate per far si che 
sia il server ad inviare i dati da analizzare anzichè il client...con un 
client collegato non fanno una piega, anche con l'invio ciclico, ma ho dei 
problemi su una seconda connessione in contemporanea alla 
prima...logicamente il problema si verifica su
if Assigned(FOutputThread) then AThread.Connection.Disconnect
     else
       FOutputThread := AThread;
in quanto FOutputThread è già assegnato, pur "arrivando" da due client 
diversi con due IP diversi, e mi dirotta sull'evento OnDisconnect facendo 
confusione tra due client.
Se ritieni possa utilizzare il tuo codice per il multithread, un piccolo 
suggerimento?
Grazie
Valter

        FOutputThread := AThread;
A te non serve FOutputThread.  Togli del tutto la sua gestione.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

        FOutputThread := AThread;
A te non serve FOutputThread.  Togli del tutto la sua gestione.


 
Secondo me il problema non e' di Delphi ma di  
www.newsland.it
Ciao Leon

 Secondo me il problema non e' di Delphi ma di  
www.newsland.it
Che vuoi dire ?


 
A me Andera arrivano doppi messaggi uno da
leadongroup.it
  e una da x...@xx.xt
con lo stesso orario . Ciao Leon

 A me Andera arrivano doppi[...]
Sorry, ho sbagliato io.
