I’ve got a system I’m designing where we’re using 4 specialized PCs we manufacture in-house that has 16 serial ports (db-9 RS232) I need to communicate with 64 units simultaneously (4×16) and manage the communications. Here’s the model I came up with and I’m soliciting feedback
Server: Runs on one system and coordinates client applications. Maintains a master state machine and makes sure that the clients are in lock step with that state machine. (For instance, all units do task A, when the last one reports completion, all units do task B).
Communicates via .net remoting? WCF?
Client: Can run on the same system as the server. Manages all the IO. Manages business logic for actual task execution (bad idea?) Reports status through Remoting/WCF via notification events (for instance INotifyPropertyChanged).
I’ve never worked with .net remoting or ANY sort of distributed applications so I’m a total novice at this, but I do learn quickly. Literature and community advice would be much appreciated at this point.
If I were you I would read up on distributed system design. Generally it is a bad idea to have a single point of failure in a system (one special PC is the ‘server’ and all others need to communicate to it.)
But in your case it could very well be that it does not matter.
Read up on distributed systens design.
The API you choose is not the most important thing, I’d say. First you need to plan the architecture, and the behavior you want to get in various scenarios (like one of the PCs goes AWOL.).
Just a quick reaction from reading your reqmts, I would look into a distributed pub/sub system. How you implement the pub/sub is up to you. You could use MSMQ, or WCF and WS-Eventing, or ….