I am making a request to a device via SSH, and am having a few problems.
One – creating a dynamic trailer.
Previously, we were using the # symbol as the trailer, but found that this cut some responses in two because there was a # inside the response. To combat this, I’d like to improve the trailer. When we get a response, we get back the terminal line ([SystemName]#). For example, Router0232#. Is it possible to create a dynamic trailer to ensure that I capture all of the data? That way, I can use the entire string as my trailer.
I tried to use the times=”2″ to guide how many times the trailer will occur, but also had no success there.
Two – Issue with request speed.
The request I am making fails or returns an empty response after startup. The format for all requests is the following:
Init CLI 1
Init CLI 2
Data request (desired data)
The Init CLI requests set up the terminal so that no data is lost in the response. If I don’t add these two pairs to all of our requests, I receive extra/missing information in the response we care about. Still, on startup, I receive incorrect data in my response, as below:
As you can see, there seems to be some overlap as I’ve received the previous command in my last (terminal width 0) response. However, if I execute the request again (manually with a button, for example), I receive the correct response. The only way I could get the response to work on the first request was using a half second delay. See below:
However, there are some requests we need to make thousands of times and this can quickly escalate the polling time. I’m still checking to see if we can make bulk requests of data, but in the meantime I want to see if I can make the responses return correctly without adding too much delay. Is there some way to improve the communication to reduce this overlapping of response, or do I just need to slow the communication down?
Thanks in advance for any information.
To answer to question one:
-Having a true dynamic trailer during run-time with classic responses does not exist (yet). There is however a corner case for a serial driver. This worked three years ago, it could be that it’s not working anymore or that it doesn’t work for SSH: define the length interprete type of the trailer parameter to either fixed or next param. In case of a fixed length execute the change length action, then execute a copy action with the new value. With the next param it’s not needed to have the change length action.
There are some remarks with this way of working: warnings will be added to the logging that there’s an attempt to change the length of a fixed parameter. Changing the trailer value is only possible BEFORE launching the first command. It’s not possible to say “use trailer A for first response, then use trailer B for the second response”, then the second (and next responses) will wait until timeout time. This means that you can’t start with ‘#’ at startup to determine the system name and modify the trailer afterwards. If a saved parameter is used as trailer with the system name from previous runs and the system name ever changes means that the communication will be in timeout forever due to a mismatch in the trailer. To be tested could be: use one trailer # parameter to determine the name at startup and use another trailer parameter that will be modified.
-Another possibility is to use a multi-threaded timer: from a QAction the format of the response can be determined, also the trailer. Downside here is that a multi-threaded timer goes of every x seconds and it’s more complex if different groups need to be executed at different poll speeds.