I'm developing a protocol to integrate with a third-party SDK, which continuously sends "Active" or "Busy" messages on port 7001. Commands are also sent to the SDK on port 7001, and responses are received on the same port.
The protocol I’ve developed is able to send commands successfully. However, I’m facing an issue where the incoming "Active" or "Busy" status messages are interfering with the expected command responses. Since these status messages are received on the same port, I’m unable to reliably determine whether an incoming message is a command response or just a regular status update from the SDK.
To handle this correctly, I need to check the SDK’s status based on these "Active" or "Busy" messages. If the SDK is "Busy", it will not accept any commands. It will only accept commands when it is "Active". Therefore, I need to trigger command execution only upon receiving an "Active" message.
Additionally, I need to send multiple commands, each with a separate response structure. I’ve already written a parser that handles and matches each response to its corresponding command. However, since the SDK continuously sends "Active" or "Busy" messages, the system is prematurely interpreting these status messages as responses and moving forward without actually waiting for the real command response.
Dear Dojo Community,
I went through the documentation and I found below link but I didn't find the way how to do that in protocol xml, could you please help me.
https://docs.dataminer.services/develop/devguide/Connector/ConnectionsSmartSerialCommonPitfalls.html
:::::Handling both unsolicited messages and command-response pairs:::::
When handling both unsolicited messages and command-response pairs on the same connection, it is important to be aware of when unsolicited messages can enter. If these can enter simultaneously with a response that belongs to a command, the pair tag should only contain the command (no response). To receive the response, handle it as if it is an unsolicited message, and then determine if it is your expected response or an actual unsolicited message.
This is necessary because it is possible that the unsolicited message enters just after the command is sent, which will cause the response tag to try and match this unsolicited message instead of the actual response.
Dear Dojo Community,
could you please guide me on this?
Thank you
Hi Vikas,
If I understand your situation correctly. You have a connector with a smart-serial connection?
As the documentation indicated only one type can exist on the same IP + Port combination (serial or smart-serial). In your situation it should be smart-serial.
The connector should contain responses for each possible response. The response should be unique. And the order of the responses is as well important. Go from most specific to less specific. This way your code can handle the responses the best.
But next to this, smart-serial is a listening communication protocol. With this you need to know when you send something you "expect" a response to be back as soon as possible, you don't know for sure that the next will be the one you expect. And there will be potential responses in between ( as is in your situation ).
The best way is to make each response independent (not part of a pair). The responses needs to be "if possible" have a header and trailer and potential specific static data only present for that response. As the smart-serial connection will look to through all response and will try to match it in you protocol in order. The first response in your protocol will be checked and if it matches it will use that response. Otherwise it will look at the next one and then the next one until it finds its first fit. It could happen that when the response Data matches an earlier response it will use that one instead the one you thought the handling would happen.
Dear Dojo Community,
I need your assistance. I’ve completed the protocol development — everything is in place, including Group, Pair, Command, Response, and Qaction for parsing responses to each command.
However, I'm encountering an issue where the SDK continuously sends "Active" or "Busy" status messages. The system is prematurely interpreting these status updates as actual command responses, causing it to proceed without waiting for the real responses.
Any insights or suggestions on how to properly differentiate and handle these status messages would be greatly appreciated.
Thank you!