Handling errors between parellel processes that care what the others are doing

[GregFreeman]

I have a reusable communications manager I have been writing. I'd like it to be used for CAN, TCP server, TCP client, etc. Anything with Open, close, read write VIs, just inject the proper class at startup. I am using a mediator which launches an "open connection manager." When this connection manager gets a connection, it notifies the mediator, passing it the connection, who then launches a parallel reader and writer.

 

That's the gist of it at least.

 

I got it all working well for the server, but when I went to implement TCP client, I realized I was missing something big. What to do when connections are dropped. This was easy, the server doesn't care, it just listens as always, and the reader & writer will error out and close. But, with client connections, they most likely want to reconnect. With CAN, someone may want something different on a per-application basis. Has anyone managed something like this before? How do you handle it? I'm thinking some error handler with dynamic dispatch and must override will work, but I'm not entirely sure how to implement it all together.

 

____________________________________________________________________________

 

Just a more detailed view of my architecture in case it helps:

 

The mediator is passed an app specific child of "transmission" class upon startup (Transmission is an abstract class with all must override VIs, open close read write). This child class would be something like TCP client, TCP server, CAN client etc. The mediator then launches the "transmission open manager" injecting the child class in. So, essentially, your app specific class is injected on a transmission class wire into the "transmission open manager." The manager delegates to this injected class to open connections. When a particular connection is made, it is bundled up into the app-specific child of transmission class, and the class is passed to the mediator. The mediator then launches the reader manager and the writer manager, injects them each with this class and they execute the appropriate read/write VIs via dynamic dispatch. 

 

Hopefully this makes sense. It seems to work quite well, but unfortunately I cannot post the code. My idea here is similar to an HAL. If you want to add a new class, say UDP client, you just subclass transmission with your app specific UDP client class, create the must override VIs and you're done. Please ask for any clarifications if needed.

 

 

[Aristos Queue]

There's a "mini-language" approach that I've seen done. You give your child classes (TCP/UDP/CAN/etc) a method "What To Do About This Error.vi"... that VI takes the error in and returns an array of string output. Each string is a command like "Log the error", "Drop the error", "Retry Operation", "Consign The Network To The Flames Sanctum Ignious Eternum", etc. The framework then does the commands one by one (like processing a message queue in one of the string-based state machines).

 

Variations on that system abound... you can make the mini-language be an array of message classes, each of which invokes a particular method on the framework. Sometimes you can get away with having the "What To Do About This Error.vi" call methods of the framework directly, but most people don't like that because giving the child classes scope of the methods generally means the child can call methods at other times, potentially destabilizing the system. The string and msg class approaches strictly limit what the child can request and when.