views:

447

answers:

2

I've got a system i'm designing where we're using 4 specialized PC's we manufacture in house that have 16 serial ports (db-9 RS232) I need to communicate with 64 units near simultaneously (4x16) 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 buisness 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.

+1  A: 

Definitely check out the Concurrency and Coordination Runtime (CCR):

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

EDIT:

Link to download:

http://msdn.microsoft.com/en-us/robotics/aa731520.aspx

Jonathan Parker
is this a pre-bundled .net component? it's hard to tell, it looks like classes i'm already familiar with (at least i've seen) does this come with .net 3.0?
Firoso
No it's a separate download.
Jonathan Parker
+1  A: 

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 ....

Cheeso
This was a very useful and informative response, thank you. It very well is the case here that if one goes down it's not a big deal.
Firoso