Sharing Data between 2 applications

Where did I say "language nobody else uses"? You said "it's different from everyone else's" and I replied with "probably using it incorrectly".

Use of the correct terminology is critical to getting assistance. If no one understands what you need, you will be very lucky if you get a useful answer.

A possible alternative to MSMQ is Background Intelligent Transfer Service (BITS). I am still not sure what your requirements are, but BITS is used for many things; for example, I think BITSis used by Windows Update to download updates.

Dear Sam,
Please accept my apologies if my reply offended you. I had a resource discussing the problem, and I got this term from it. However, I went back to it to check, and found out that I was wrong and that the term used to describe my case is different than "synchronous".
So, I admit that I was wrong, but I still believe that describing someones' question as a "language nobody else uses", is inappropriate for somebody trying to help.
Thanks for helping

You won't get much help with that attitude. I am familiar with the term asynchronous and you are probably using it incorrectly. Can you find an example use of the term in the manner you are using it? See Synchronous and Overlapped Pipe I/O; it says that pipes can perform I/O "either synchronously or asynchronously". Therefore your statement that pipes cannot be asynchronous is incorrect. See also Asynchronous serial communication; in "Asynchronous start/stop operation" it says "the sender and receiver must agree"; in other words, there is both a sender and a receiver executing for the asynchronous operation. See also Asynchronous I/O; in "Implementation" it says that most implementations of I/O uses either polling or interrupts, both of which require a program at both ends.

Believe me I didn't invent the word "asynchronous".. it's the term used in this context, and if it's different from your definition, then it doesn't mean that it's different from everyone else's.

Perhaps your definition of asynchronous is different from everyone else's. You say "applications might be turned off" and if I understand what you are saying then that is not what asynchronous is. I am only vaguely familiar with MSMQ but I assume you are saying it could work because it will (if it does) store the data until your application is ready for it. Is that what you mean? I cannot help much more but I think you will have better success finding what you need if you are more clear about what you need.

The bid disadvantage of Remoting, Piping and Sockets in my case is that I need an asynchronous way which they don't provide. One of the 2 applications might be turned off while the other application is sending/writing data.
Plus, there's a considerable performance issue in here. My case might include many start/kill for the applications/processes and therefore many construction/deconstruction in the case of the sockets.
In the case of Remoting, each call of the wanted procedures implies many protocol messages back and forth between the 2 processes and therefore an unnecessary overhead.
That's how I see it, please correct me if I'm wrong.
However, the shared memory idea sounds reasonable, I'll start reading about it.

Remoting, Piping and Sockets do not use the file system so I don't understand the problem. A very common alternative is shared memory but since I don't know why you don't want to use Remoting, Piping or Sockets I don't know if shared memory would be better.
 

You can use xml because its very light and it ll work fine.