I am currently implementing a software that uses a GSM terminal to perform actions. Actions can be sending messages, checking balance, receiving status report messages, setting the pin, …
The communication between terminal and program runs over a serial port. I am sending AT commands (basically strings) to the device that executes them and returns a message depending on the command. I have a limited set of about 20 different commands that need to be executed and some of them have the same return messages (just OK or ERROR). While waiting for a return value is it possible that an incoming message notification is returned instead and the actual value the program is waiting for arrives later.
I need to consider that in the future the GSM terminal shall be exchangeable easily. The AT command set is mostly standardized, but the return values can differ between manufacturers and even mobile operators…
I am struggling to find a good generic design concept. The tasks to be performed are the following:
- Check if response belongs to the command sent
- Check if response is valid (command worked or not)
The rest of the system is running well (reliable sending and receiving, timeouts, retransmit in case of errors, etc…), it’s just about verifying return values that can happen to belong to several commands sent.
I am using an event based observer system. Every time a return value is received it is published to all subscribers which will process the result. Before sending a command to the serial interface, a component registers with the observer and unregisters if its job is done. But if I have two subscribers that wait for a result and both expect OK it gets complicated.
I am on my own at the moment so I’d appreciate some help and inspiration here.
AT commands are generally not designed to be multiplexed over a single channel, so if you have sent multiple requests without waiting for the responses, it is very likely that you will get the responses in the same order as that you sent the requests (although it is better to simply wait for a final response before sending the next request).
If it is possible that you get unsolicited messages intermixed with the request/response messages, you could chain the message handlers.
If you do that, you first present a received message to the response handler of the oldest unfinished request. If that handler indicates it couldn’t process the message, you go to the next handler in the chain (the next oldest unfinished request). If you reached the end of the chain of unfinished requests, you present the message to the handler(s) for unsolicited messages.
Once any handler indicates it has processed the message, you stop the chain right there and no further handlers will get to see it. This prevents responses like OK to complete multiple requests.
This can be implemented using the Chain of Responsibility pattern, or simply as a loop over an ordered list of message handlers.
1