"F Alvarado" <f.alvarado@brainsoftware.net> wrote in message
news:478b1ca6$1@newsgroups.borland.com...
> Martin:
> You said you have used dozens of TidTCPClients without problems...created
> them in the constructor...
> Are you using one or several per application?
All in one app.
Can you show me an example
> of this approach?
Not on this machine at the moment - all my examples are at home. Maybee
something like this,(some pseudocode):
TclientThread=class(TThread)
private
FhostName:string;
FhostPort:integer;
clientSocket:TidTCPclient;
aReplyWasRxForTheLastPoll:boolean;
protected
procedure execute; override;
public
constructor create(hostName:string;port:integer); reintroduce;
procedure terminate; reintroduce;
end;
constructor
TclientThread.create(hostName:string;port:integer;pollTimeout:DWORD);
begin
inherited create(true);
FhostName:=hostName;
FhostPort:=port;
clientSocket:=TidTCPclient.create(nil);
clientSocket.readTimeout:=pollTimeout;
freeOnTerminate:=true;
end;
procedure TclientThread.execute;
var PDU:TprotocolUnit;
rxData:string;
rxIndex:integer;
awaitingResponse:boolean;
begin
try
PDU:=TprotocolUnit.create;
while not terminated do
begin
try
clientSocket.connect;
try
clientSocket.write(pollRequest);
aReplyWasRxForTheLastPoll:=false;
rxData:=clientSocket.read(serverResponse);
for rxIndex:=1 to length(rxData) do
begin
if PDU.processInputChar(rxData[rxIndex]) then
begin
PDU.errorMessage:='';
postMessage(formHandle,WM_APP,0,integer(PDU));
PDU:=TprotocolUnit.create;
aReplyWasRxForTheLastPoll:=true;
end;
end;
finally
clientSocket.disconnect;
end
except
on TidReadTimeout do
begin
if (not aReplyWasRxForTheLastPoll) then
begin
PDU.errorMessage:=e.message;
postMessage(formHandle,WM_APP,0,integer(PDU));
PDU:=TprotocolUnit.create;
end;
end;
on e:exception do
begin
PDU.errorMessage:=e.message;
postMessage(formHandle,WM_APP,0,integer(PDU));
PDU:=TprotocolUnit.create;
end;
end;
end;
finally
clientSocket.free;
end;
end;
> Also, my protocol is very work intensive, it sends/receives data in a fast
> series of 5-6 secs, something like this:
> Disconnect->Change Host/Port->Connect->Send Data->Receive
> Data->Disconnect...
Well, continual connect/disconnect is not at all good for overall
throughput. If your protocol can handle it, you should remain connected so
that the latency of the 3-way and 4-way handshakes involved in
connect/disconnect are avoided. C/D protocols are a real performace-killer
and only really justified if the number of clients is much larger than the
number of sockets that can be handled, eg. web servers.
> Do something else for about 3-4 mins
If the comms is threaded off, it does not matter what else your app is
doing, within reason.
> Disconnect->Change Host/Port->Connect->Send Data->Receive
> Data->Disconnect...
> ...and so on, all day long...
> there is no need to wait for Server's response: it's very fast...
You have to wait for the server response - it's inherent in your protocol as
you describe it! You might not have to wait for long, but you have to wait.
> Which version of Indy are you using?
9,10 - have used both. Multiple clients work fine.
Rgds,
Martin
