Home/ Questions/Q 522407
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T08:21:03+00:00

(Edited to try to explain better) We have an agent, written in C++ for

  • 0

(Edited to try to explain better)

We have an agent, written in C++ for Win32. It needs to periodically post information to a server. It must support disconnected operation. That is: the client doesn’t always have a connection to the server.

Note: This is for communication between an agent running on desktop PCs, to communicate with a server running somewhere in the enterprise.

This means that the messages to be sent to the server must be queued (so that they can be sent once the connection is available).

We currently use an in-house system that queues messages as individual files on disk, and uses HTTP POST to send them to the server when it’s available.

It’s starting to show its age, and I’d like to investigate alternatives before I consider updating it.

  1. It must be available by default on Windows XP SP2, Windows Vista and Windows 7, or must be simple to include in our installer.
    This product will be installed (by administrators) on a couple of hundred thousand PCs. They’ll probably use something like Microsoft SMS or ConfigMgr. In this scenario, “frivolous” prerequisites are frowned upon. This means that, unless the client-side code (or a redistributable) can be included in our installer, the administrator won’t be happy. This makes MSMQ a particularly hard sell, because it’s not installed by default with XP.

  2. It must be relatively simple to use from C++ on Win32.
    Our client is an unmanaged C++ Win32 application. No .NET or Java on the client.

  3. The transport should be HTTP or HTTPS. That is: it must go through firewalls easily; no RPC or DCOM.
  4. It should be relatively reliable, with retries, etc. Protection against replays is a must-have.
  5. It must be scalable — there’s a lot of traffic. Per-message impact on the server should be minimal.
  6. The server end is C#, currently using ASP.NET to implement a simple HTTP POST mechanism.
  7. (The slightly odd one). It must support client-side in-memory queues, so that we can avoid spinning up the hard disk. It must allow flushing to disk periodically.
  8. It must be suitable for use in a proprietary product (i.e. no GPL, etc.).
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    How is your current solution showing its age?

    I would push the logic on to the back end, and make the clients extremely simple.

    1. Messages are simply stored in the file system. Have the client write to c:/queue/{uuid}.tmp. When the file is written, rename it to c:/queue/{uuid}.msg. This makes writing messages to the queue on the client “atomic”.

    2. A C++ thread wakes up, scans c:\queue for “*.msg” files, and if it finds one it then checks for the server, and HTTP POSTs the message to it. When it receives the 200 status back from the server (i.e. it has got the message), then it can delete the file. It only scans for *.msg files. The *.tmp files are still being written too, and you’d have a race condition trying to send a msg file that was still being written. That’s what the rename from .tmp is for. I’d also suggest scanning by creation date so early messages go first.

    3. Your server receives the message, and here it can to any necessary dupe checking. Push this burden on the server to centralize it. You could simply record every uuid for every message to do duplication elimination. If that list gets too long (I don’t know your traffic volume), perhaps you can cull it of items greater than 30 days (I also don’t know how long your clients can remain off line).

    This system is simple, but pretty robust. If the file sending thread gets an error, it will simply try to send the file next time. The only time you should be getting a duplicate message is in the window between when the client gets the 200 ack from the server and when it deletes the file. If the client shuts down or crashes at that point, you will have a file that has been sent but not removed from the queue.

    If your clients are stable, this is a pretty low risk. With the dupe checking based on the message ID, you can mitigate that at the cost of some bookkeeping, but maintaining a list of uuids isn’t spectacularly daunting, but again it does depend on your message volume and other performance requirements.

    The fact that you are allowed to work “offline” suggests you have some “slack” in your absolute messaging performance.

    • 0