delphi - Inter-process communication

Question

I have two applications: X and Y.
X is the main application and it handles a lot of XML files. It has a history of more than 10 years and half a dozen techniques have been used to store, process and handle these XML files.
Y is a debugging tool that I am developing, which can process and display XML files in a more human-readable form. Basically, it just has a collection of stylesheets that will detect the XML format and if it recognizes the format, it will transform the XML to HTML which is displayed in a TWebBrowser component.

Problem:
When Y is active, I want X to send any XML it proceses to Y for displaying purposes. But only when Y is running! If Y is not running, X just won't do anything.
The detection of Y needs to be done on any moment and needs to be fast. I've considered using TCP/IP communication but the delay caused by a missing Y is just too long. Especially since a lot of XML is processed sometimes. Same problem with named pipes and similar network-based solutions. I need to quickly determine if Y is running and available and if so, send the XML fast and then continue X.
I've also considered to make Y a COM-based application or maybe add a COM-based DLL with events that would allow the inter-process communication. The DLL solution would be interesting since it would expose a method to X to upload an XML file, then send an event to Y to process the XML. This seems to be the best option although I would also need to check if the DLL is registered or not. If not, then X can't even call it!
The application X will also be used by customers who won't receive Y or the additional DLL so in most cases, the DLL will not be registered. (As I said, it's meant to help during debugging...)

But maybe there are other options? TCP/IP is too slow, COM is a bit too complex.


X and Y will be running on the same system. Or just X will be on a system and Y is missing completely.

---

About using memory-mapped files... While practical, I need to keep in mind that most of the times, Y won't be running thus the MMF will waste memory. XML data can be up to 4 MB in size within X thus having multiple blocks of this size in-memory is a bit overkill. It can be used to send status messages between X and Y but memory is sometimes a bit of a problem with application X. And while a MMF can be connected to a physical file, I'm trying to avoid writing any temporary files altogether.
It's a good solution, but I fear not good enough.

---

Some additional explanations are in order, I think. Application X is an application which will be used for several hours, with users doing a lot of actions that translate to lots of XML data that gets processed. Application X is a desktop application that communicates with several web applications (REST), web services (SOAP) and other applications and most of this is through XML.
Application Y is just meant to peek inside the processes that X is running. Basically, X is working for 20 minutes and Y pops up. From that moment on, X should start sending XML to Y until Y disappears again or until X is terminated. In most cases, Y will just be running to capture just a small portion of the running tasks and it's possibly even started multiple times. But I might be thinking about the whole thing in the wrong direction. Maybe X should be a server with Y registering to it... It's not a real problem when Y can't find X. But X not finding Y cannot result in delays or other problems...

Answer 1

Have a look at my IPC at:

http://www.cromis.net/blog/downloads/cromis-ipc/

It is fast, free and has a setable timeout, so you can set it to a very small amount (50ms for example). Because it is very fast (typical message cycle request -> process -> response takes less than 1ms, around 0.1ms) you can have very small timeouts. It has client server build into it, so many clients are no problem. It runs threaded with task pool behind so it does not freeze your program and it has very flexible data packets to ease writing / reading the data.

As already said you can even check with other means if the debugger is running.

• Check for process
• Check for main window of the process
• Use a Mutex
• ...