I want to split a C++/CLI application on two parts :
1. Communication Part, with I/O + logging on text file :
3 COM Ports, 2 sockets and 1 log file
2. UI Part, to handle the data received from COM Ports, sockets etc…
For the moment, my application is constantly reading from all COM Ports (with some writing when needed), communicating with 2 servers (sending and receiving) and logging all data received from these modules.
The UI is also pretty complex, but it's not relevant for my problem.
Now, I want to separate the communication parts of the program, mostly because of the limitations of the COM ports (1 connection at the same time), to be able to use them on multiple programs.
The communication part must be multithreaded so it can communicate with all the modules, and run all the time (as a service ?).
I read about WCF (because this application was made with .NET Framework), but I'm not sure about this solution : It should run on a low configuration (Intel Atom @1.66GHz, 2GB RAM, Windows XP Embedded, .NET Framework 4.0).
Can I try to learn WCF to work something out, or should I find another solution because of the low configuration ?
Ideally, I want to build a program that will be able to trigger some events to the UI part.
Best Answer
I'm currently working on a complex piece of software that seems similar to yours that uses WCF rather successfully. When the WCF application is run outside of a web server environment its called self hosting, and I suggest you avoid all the service reference generation tools that Visual Studio provides and configure your server and client manually. It's much easier to maintain and once you get a configuration that works for you its pretty simple.
However, if you do have performance concerns (which would make sense given your hardware) and seeing that half of your application is C++, I'd recommend named pipes. Named pipes have been around for a while, and in Windows they are treated by the OS similar to an in-memory file stream that both processes can read and write to, so they are pretty quick.
To get the best of both worlds (or a compromise of both, depending on your viewpoint ;)) WCF provides a named pipe binding, though I've never used it.
Also note this question has been asked before:
https://stackoverflow.com/questions/712882/wcf-performance-net-tcp-versus-namedpipes
https://stackoverflow.com/questions/84855/what-is-the-best-choice-for-net-inter-process-communication