Anton S. wrote:
> 1) In my descendant class I implement true asynchronous Connect with
> asynchronous DNS lookup before connecting.
Method DnsLookup doesn't require a custom timeout since the underlaying
winsock function uses system's DNS lookup timeout. Same for Connect
with or without DNS name.
And if method Connect is called with a DNS name it performs a blocking
DNS lookup while a Built-In timeout won't trigger at all.
> Of course, I wish to use
> built-in timeout mechanism for tracking timeouts. But descendant
> classes haven't access to necessary fields, namely
> FTimeoutConnectStartTick. And without it I have no means of
> controlling the timeout.
> There are two ways as I see it: make
> FTimeoutConnectStartTick protected or even public - like Counter
> field is - or add a parameter to TimeoutStartSampling with type
> TTimeoutReason. Inside this method when parameter is torConnect,
> FTimeoutConnectStartTick would be assigned. Or, async DNS lookup
> before connect could be implemented in TWSocket what is the best
> decision IMHO :)
I don't see it. Why do you need FTimeoutConnectStartTick?
You can do what ever you like i.e. (from memory):
MyWSocket1.TimeoutConnect := 0;
MyWSocket1.TimeoutIdle := 15000;
MyWSocket1.TimeoutStartSampling;
MyWSocket1.InDnsLookup := TRUE;
MyWSocket1.DnsLookup;
[..]
procedure TForm1.MyWSocket1DnsLookupDone(Sender: TObject;
ErrCode: Word);
begin
MyWSocket1.InDnsLookup := FALSE;
MyWSocket1.TimeoutStopSampling;
..
if ErrCode = 0 then
begin
MyWSocket1.Addr := MyWSocket1.DnsResult; //IP
MyWSocket1.TimeoutIdle := 0;
MyWSocket1.TimeoutConnect := 30000;
MyWSocket1.Connect;
end;
end;
procedure TForm1.MyWSocket1Timeout(Sender: TObject; Reason: TTimeoutReason);
begin
if MyWSocket1.InDnsLookup then
MyWSocket1.CancelDnsLookup
else if Reason = torConnect then
..
else
..;
..
end;
Or simply use TimeoutIdle only and handle the timeout according
to whatsoever state you like. You may also call TimeoutStartSampling
from the timeout event handler.
>
> 2) I have listening socket and wish to have its clients disconnected
> by inactivity timeout. Alas, the sockets created by Accept are never
> ininialized with timeout code.
Listening sockets do not connect so use TimeoutIdle in OnClientCreate
event:
procedure TTcpSrvForm.WSocketServer1ClientCreate(Sender: TObject;
Client: TWSocketClient);
begin
Client.TimeoutSampling := 5000;
Client.TimeoutIdle := 30000;
Client.OnTimeout := ClientTimeout;
end;
procedure TTcpSrvForm.ClientTimeout(Sender: TObject; Reason: TTimeoutReason);
begin
if TWSocketClient(Sender).State = wsConnected then
TWSocketClient(Sender).CloseDelayed;
end;
Or call TimeoutStartSampling explicitly from OnClientConnect.
>
> 3) I have a TTimer in my thread which owns sockets. May I use
> TIcsThreadTimer instead and would it be more effective or no
> difference?
TIcsThreadTimer is a lazy, low resolution timer, so in general no
TTimer replacement, use TIcsTimer if you need a thread-safe TTimer
replacement. TIcsTimer doesn't create a hidden window but uses
TWSocket's window to receive WM_TIMER messages, that saves
one window handle.
There are example apps. for both ICS timers in folder MiscDemos.
--
Arno Garrels
> --
> Anton
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
