views:

143

answers:

5

I have a Delphi 2006 app that gathers data and displays it as a summary of many channels, one channel per row on a TDrawGrid. I have the same app running on various other PCs on the network, but these other PC's are slaves - they don't gather data but merely provide a remote display of the summary.

At present, the slaves just show a mimic of the summary display screen on the master, and this is implemented via broadcasts by way of mailslots from the master.

I want to implement this in a different way, to reduce the load on the master, and provide the slaves with a bit more flexibility and independence on how they interpret the data. Also, I am having issues with mailslot broadcast of the data across subnets.

Can I use some shared memory scheme to lay the data down to a memory-mapped file where the slaves can have access from anywhere (over the web, even)? We are talking about a memory size of 100k bytes max, say, updated by the master at around once per second, probably in a thread, to keep the master foreground task responsive.

+2  A: 

You could use a database such as DBISAM, Firebird, etc.. With DBISAM, I've used a trick of reading the first 8 bytes of the database file which seems to be a header. If it changes, I know that the data in the table has changed, otherwise it hasn't. You can utilize this in the client if you use a polling loop, or if you want to continue to use the mailslots as a notification method. i.e. poll the file every 10 seconds or upon mailslot notification, whichever comes first.

Chris Thornton
A: 

We use MSMQ for something similar.

Serge Dubovsky
+4  A: 

Shared memory won't work over web (unless you run VPN) and it doesn't work well over network in general (views can be desynchronized and you can't synchronize them across network).

I can see several solutions to your task:

Option 1. Use message-oriented middleware (MOM), such as MSMQ, kbmMW, our MsgConnect to broadcast notifications which include only changes in your data. This way the clients won't need to poll the server additionally for data snapshot. All MOM solutions use TCP connections for operations and this is more reliable than mailslots.

Option 2. Use some client-server DBMS, probably the one which supports notifications to clients (I am not an expert in DMBS so I can't tell you the names).

Eugene Mayevski 'EldoS Corp
+2  A: 

What's wrong with using TCP/IP? You can use Indy (ships with Delphi already) or ICS to have your main (master) app respond to IP requests (eg., HTTP or ICMP or whatever suits your needs for data) with a thread or two, and have the "slave" apps just request the data via the IP address of the master on a specific port. This would work on an intranet or via the internet transparently.

Ken White
+2  A: 

The simplest way is using a file on a share that the master writes to and the slaves only read. Some kind of synchronization might be necessary, if you want to prevent "dirty reads". On the other hand, it might not matter, depending on the kind of data you want to display.

Using a simple file has the advantage that it does not require any additional software (e.g. a daetabase server or some middleware) following the KISS principle. But of course it is far from sexy ;-) and does not use the correct buzzword technology.

dummzeuch
Wouldn't standard windows file access mechanisms prevent dirty reads? Occasionally the slave wold not be able to get the data but that would be no real problem. Dirty reads would not matter, as they would be replaced on the next poll of the master anyway. Presumably, read and write disk caching at the master would mean that the majority of accesses to the file would be a read from or a write to memory anyway?
@user89691: That depends on how the file is opened and whether any locking mechanisms are used. The simplest way is for the master to open the file write / allow read and the slaves readonly / allow read/write. But that would allow dirty reads. Other open flags could prevent dirty reads but then both sides must handle access denied errors.
dummzeuch
What exactly is a dirty read then? Are you saying that if the master was in the process of updating the file "write/allow read" and the slave read it, the slave might get half the old data and half the new data? I thought the operating system at least kept record writes as atomic. If it doesn't, would an adequate locking mechanism be to open the file as "Write/deny read", update the data, close the file (and make the slave cope with the times it coudlnt get the data)?
@user89691: Yes, "dirty read" means while the master writes to the file a slave reads it and gets data that is part old and part new. The OS does not keep record writes atomic because it does not know about records. I guess it keeps writes of some size atomic if written in one go (maybe a 4k block), but I am not sure. Yes, Open "Write/Deny Read" and Close would be a locking mechanism but only if the slaves use Open "Read/Deny Write" and then the master must also cope with open failures. Otherwise (Open read/deny none) would result in potential dirty reads again.
dummzeuch