Handling Timeouts with Awesome Indy...
Laurie
I've decoded this much:
IdSocketHandle.Readable is the ultimate read from the WinSock.read dll.
It takes a timeout
parameter. It appears that the timeout value can be specified in the ending
client/server
component, for example TIdHttp.DoRequest calls ReadLn, but chooses not to
specify any timeout
parameter. Unfortunately, the timeout is not exposed to the actual user of
the Http or FTP component.
In previous WinSock solutions, I've used setsockopt() to set the timeout,
and the equivelant for Indy is something like this:
procedure SetTimeout(ABinding: TIdSocketHandle; timeinms: integer);
var
timeInMilliseconds:DWORD;
begin
timeInMilliseconds := timeinms;
// Set the send and receive timeout
ABinding.SetSockOpt(SOL_SOCKET,SO_RCVTIMEO,pchar(@timeInMilliSeconds),
sizeof(DWORD));
ABinding.SetSockOpt(SOL_SOCKET,SO_SNDTIMEO,pchar(@timeInMilliSeconds),
sizeof(DWORD));
end;
Unfortunately, you have to have connected to get the ABinding
(TIdHttp.Binding) to
be valid. But you don't have a binding untill you do the
TIdHttp.Get('url'), which is a
bit late, maybe something like
http.Connect
SetTimeout(http.Binding);
http.Get('http://....')
which I haven't tried yet. Seem's very inelegant. Which leaves me
back with OnTimer() etc.
Seems weird that so much of the Indy library passes the Timeout value all
the way from TIdHttp
all the way through 6 objects: i.e.:
http.Get('http://.....');
procedure TIdHTTP.DoRequest(.. AURL: string ..);
function TIdTCPConnection.ReadLn(const ATerminator: string = ''; const
ATimeout: integer = IdTimeoutInfinite): string;
function TIdTCPConnection.ReadFromStack(... const ATimeout: integer =
IdTimeoutInfinite...): integer;
function TIdSocketHandle.Readable(AMSec: Integer = IdTimeoutDefault):
boolean;
function TIdStackWinsock.WSSelect(ARead, AWrite, AErrors: TList; ATimeout:
Integer): Integer;
The timeout get specified all the way through the chain, expect is not
specifiable by the user of the end component .. TIdHttp.
There must be an elegant solution for such a powerful & featured library?
Perhaps a TIdTimeout component like TIdAntiFreeze to specify timeouts for
each protocol?
Perhaps TIdHttp.Get() need an overloaded version with a timeout?
Perhaps TIdHttp needs a Timeout property?
(Same for FTP component also?)
i.e. TIdHttp.Get(AURL: string; const ATimeout: integer =
IdTimeoutInfinite);
..Laurie
Kudzu - Team Indy
>component, for example TIdHttp.DoRequest calls ReadLn, but chooses not to
>specify any timeout
>parameter. Unfortunately, the timeout is not exposed to the actual user of
>the Http or FTP component.
Not yet. In Indy 8.1 it will likely appear sometime. ReadLn does allow for a
tiemout, just pass it as a param.
>In previous WinSock solutions, I've used setsockopt() to set the timeout,
>and the equivelant for Indy is something like this:
It only works in Winsock 2.0.
--
Chad Z. Hower (Kudzu) - Church Hill, TN - Team Indy
"Programming is an art form that fights back"
Forget the Y2K problem, Lets fix the W2K problem.
http://www.pbe.com/Kudzu/ - Free Delphi/CBuilder components and articles