Re: Application design question

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Hi Larry,

Thanks for the info...

With how you describe it, doesn't the 'scheduler' (for want of a better
word) poll the DB to raise the events?

Also, any links on anything I can read up about this would be very much
appreciated. Naturally, from an ASP.NET background, the event is driven from
the client rather than the server (same situation as polling). If the server
is pushing instead, I have a whole new way of programming to learn (i
guess).

--
Best regards,
Dave Colliver.
http://www.AshfieldFOCUS.com
~~
http://www.FOCUSPortals.com - Local franchises available


"Larry Smith" <_nospam@xxxxxxxxxxxx> wrote in message
news:eqKARyE5JHA.4116@xxxxxxxxxxxxxxxxxxxxxxx
I am coming from an ASP.NET background into a windows (and windows
mobile) application project. (The project is currently being scoped, but
my skills may be required.) The project will be written in C# and will
use a variety of platforms (Windows, Windows Mobile, Web Services,
ASP.NET etc.)

The application will be presented on two large plasma displays and will
need to provide real time information. If you imagine where you have seen
the bankers in the trading room, you have the screens in front of them
providing real-time share prices. Now my app will be different, but it is
the real-time nature that I need to consider.

There will also be screens for the desks... the plasma displays are
mainly for an overview, like a call center, the desk screens are actually
the interactive part of the whole project.

In the trading room example, the screen is updated and things start
flashing etc.

How is the updating managed (or how should it be managed). My app will
have a database backend. Does the screen just continually poll the
database or use some other method to manage the screen? If so, what does
it do?

Also, from a loading perspective, when I design my app, if for example it
is polling the DB, how often should I poll? (I know the question is a
little open ended, but what I am concerned about is potential load... I
want it often enough to look like real time, but not too often that
everything grinds to a halt.

Finally, when developing something like this, is there anything else that
I should consider?

Polling is normally very inefficient. It's a waste of time sending in
requests for data that might not have changed. That might not apply in
your case however if the data is changing so frequently that if you did
poll, you're guaranteed to get fresh data each time. It's also easier to
code than an event driven system (since the server doesn't have to track
clients - read on) but the latter is often the way to go. Consider for
instance a system where clients can register with the server (running on
your backend) to receive data every X seconds (or whatever granularity you
want) but only if the data has changed since the last time they received
something (note that they'll pass in X accordingly but this can even be -1
to request all changes in real time). For example, a given client could
connect to the server and say something like, "fire me a data change event
every 5 seconds but only if the data actually changed since the last time
I received it". The server would then keep track of these requests and
everytime the data changes, it would fire the event to each waiting client
accordingly (you can then update your "desk" and "plasma" monitors). For
some clients however there will be a delay before the event is fired based
on the time that was requested. For instance, if they were last notified 2
seconds ago then based on a requested 5 second delay, you would have to
wait 3 more seconds before firing the event. OTOH, if 7 seconds has
elapsed because the data hasn't changed for that long then you would have
to fire the event immediately (to that particular client and any others).
The devil is in the details of course (mostly on the server side) but it's
not that difficult. Just make sure you code it efficiently on the server
side in particular. It shouldn't waste time continuously checking which
clients need to be notified in some ongoing loop for instance. It should
be scheduled as efficiently as you can. Also, I strongly recommend writing
(or purchasing) this as a generic scheduler component (object) first (one
that can fire events based on changes to any arbitrary data source) and
then construct a scheduler for your specific data source (DB) on top of
this. Your DB scheduler shouldn't be wired to the same machine as the DB
itself however so you can move it to another machine if ever required. A
server would have to be written for the DB machine however to fire events
whenever the required data changes (your scheduler can connect to this
even if located on another machine). In any case, caution advised about
relying on the system clock to do your scheduling, assuming you're going
to implement this by tracking the last send time for each client (as one
potential way). Someone might change the clock so relying on system ticks
or some other mechanism should be considered (but also consider what
happens if the machine goes down).

This is certainly more difficult to implement than having clients
continously request data every X seconds but it's cleaner IMO and I would
probably go with it instead (if you have the time and the $). Ultimately
I'm not familiar with your own situation though (or your precise
requirements) so exercise caution before adopting this or any other
solution (from a stranger on the Internet no less).



.

Relevant Pages

  • Re: Server process stalled during massive thread creation : scheduler problem ?
    ... i just realized a behaviour of the scheduler that gets me thinking... ... i run a server process that accepts ... TCP connections, and after a client has connected, just echoes all the ... When the load generator starts 1000 threads simultanously, ...
    (Linux-Kernel)
  • Re: [CFT][PATCH] new scheduler policy
    ... >> server starts executing requests from the client with the smallest ... Each client has a buffer which is used to read some ... >> unusually large requests, but is typically 4KB. ... > There are still regressions in the CPU scheduler though. ...
    (Linux-Kernel)
  • Re: ANN: dbGonazles database for Delphi, Kylix and C++Builder
    ... Adem schrieb: ... The poll shouldn't cause this load. ... > server from the client every x miliseconds. ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: Select/Poll
    ... In fact, both poll() ... I'm using select in a server to read ... > loop on these FDs and the server maintainig those FDs is not able to get ... Some of the last messages sent by each client are lost. ...
    (Linux-Kernel)
  • Re: Polling Email at ISP
    ... If a client PC or user is not logged on the network will the server still ... poll this account at the ISP? ... It's stored on the server, ...
    (microsoft.public.windows.server.sbs)