Re: [twsocket] Built-in timeout questions
Thanks Arno, I followed your advices and successfully solved both issues. Regarding timer I'll try ThreadTimer as I don't need precise resolution here -- 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
Re: [twsocket] Built-in timeout questions
Regarding accepted sockets: that's how I solved the problem for now: procedure TServer.TriggerClientConnect(Client: TWSocketClient; Error: Word); begin inherited; if Error 0 then Exit; with TSrvClient(Client) do begin TimeoutSampling := 1000; TimeoutConnect := InactiveTimeout; TimeoutIdle := InactiveTimeout; OnTimeout := ClientTimeout; TimeoutStartSampling; Counter.SetConnected; // -- init Counter manually end; end; This good method might be called in TimeoutStartSampling after Counter creation when state is wsConnected, and after socket accepting too. -- 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
Re: [twsocket] Built-in timeout questions
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 := 3; 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 := 3; 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
Re: [twsocket] Built-in timeout questions
2Arno 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. Yes, this is blocking DNS lookup which I want to avoid. And I dislike relying on OS timeouts, maybe it'll be 5 minutes long? You can do what ever you like i.e. (from memory): Thanks! I'll examine the snipped you provided! Listening sockets do not connect so use TimeoutIdle in OnClientCreate event Ah, the trick is not using connect timeout! I've got it. 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. Well, I want this timer to execute periodical and not time-precise tasks so resolution of GMinIcsTimerResolution : Longword = 100; is far than enough. And regarding TIcsTimer, would it work if there's no any TWSocket object created yet? -- 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
Re: [twsocket] Built-in timeout questions
Yes, this is blocking DNS lookup which I want to avoid. And I dislike relying on OS timeouts, maybe it'll be 5 minutes long? There is nothing you can do to speed-up or stop the DNS or connection timeouts, they are specified in the registry. Even if you abort the component on a timer, you can not re-use the socket for another connection until the original Windows timeouts expires. I suspect that only one DNS look-up is done at a time, and multiple look-ups are queued, but this may be OS dependent, and I could be wrong. Using dozens or hundreds of sockets gets around the OS timeout issues. The best you can do is ping the remote IP first, because ping can be timed out in five seconds or something sensible. But this not always work across the public internet due to firewalls blocking ping. Angus -- 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
Re: [twsocket] Built-in timeout questions
Anton S. wrote: 2Arno 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. Yes, this is blocking DNS lookup which I want to avoid. Note that it won't work faster with many calls from different instances since winsock internally serializes the lookups. If you need parallel lookups you have to use multiple threads. In the IPv6 branch I implemented something like that, little demo exists as well. And I dislike relying on OS timeouts, maybe it'll be 5 minutes long? Most likely not, have a look here: http://technet.microsoft.com/de-de/library/cc977482%28en-us%29.aspx You can do what ever you like i.e. (from memory): Thanks! I'll examine the snipped you provided! Listening sockets do not connect so use TimeoutIdle in OnClientCreate event Ah, the trick is not using connect timeout! I've got it. Sorry, I meant that accepted sockets do not call Connect. And regarding TIcsTimer, would it work if there's no any TWSocket object created yet? No it requires an owner of type TIcsWndControl or descendant. -- Arno Garrels -- 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
[twsocket] Built-in timeout questions
Hello all, recently I've started migrating from my own timeout-featured TWSocket descendant towards the ICS built-in timeout. First of all, thanks to Arno for implementing this feature! Usage is quite simple and most of the questions could be answered by reading the code but some things are still lurking in the dark. Here are my questions: 1) In my descendant class I implement true asynchronous Connect with asynchronous DNS lookup before connecting. 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 :) 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. Of course, I may execute their TimeoutStartSampling manually but then another issue is revealing: TimeoutStartSampling creates Counter but doesn't init it, leaving its fields empty. So in case when client is connecting but sends or receives nothing, it is timeouted immediately! So I guess there should be FCounter.LastSendTick := _GetTickCount after CreateCounter. Regarding accepted sockets I guess some additions should be made too (for example, copying timeout fields from Server to newly created socket) but it's not so critical. 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? -- 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
