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