Re: Application design question

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
Loading