Architecture/design for reading incoming data and distributing it across program

Question

This may be a broad question but I have not been able to find an answer.

In my program I am communicating to a device over serial communication. The data coming through is binary, and formatted with some header/length/checksum bytes. I can decode the data fine, the part I am stuck on is what is a good practice on distributing that data to parts of the program.

In this example lets say there are 10 different message types, that the serial port can receive. Module A in the program wants Messages 1 to 5, and Module B wants messages 6 to 10.

When the serial port finds a valid message, how should it notify Module A and Module B?

Right now I am implementing it by registering callbacks for any module that wants serial data, and send the message to all modules registered, whether its for them or not. I am curious if there is a more accepted design/architecture for this type of problem.

I will have to do the same thing with CAN and ethernet devices, so wanted to try and get this implemented correctly. I am currently working in C.

Answer 1

Right now I am implementing it by registering callbacks for any module that wants serial data, and send the message to all modules registered, whether its for them or not. I am curious if there is a more accepted design/architecture for this type of problem.

What you are describing is beginnings of a publish-subscribe design pattern. The parsers which create messages from CAN and Ethernet are the publishers. The modules A and B are subscribers.

In many publish-subscribe implementations, the publishers and subscribers register with the message broker, and not with each-other. So, the publishers and subscribers are decoupled.

Answer 2

When the serial port finds a valid message, how should it notify Module A and Module B?

First, you should consider whether the message format can be adapted in such a way that makes dispatching easy. E.g. if each type of message can be given a unique ID, you can dispatch based on it without parsing the entire message. Then modules can register a callback for specific message IDs. This way you decouple both the parsing and dispatching.

If that's not viable, you may consider sending a message to each module in turn and let the module indicate whether the message was handled, e.g. by returning a boolean. This may save some CPU cycles.

However, if tightly coupling the parsing/dispatching is not a big problem, then consider the simple design of parsing and dispatching in a single place. This has the benefit that it makes the structure of (this part of) the program very clear.