Newsgroup: it.comp.lang.c++
Titolo: TTcpClient

Sto facendo una prova di Client/Server con Borland C++. La cosa 
funziona, ma il Client (TTcpClient) resta bloccato in attesa dell'input. 
Mi chiedo se la cosa giusta è fare un nuovo thread per gestire l'input, 
oppure se c'è un modo (callback? peek?) per sapere se c'è dell'input in 
attesa.
E.

 fine funzionarono; se hai un indirizzo te li mando.
Ti ringrazio, ti ho scritto in privato.
E.

?manu* ha scritto:

Mi hanno suggerito il seguente articolo:
 
http://www.swissdelphicenter.ch/en/showarticle.php?id=4
che spiega che il modo giusto di fare quello che mi serve è istanziare 
un nuovo thread. Dunque ora mi tocca... devo imparare la programmazione 
multi-threading...
PS. L'autore dell'articolo è il progettista della corrispondente 
libreria di Delphi. Dunque molto autorevole ma... di parte!
E.

 libreria di Delphi. Dunque molto autorevole ma... di parte!
In realtà non esiste una "corrispondente" libreria: è sempre la
stessa. La VCL di Delphi è il sostrato su cui poggia anche C++
Builder.
I componenti Indy sono abbastanza buoni per svolgere questi compiti.
Che intendi con "di parte"?

 Che intendi con "di parte"?
Visto che la sua libreria è "blocking" lui difende questo paradigma...
E.

 multi-threading...
Ma la scelta di quella libreria/framework č dettata da esigenze specifiche? 
Max

 Ma la scelta di quella libreria/framework è dettata da esigenze specifiche? 
No, sto esplorando varie possibilità. Borland è un suggerimento che mi 
hanno dato, e devo dire che sono rimasto veramente impressionato dalla 
facilità con cui si può fare l'interfaccia grafica...
Per il server invece penso di utilizzare g++/boost.
E.

 No, sto esplorando varie possibilità.
In tal caso ti consiglierei di valutare Boost.Asio anche per il client. (Per
il server mi pare che tu ti stia già orientando in quel senso. O no?)
Max

 facilità con cui si può fare l'interfaccia grafica...
Ecco... valuta l'approccio a sincrono oltre che quello di andare
multithread. IMHO è più semplice. Andrea potrebbe non essere d'accordo
con me, tuttavia.
Io ammetto candidamente però di avere presente la programmazione
asincrona sotto fBSD (con kqueues), le varie select, poll sotto POSIX
*e* un fottio di roba sotto Python che qui non ha nulla a che vedere.
-- 
-riko

con me, tuttavia.
Sono d'accordo sul contemplare una strada alternativa. Non sono
d'accordo sul "piů semplice", perché credo dipenda dal tipo di
applicazione. Perň tieni presente che a livello professionale vorrei
tanto provare l'approccio asincrono e non trovo il modo di farlo;
viceversa ho sfruttato bene l'approccio multithread e di sicuro posso
dire che richiede molta attenzione.
Personalmente, non ho mai avuto grosse preoccupazioni. Comunque credo
che con le nuove architetture sarebbe uno sbaglio non valutare anche
l'approccio multiprocesso. Magari non sotto Windows, in cui č
particolarmente dispendioso.

Visto che la sua libreria è "blocking" lui difende questo paradigma...
Indubbiamente. E comunque se leggessi il codice sorgente scritto dal
buon Chad ti metteresti le mani nei capelli. Per non parlare di
Intraweb, un mostro generato dalla sua azienda, che ho usato (o
meglio: cercato di far funzionare) per un anno, per poi rinunciare.
Comunque con gli Indy non ho mai avuto particolari problemi. Prima che
diventassero componenti di serie di Delphi, molti usavano la suite
Internet Component Suite di Piette. La trovi ancora qui:
 
http://www.overbyte.be/frame_index.html

Max M. ha scritto:

Sì, ma il client deve avere un'interfaccia grafica per Windows, e quindi 
sarebbe preferibile usare un ambiente di sviluppo visuale dedicato a 
Windows. Non c'è ancora unanimità di vedute tra i miei eventuali 
"collaboratori", uno dei quali preferirebbe usare Borland C++, mentre 
l'altro sembrerebbe più orientato verso Java/Eclipse con eventuale 
nucleo scritto in C++...
Non abbiamo motivo di avere lo stesso ambiente di sviluppo per client e 
server. I due codici gireranno (sempre che il progetto che per ora è a 
livello amatoriale, vada avanti...) su architetture diverse (win/linux) 
e saranno probabilmente sviluppati da persone diverse. Mi immagino solo 
una parte di codice in comune per gestire il protocollo di 
comunicazione, e per questo vorrei mantenere C++ da ambo i lati (ma non 
sarebbe strettamente necessario).
A proposito di protocollo di comunicazione. E' veramente utile che il 
protocollo sia in formato testo? (questo viene suggerito nell'articolo 
che ho linkato qualche messaggio fa) Io avevo già in mente un formato 
binario in cui client e server si scambiano messaggi del tipo:
	data_length;  // 2 bytes
	command_code; // 2 bytes
	command_dependent_data; // data_length-4 bytes
non è sensato?
E.

protocollo sia in formato testo?
No.
Può avere una sua utilità solo per loggare, pari pari, il messaggio
ricevuto, ma è un'utilità relativa.

 particolarmente dispendioso.
