Re: [twsocket] [ICS-SSL] built-in timer
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] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] [ICS-SSL] built-in timer
> 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? There is an event triggered when TWSocket send each data pacet: OnSendData which is perfect in that case. >> It would 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 think TWndConrol doesn't have to handle this message explicitely since it calls DefWindowProc for a,y message not explicitely handled and DefWindowProc will cal the callback method set by SetTiler. >> 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. What if TIcsTimer post a message to the calling component when the programmed timer event has occured ? Wouldn't this would solve all multithread issues ? -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] [ICS-SSL] built-in timer
Francois PIETTE wrote: >> Francois PIETTE wrote: >> 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? > > There is an event triggered when TWSocket send each data pacet: > OnSendData which is perfect in that case. I forgot this event completely :) I hope it's not too slow calling GetTickCount from it. >> Hmm, I see multi-threading issues, since a timer always fires in >> context of the thread where it has been created. > > What if TIcsTimer post a message to the calling component when the > programmed timer event has occured ? Wouldn't this would solve all > multithread issues ? Then TIcsTimer would have to manage a list of linked ICS-Components. When the timer fires it has to iterate thru this list. But deferencing a component pointer which might have been already destroyed (by another thread) will crash, right? You probably can make that threadsafe, however I fear it would slow down performance too much? --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] built-in timer
>>> Hmm, I see multi-threading issues, since a timer always fires in >>> context of the thread where it has been created. >> >> What if TIcsTimer post a message to the calling component when the >> programmed timer event has occured ? Wouldn't this would solve all >> multithread issues ? > > Then TIcsTimer would have to manage a list of linked ICS-Components. > When the timer fires it has to iterate thru this list. There are surely ways to design it to avoid scanning a list of components. A standard TTimer is probably not the best design either. Probably a dedicated thread could do the job, using MsgWaitForMultipleObjectsEx to make the thread sleep until the next event to be signaled. The event to be signaled can be the ID in the component list. Or something like that: The idea just pops out of my head. > But deferencing a component pointer which might have been already > destroyed > (by another thread) will crash, right? Right. Maybe could we impose that all linked component derive from TIcsWndControl and implement the required behaviour in TIcsWndControl. That is unregister the timeout from the detructor. > You probably can make that > threadsafe, however I fear it would slow down performance too much? I think not much more than using a TTimer which anyway post a message. We could also design the thing like MS do: either using a message or using a callback (which is called in the other thread context, that is the user is responsible for managing the thread concurrency). -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] built-in timer
Francois PIETTE wrote: Hmm, I see multi-threading issues, since a timer always fires in context of the thread where it has been created. >>> >>> What if TIcsTimer post a message to the calling component when the >>> programmed timer event has occured ? Wouldn't this would solve all >>> multithread issues ? >> >> Then TIcsTimer would have to manage a list of linked ICS-Components. >> When the timer fires it has to iterate thru this list. > > There are surely ways to design it to avoid scanning a list of > components. A standard TTimer is probably not the best design either. > Probably a dedicated thread could do the job, using > MsgWaitForMultipleObjectsEx to make the thread sleep until the next > event to be signaled. The event to be signaled can be the ID in the > component list. Or something like that: The idea just pops out of my > head. Wasn't the number of handles you can wait for limited to 32? --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] built-in timer
>> There are surely ways to design it to avoid scanning a list of >> components. A standard TTimer is probably not the best design either. >> Probably a dedicated thread could do the job, using >> MsgWaitForMultipleObjectsEx to make the thread sleep until the next >> event to be signaled. The event to be signaled can be the ID in the >> component list. Or something like that: The idea just pops out of my >> head. > > Wasn't the number of handles you can wait for limited to 32? MSDN says: "The maximum number of object handles is MAXIMUM_WAIT_OBJECTS minus one." Windows.pas has this: MAXIMUM_WAIT_OBJECTS = 64; So a single thread can wait on a maximum on 63 objects. So either use a separate thread for each 63 objects to wait for, or combine my solution (waitfor) with yours (linked lust or similar) to allow more objects with a single thread without having long list of items to scan. Probably using a thread per 63 objects is easier to implement. Most applications will not deal with that much _simultaneous_ timer problems. -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: "Arno Garrels" <[EMAIL PROTECTED]> To: "ICS support mailing" Sent: Sunday, July 16, 2006 4:07 PM Subject: Re: [twsocket] built-in timer > Francois PIETTE wrote: > Hmm, I see multi-threading issues, since a timer always fires in > context of the thread where it has been created. What if TIcsTimer post a message to the calling component when the programmed timer event has occured ? Wouldn't this would solve all multithread issues ? >>> >>> Then TIcsTimer would have to manage a list of linked ICS-Components. >>> When the timer fires it has to iterate thru this list. >> >> There are surely ways to design it to avoid scanning a list of >> components. A standard TTimer is probably not the best design either. >> Probably a dedicated thread could do the job, using >> MsgWaitForMultipleObjectsEx to make the thread sleep until the next >> event to be signaled. The event to be signaled can be the ID in the >> component list. Or something like that: The idea just pops out of my >> head. > > Wasn't the number of handles you can wait for limited to 32? > > --- > Arno Garrels [TeamICS] > http://www.overbyte.be/eng/overbyte/teamics.html > > -- > To unsubscribe or change your settings for TWSocket mailing list > please goto http://www.elists.org/mailman/listinfo/twsocket > Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] UDP Concept doubt
> Now I got it UDP packets are not fragmented at the application level, but you may get duplicates, or miss some packet, recieve the packets in incorrect order. Those conditions are very difficult to reproduce on a small LAN. You have to have a large LAN with different speed in different subnet and have several routes between points A and B. You are likely to get the problems on the internet when communicating between systems with long routes between them (Use tracert to know). It is much easier to deal with TCP fargmentation than to deal with the unreliable (by design !) UDP protocol. The only interesting features are broadcast and multicast capabilities UDP has an TCP lacks. Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: "Éric Fleming Bonilha" <[EMAIL PROTECTED]> To: "ICS support mailing" Sent: Tuesday, July 04, 2006 1:44 PM Subject: Re: [twsocket] UDP Concept doubt > Thanks Dan!!! > > Now I got it > > Thanks!!! > > - Original Message - > From: "Dan" <[EMAIL PROTECTED]> > To: "'ICS support mailing'" > Sent: Monday, July 03, 2006 7:11 PM > Subject: Re: [twsocket] UDP Concept doubt > > > UDP packets can be fragmented at the IP level, but once you do a receive > you > will receive the full datagram so you don't have to worry about it. A > problem you may run into though is that of WSockets default buffer not > being > big enough for a full size UDP packet... you might have to set the buffer > higher than the default if you aren't receiving the full datagrams. > > Dan > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Éric Fleming Bonilha > Sent: 03 July 2006 13:42 > To: twsocket@elists.org > Subject: [twsocket] UDP Concept doubt > > Hello Everyone! > > I´m in doubt in some aspects of UDP. > > Do UDP suffers from fragmentation like TCP? what I mean is that in TCP if > I > send a chunck of data, it is not guaranteed that this data will be > received > in a single event correct? It is guaranteed that it will be delivered > completed and in order, so we have to implement packet boundaries on the > application protocol. > > I would like to know if I send packets of data in UDP it will be > fragmented > too, because if it is, than an application protocol that will use UDP as > underling layer will have to implement some packet boundaries mechanism. > > I´m asking this because of the RTP (Real Time Protocol) protocol, I´m > currently developing an application that will have to parse RTP packets, > but > on RTP specification there is no packet boundaries. On the specification > is > only said that one RTP packet should be sent on one UDP packet, but I´m > thinking if UDP packet will be fragmented and will be received in one or > more events on ICS > > Thanks a lot > > Éric Fleming Bonilha > -- > To unsubscribe or change your settings for TWSocket mailing list > please goto http://www.elists.org/mailman/listinfo/twsocket > Visit our website at http://www.overbyte.be > > > -- > To unsubscribe or change your settings for TWSocket mailing list > please goto http://www.elists.org/mailman/listinfo/twsocket > Visit our website at http://www.overbyte.be > > -- > To unsubscribe or change your settings for TWSocket mailing list > please goto http://www.elists.org/mailman/listinfo/twsocket > Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
