Framework/approach to use for 'alerter' type applet?

Question

A client has a lashed-together 'alerter' system based around batch files and 'NET SEND' commands. He edits the batch files (adding/removing users) as necessary.

His requirements are getting a bit more complex now; he wants users to be able to drop in and out of the notifications, during the day. I got to thinking about some kind of tray icon applet that registers with a server, popping up 'toast' type alerts as necessary and allowing the user to opt-out of seeing notifications on an adhoc basis (ie, don't bother me for the next hour, don't bother me until I say otherwise, start bothering me again from now on, etc).

The kind of information in each alert is simple; 'A new contract from store 1234 has arrived', 'Store 1234 have amended a contract', 'Store 1234 have deleted a contract' etc. Just fairly short, basic text strings, really.

It's not particularly busy - there will be in the order of 5-20 alerts an hour, the point being that in this new app they can be ignored (the Net Send approach he has now requires people to click the OK button of the message box whether or not they're interested in the alert at that point in time). Having said that, there is some time sensitivity involved - looking every 5 minutes to see if there had been an alert would be no good, though perhaps once a minute might be acceptable. The number of users interested in the alerts will vary during the day (and their workload) but it's between about 2 and a dozen - we're certainly not talking hundreds of users on the system.

I've done Delphi socket apps where clients connect to a server on demand and exchange information, but I've never done anything where the clients are 'listening-to', or polling, a server. I don't know whether you would tackle this with Named Pipes, TCP/IP or some kind of Windows Network tool. (The clients and the server are all Windows 2003/XP, on the same internal network).

I'm not really sure where to start. Is this the kind of thing that the RemObjects API would help with? Can anyone recommend a useful tutorial or example that I might reverse engineer for ideas? :-)

This would be done in Delphi 2007 (or possibly 2009 with a bit of luck).

Answer 1

I understand all the recent events and talk about Web2.0 would give a feeling that there are better options, but (on a company's LAN) there still is nothing better (in my humble opinion) than plain networking like UDP or TCP sockets.

For a similar project to what you described, I've used a straight-forward TCP server component on the server (first in a little-UI app for debugging, later in an NT-service), and a TCP client with a sys-tray icon. The client keeps a connection open to the server (or to one of a list of servers, to provide some load-balancing and fail-over).

UDP doesn't handle connections, but might be a better suit for short messages like you describe. You might still benefit from a central server the clients report to when starting or stopping.

In both cases, the server, when receiving a message to broadcast, would forward it to all the clients it knows about, either by the open connections with TCP, or by the client-addresses it got start-reports from over UDP.

Answer 2

I would probably use a file based approach rather than a client server with sockets. Just put the messages into text files on a file server and read them from the clients.

Nothing beats such a solution in simplicity. Of course it does not have the buzzword capability of a dotNET services consuming allways on WEB 3.14 community app written with smaragd on rails. ;-)

Answer 3

Do I only get msgs if my computer is running? Or do I get a backlog on startup?

If you don't have to memorize missed msgs, a basic socket server-client demo is already close to what you want.

Adding a simple auto-update mechanism could make deployment easier.

Answer 4

Sound like you already have TCP/IP code lying around that you can refactor, so that may be the best way.

Another option would be to use a database for connection and message serving. I've used this for alerting in manufacturing environments where management wants instant info about production status.