Si. Il multiprocesso lo valuto sempre ma di fatto va spesso a braccetto
con l'asincrono. Sia partendo dal multiprocesso come architettura e
*dentro* ciascun processo usare una logica asincrona, sia partendo
dall'idea di stare asincroni e poi doversi trovare a scalare oltre un
tot.
-- 
-riko

Su ACE ho sentito dire molto bene [...]
Anche io. Mai usata però. Quando si è reso necessario utilizzare, per
lavoro, delle infrastrutture di questo tipo, si è ricorsi a JCA (Java
Connector Architecture), che però sia qualcosa di più alto livello
rispetto ad ACE.

 protocollo sia in formato testo?
Questo è veramente un argomento su cui sono stati versati fiumi di
inchiostro digitale, e non saprei che cosa dire di originale. E poi alla
fine si finisce sempre a parlare di SOAP e Corba. :)
In ogni caso la risposta giusta alla tua domanda è: dipende. Da cosa
dipenda, poi, nessuno è mai d'accordo.
Ma vorrei fare un passo indietro. Siete sicuri che abbia senso perdere tempo
a inventarsi un protocollo? Non c'è ne sono già abbastanza in giro? E,
soprattutto, non è meglio appoggiarsi a qualche tecnologia consolidata? In
questi giorni, ad esempio, mi sto riguardando la documentazione di ICE
(
http://www.zeroc.com/ice.html
). Sto pensando di adottarlo in alcuni nuovi
progetti interni. Dacci un'occhiata.
Max
 

 mio interlocutore, ...
Al momento, più o meno tutte le mie implementazioni di server e client sono
basati su ACE. Non saprei se parlarne male o bene. Di ACE, dico, non delle
mie implementazioni. :) 
È in sostanza l'implementazione dei vari pattern codificati da Schmitd e
compagnia bella. Io comunque ne uso solo un sottoinsieme: Reactor, code di
messaggi, e facade vari di socket.
Mi stupisco che tu non abbia citato Boost.Asio. (O forse mi è sfuggito.) Se
ti interessa la programmazione asincrona in C++, ti suggerisco di guardarti
quello, piuttosto che ACE. Come già scrissi in questo NG, Asio implementa
diversi pattern che si trovano anche in ACE (in primis il Proactor), ma è
scritto con stile e idiomi molto più moderni e si integra bene con il resto
di Boost. (Sembra che piaccia molto anche a Stroustrup, per altro.)
Max

 (con tanto di name mangling) da Java ;-)
Pero' l'idea di realizzare la GUI in C# ed il nucleo in C++ potrebbe
essere meno peregrina, dal momento che grazie a C++/CLI l'impedenza
tra C# e C++ e' decisamente minore.
La mia sensazione e' che per creare GUI C++ Builder resta piu' comodo
di Visual Studio, ma se si vuole far ricorso a Boost in modo pesante
Borland non e' realisticamente un'opzione.
Altrimenti piuttosto che Java, Python.
Ciao,
Nicola

 Visual studio, e spero che sia un buon compilatore.
...
Le ultime versioni di vc a livello di compilatore non sono solo buone, 
ma secondo me addirittura ottime (o quasi).
Dal punto di vista boost, direi nessun problema
Considera in oltre che il compilatore è gratis.
GM

 Visual studio, e spero che sia un buon compilatore.
Sostanzialmente per ogni versione del C++ Builder c'e' una versione di
Boost "migliore";
Con BCB6 non conviene andare oltre 1.31/1.32, a seconda delle librerie
utilizzate.
Coi successivi probabilmente la cosa migliore e' fare riferimento alla
versione di bcbboost corrispondente.
Boost 1.37, che e' imminente, uscira' con una serie di patch per
CB2007 e CB2009, ma per dare un'idea CB2009 ottiene circa 1350
regression test falliti, contro i 140 circa di VC++2008.
CodeGear sta facendo uno sforzo notevole, sia sul fronte del
compilatore, sia su quello delle patch per Boost, ma gli anni perduti
tra il 2002 ed il 2006 si sentono tutt'ora, anche per l'evidente
differenza di risorse rispetto a Microsoft. Peccato, perche' il lungo
intervallo tra VC++ 6.0 e VC++ 7.0/7.1 poteva essere sfruttato per
dettare il passo, almeno in termini di aderenza allo standard.
Ciao,
Nicola

 multi-threading...
Ci sono due approcci classici a questo problema, uno e` quello che ti 
hanno spiegato (staccare un nuovo thread per ogni connessione), l'altro 
e` quello di usare select() con un fd_set con collegati tutti i tuoi 
socket e un eventuale timeout e con FD_ISSET vedere su quale socket ci 
sono dati in modo da effettuare delle recv() dai socket SEMPRE non 
bloccanti (recv non e` bloccante se ci sono dati sui socket).
Su windows spesso si aggancia un event al socket in modo da poter 
utilizzare WaitForMultipleObjects() invece di select x gestire eventi 
che vengono anche da altri sottosistemi.
C'e' anche la possibilita` di settare i socket come NONBLOCKING, e non 
usare select o WaitForM... e verificare su ogni recv() il valore di 
WSALastError/errno per vedere se il socket era senza dati nel buffer nel 
caso si riceva zero...
Comunque sono domande offtopics qui, ti consiglio un gruppo su cui si 
discute di networking o magari il .win32 se vuoi informazioni specifiche 
delle tecniche da usare con winsock.
Bye,
  Gabry