Francois PIETTE wrote:
>> I would also vote for a built-in timer since any server needs to
>> perform some tasks periodically, so probably deriving from
>> TComponent plus a window receiving timer messages is a good choice.
> Most communication application and many other needs to perform some
> task periodically as well as handle all kind of time out. 

Concerning a client idle timeout in a server application/component 
where would you refresh client's last alive time stamp? It's clear to
refresh it in OnDataAvailable, but that is not enough, it has to be
refreshed also when data is being sent. Should I use/override TryToSend
for this purpose? What if someone would put 2GB into the send buffer? 

> It wouyld
> be usefull to add a general purpose timer component able to do a lot
> of tasks, centralized in a single component. 

I see some problems with V6, since TWndControl does not handle WM_TIMER
messages by default. Such timer should not create a window but attach
to an existing window.

I currently derive a server from TComponent and create a window that is
used for WM_TIMER and other component messages (makes it easy to
ThreadAttach/ThreadDetach the component/timer). If you want to preserve
an option to run non-WSocket-events, and listening as well as client
sockets all in different threads such design appears to be OK.  

> A single TIcsTimer
> component is enough in an application if correctly designed. All
> other components needing a timer could be linked to this TIcsTimer,
> much like many data-aware components are linked to a single
> datasource component or many SQL-Query type component are linked to a
> single database connection component.

Hmm, I see multi-threading issues, since a timer always fires in 
context of the thread where it has been created. 
> This discussion should probably be moved to the twsocket mailing
> list. Isn't it ?

Arno Garrels [TeamICS]

To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at

Reply via email to