Newsgroup: it.comp.lang.delphi
Titolo: Indy e tcpserver consiglio

Devo scrivere un softwarino in delphi 7 e indy che permetta a 2 o più pc 
di comunicare via tcp. Ho già scritto qualcosina, poche righe e fatte 
male che però funzionano, usando il componente IdTCPServer. Vorrei però 
un consiglio da voi su come scrivere corretamente la comunicazione tra 
due o piu macchine che non pianti il programma o la macchina stessa, e 
per far questo è sufficiente il solo componente citato o se ne deve 
usare altri ?
Omega

Secondo me basta quello, aggiungerei un altro thread per la gestione delle
code.
Poi dipende da cosa devi fare nello specifico e da come hai iniziato la
struttura
Bye,
Raktzo

Omega
	Ciao
	MassimoB
 
---------------------------------
http://www.massimobeschi.it/
---------------------------------
Se tu pagare come dici tu ...
Io lavorare come dico io ...
Se tu pagare come dico io ...
Io lavorare come dici tu ...
---------------------------------

 code.
Cioč?

 [...]la logica Indy è bloccante[...]
Che vuoi dire ?

 Cioè?
Come ha ricordato MassimoB, Indy è principalmente bloccante, percui la
richiesta di un client la scarico in una coda, sblocco il client, gestisco
la coda.
Se non ho letto male non credo che abbia bisogno di servizi sincroni.
Ovvio che, se le esigenze sono altre, la soluzioni può non essere
pertinente.
Bye,
Raktzo

 la coda.
Mi spieghi che cosa vorresti fare?

 Mi spieghi che cosa vorresti fare?
Lettura dal client che fa la richiesta
scarico sulla coda
rilascio il client
altro thread
 lettura coda
 invio informazioni al client/ai client
Ho forse interpretato male la richiesta iniziale?
Una tua interpretazione/soluzione?
Bye,
Raktzo

  invio informazioni al client/ai client
Cioè rendendo il tutto asincrono?
La logica asincrona richiede molta attenzione ed è più difficile 
da gestire.  Oltretutto, se il client ha bisogno di ricevere 
risposte dal server, per andare avanti, rimanere sincroni è meglio.

 Che vuoi dire ?
Penso che l'aggettivo "bloccante" si riferisca al fatto che la logica 
con cui sono implementati i componenti Indy prevede che ciascun metodo 
ritorni solo dopo aver completato il proprio compito.
E' più facile da esemplificare che da spiegare (o forse sono io che non 
riesco a spiegarlo bene).
Un esempio: alcune librerie richiedono di effettuare la connessione in 
un modo simile al seguente.
   // ...
   SomeServer.Connect;
   while not SomeServer.Connected do
     Sleep(1);
   // ...
In sostanza, l'invocazione di un metodo dà vita ad un thread che 
gestisce in modo asincrono la connessione ed è necessario scrivere 
codice aggiuntivo per controllare quanto questa avviene, gestire timeout 
manualmente, verificare se sono avvenuti errori e così via.
Indy invece lavora in modo sincrono:
   // ...
   IndyServer.Connect; // ritorna solo a connessione avvenuta (o errore)
   if IndyServer.Connected then
   begin
     // ...
   end;
   // ...
Questo permette di ridurre il codice da scrivere per eseguire una serie 
di comandi che, dal punto di vista logico, vanno eseguiti in sequenza, 
senza la necessità di aggiungere cicli di attesa addizionali.
Lavorando in questo modo, però, se si vuole aggiornare l'interfaccia 
grafica dell'applicazione mentre il componente Indy TCP server di turno 
esegue il proprio lavoro, si dovrebbe creare un thread separato e 
gestire in tale thread la connessione (attraverso la chiamata degli 
appositi metodi), mentre nel primo caso questa operazione potrebbe 
essere gestita all'interno del ciclo di attesa.
L'esempio è pretestuoso e serve solo a chiarire il concetto.
Ho la netta impressione che per rendere l'idea del termine "bloccante", 
bastava sostituirlo con "asincrono" senza aggiungere ulteriori dettagli. :-D
-- 
MARCO BREVEGLIERI
  (
http://www.marco.breveglieri.name
)

 risposte dal server, per andare avanti, rimanere sincroni è meglio.
Ho ribadito più volte che la soluzione data dipende molto dal contesto in
cui si applica.
Bye,
Raktzo

 essere gestita all'interno del ciclo di attesa.
Io preferisco la modalità degli Indy, perché ti lascia la scelta 
su come operare.  Forzarmi ad avere una modalità asincrona, da 
trasformare in sincrona mediante attese non mi piace molto.
La modalità asincrona può essere utile (e di fatto è l'unica 
utilizzabile con certe apparecchiature hardware, ad esempio) ma è 
leggermente più complicata da gestire (vedi macchine a stati, 
ecc..).  Quando posso, io uso sempre thread separati che lavorano 
in sincrono e che comunicano con il resto del mondo mediante messaggi.

 Io preferisco la modalità degli Indy [...]
Me too! :-)
Il codice è molto più pulito poichè contiene solo le chiamate ai metodi 
che rappresentano le operazioni da compiere nella sequenza logica con 
cui sono progettate. I thread, se servono e quando servono, gli aggiungo 
io, poichè Delphi rende discretamente semplice anche questo compito.
Ciao,
   Marco.


Che vuoi dire ?
http://www.swissdelphicenter.ch/en/showarticle.php?id=4


 
http://www.swissdelphicenter.ch/en/showarticle.php?id=4
Sě, sě, come lavorano gli Indy lo so.  In ogni caso, un eventuale 
"blocco" del sistema č dovuto a un uso scorretto dei componenti, 
non alla natura della comunicazione.  In genere, č sempre bene 
usare thread separati.

Mi sembra di aver generalizzato troppo. La comunicazione tra il client
e il server in questo caso deve essere sincrona ovvero quando il client
a trasmesso i suoi dati il server li riceve li processa e manda una
conferma al client. In questo caso però il programma deve poter
svolgere altre funzioni che arrivano dall'input dell'utente. Da quanto
ho capito servirebbe gestire il tutto in thread separati ?? In questo
caso sarebbe utile un piccolo esempio legato all'uso del IdTCPServer e
dei thread.

avete qualche esempio di utilizzo?? attualmente sto utilizzando indy con UDP 
anzichè TCP, però spesso gli antivirus mi bloccano i messaggi broadcast (che 
uso per aggiornare viste di software)
Simo 

 uso per aggiornare viste di software)
Tempo fa ho postato del codice di esempio, cercalo tra i vecchi 
messaggi.