Communication between programs in .NET

Question

Hi,

I want to separate modules of my program to communicate with each other. They could be on the same computer, but possibly on different ones.

I was considering 2 methods:

1. create a class with all details. Send it of to the communication layer. This one serializes it, sends it, the other side deserializes it back to the class and than handles it further.
2. Create a hashtable (key/value thing). Put all data in it. Send it of to the communicationlayer etc etc

So it boils down to hashtable vs class.

If I think 'loosely coupled', I favor hashtable. It's easy to have one module updated, include new extra params in the hastable, without updating the other side.

Then again with a class I get compile-time type checking, instead of runtime.

Has anyone tackled this previously and has suggestions about this?

Thanks!

edit: I've awarded points to the answer which was most relevant to my original question, although it isn't the one which was upvoted the most

Answer 1

It sounds like you simply want to incorporate some IPC (Inter-Process Communication) into your system.

The best way of accomplishing this in .NET (3.0 onwards) is with the Windows Communication Foundation (WCF) - a generic framework developed by Microsoft for communication between programs in various different manners (transports) on a common basis.

Although I suspect you will probably want to use named pipes for the purposes of efficiency and robustness, there are a number of other transports available such as TCP and HTTP (see this MSDN article), not to mention a variety of serialisation formats from binary to XML to JSON.

Answer 2

What ever happened to the built in support for Remoting?

http://msdn.microsoft.com/en-us/library/aa185916.aspx

It works on TCP/IP or IPC if you want. Its quicker than WCF, and is pretty transparent to your code.

Answer 3

One tends to hit this kind of problem in distributed systems design. It surfaces in Web Service (the WSDL defining the paramers and return types) Messaging systems where the formats of messages might be XML or some other well-defined format. The problem of controlling the coupling of client and server remains in all cases.

What happens with your hash table? Suppose your request contains "NAME" and "PHONE-NUMBER", and suddenly you realise that you need to differentiate "LANDLINE-NUMBER" and "CELL-NUMBER". If you just change the hash table entries to use new values, then your server needs changing at the same time. Suppose at this point you don't just have one client and one server, but are perhaps dealing with some kind of exchange or broker systems, many clients implemented by many teams, many servers implemented by many teams. Asking all of them to upgrade to a new message format at the same time is quite an undertaking.

Hence we tend to seek back-comptible solutions such as additive change, we preserve "PHONE-NUMBER" and add the new fields. The server now tolerates messages containg either old or new format.

Different distribution technologies have different in-built degrees of toleration for back-compatibility. When dealing with serialized classes can you deal with old and new versions? When dealing with WSDL, will the message parsers tolerate additive change.

I would follow the following though process:

1). Will you have a simple relationship between client and server, for example do you code and control both, are free to dictate their release cycles. If "no", then favour flexibility, use hash tables or XML.

2). Even if you are in control look at how easily your serialization framework supports versioning. It's likely that a strongly typed, serialized class interface will be easier to work with, providing you have a clear picture of what it's going to take to make a change to the interface.

Answer 4

You can use Sockets, Remoting, or WCF, eash has pros and cons.

But if the performance is not crucial you can use WCF and serialize and deserialize your classes, and for maximum performance I recommend sockets