Using serialization to talk between two process/applications (Inter Process Communication)

Recently I was asked the following in a Interview:

There is a process/application A which is c开发者_如何学编程onstantly getting messages every 5 Minutes (Assume)

The requirement is that there is a process/application B which needs the messages to be transferred from A.

But process/application A should make sure that the message has actually been received by process/application B.

The interviewer wanted to know how can this be implemented in C#. Can we use Serialization here?

From my understanding the best way this can be done is using message queue or pipe mechanism.

Anything that involves sending messages between processes (or, generally, even between AppDomains in a single process) has to use serialization of some kind, as ultimately the data needs to be mapped down to something that can traverse process spaces, and a "Message" is, by definition, serialized data. This serialization could be explicit or implicit (automatic, perhaps by a proxy/stub layer - although I'd prefer not).

In reality, Process/Application A cannot "make sure" that it has been delivered, since it can't enforce that the second process is running. It can, however, have some kind of callback confirmation message perhaps. A transactional message queue isn't unreasonable, but that only ensures that it gets queued - it doesn't ensure that it gets processed (ever). Personally, I'd see if a socket would be sufficient, first.

There are some possible ways for IPC in .NET:

1. Memory-Mapped Files in .NET 4
2. .NET Remoting
3. Using sockets and the loop-back (127.0.0.1)

The most easiest one is using Memory-Mapped files in .NET 4.0.
You can use serialization or any message representation format e.g. XML for messaging.
This is about IPC but if you want to make sure that where the request is sent from (process B or another process) you must use a signature mechanism.

Serialization is (in short) a process of creation of a Message. However if you're interested in making sure that the Message reaches its destination (and does it in consistent state), you should rather ask about communication protocol - that's the thing that describes how the Message will actually be sent. For example UDP protocol doesn't guarantee delivery and TCP does.

It's also worth mentioning that guaranteed delivery means that it is guaranteed that either System B receives the Message intact, or System A will be informed about a failure in delivery (when for example System B is off). That said, some Message Queues guarantee delivery as well - there's a timeout in which when a Massage in queue did not reach its destination, the Message will be marked as failed(for example by putting it in Failed Messages queue).