Design Guidelines : Polling vs Events
-
Hi, I was wondering if there are some guidelines regarding the following issue in the .NET framework: Polling based design (the client polls the server every X interval for changes) Vs. Events driven design (the client registers to the event and the server will raise the event)? i am not sure when to use each of the above...
-
Hi, I was wondering if there are some guidelines regarding the following issue in the .NET framework: Polling based design (the client polls the server every X interval for changes) Vs. Events driven design (the client registers to the event and the server will raise the event)? i am not sure when to use each of the above...
There is an alternative: Observers. Polling requires significant effort to keep state in sync so that you can keep track of changes. Events are good, but do require that items subscribe to the events to keep track of them.
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before. -
Hi, I was wondering if there are some guidelines regarding the following issue in the .NET framework: Polling based design (the client polls the server every X interval for changes) Vs. Events driven design (the client registers to the event and the server will raise the event)? i am not sure when to use each of the above...
In my experience, this depends greatly on the thing being interfaced with and the platform. For example, some hardware devices support interrupts and can raise an interrupt when something happens, and then data can be read from the device. Some others do not support interrupts and need to be polled (rapidly) so that any data is not missed. It may also depend on your platform. If targeting an battery-powered platform (or working with a battery operated device), polling can greatly reduce battery life over an interrupt-based approach. For what you suggest above, I would have clients register with the server and have the server fire off events as required. This is less work all around in the long run - network traffic only exists when something is actually happening, and the server is not going to be chewing up CPU cycles by always answering "no" each time a client connects and asks "is anything available?". Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!) -
Hi, I was wondering if there are some guidelines regarding the following issue in the .NET framework: Polling based design (the client polls the server every X interval for changes) Vs. Events driven design (the client registers to the event and the server will raise the event)? i am not sure when to use each of the above...
Depends actually, polling introduces a latency , which is equal to polling interval. event's on other hand are instantaneous, so it depends whether a latency is accepted or not.