E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM Interpretation Questions (http://www.rdmprotocol.org/forums/forumdisplay.php?f=5)
-   -   ACK_TIMER corner cases (http://www.rdmprotocol.org/forums/showthread.php?t=1129)

ggallant February 14th, 2012 06:32 PM

ACK_TIMER corner cases
Hey guys, I have two unusual ACK_TIMER response cases I'd like to think are illegal, but the RDM spec doesn't expressly forbid:

1. ACK_TIMER following ACK_OVERFLOW for the same pid

For example:

Is this legal? Has anyone seen or created a responder that does this?
Spec 6.3.2 says:
The responder shall abort a partial transfer of overflow data for a PID when receiving a command for a different PID before the overflow data transfer is complete. A subsequent command for the overflow PID will result in a new data transfer starting at the beginning of the data set.

and Spec 6.3.3 says:
This mechanism allows the controller to [shall] retrieve deferred Get command data by issuing GET QUEUED_MESSAGE
The combination of both of these clauses indicates to me that it's illegal, because the correct controller followup to the ACK_TIMER (GET QUEUED_MESSAGE) would reset the overflow sequence; i.e. the responder would violate 6.3.3 by allowing the partial transfer to continue.

If I'm right, the Spec should expressly state that once a responder returns ACK_OVERFLOW for a given pid, it may not subsequently return ACK_TIMER for that pid until it has returned an ACK/NACK.


Is this legal? It seems slippery to me, e.g.:


To me, that response says, "responder's ACK_TIMER timeout on the original GET LAMP_HOURS was wrong; it needs more time to respond". Yah, it's hokey, but plausible.

There's also:


This response to me says, "responder needs more time to prepare its queued messages".

Has anyone seen this?

Section 10.3.1 says:
Each QUEUED_MESSAGE response shall be composed of a single message response

I'm not sure what "single message" is supposed to mean.

Aside, and this is just me ranting... since the Spec allows lock-step sequencing, it should have stipulated which sequence patterns are valid. Also, RDM should not have dual-purposed QUEUED_MESSAGE for both change reporting and delayed response. Delayed response should have been handled with a "pending write, latest read" pair common to other SCADA systems. This would have made ACK_TIMER congruent to ACK_OVERFLOW, eliminated the above confusion as to which order and pids are valid for ACK_TIMER, and most importantly, saved controllers from having to flush a queue of (typically unrelated) messages to get to the data they originally asked for.

sblair February 14th, 2012 08:56 PM

This is a good corner case. If you are in the middle of an ACK_OVERFLOW transaction and get an ACK_TIMER, the way I see it as long as you don't send any other PID to that device you could wait out the timer and then continue on where you left off with the ACK_OVERFLOW transaction.

In 6.3.3. your implied [shall] is expilicitly not there for a reason. Our guidance was to use QUEUED_MESSAGES, but we do not *REQUIRE* QUEUED_MESSAGES to be used. This was the subject of a lot of debate because at the time we were writing it there were a couple people that were strongly against using queued messages. So the expectation is that once the timer has expired another request can be made for the same PID again, the controller is not required to retrieve it by using queued messages, but it is generally encouraged.

I have never seen either of the two scenarios there you mention. I don't think it has even been discussed. Yes, it would be a bad idea for anyone to try doing that! At some point I always hope common sense will prevail by people implementing these.


When the responder is able to provide the required information, it shall add the correctly formatted GET_COMMAND_RESPONSE message or SET_COMMAND_RESPONSE message to its QUEUED_MESSAGE list. It shall also increment its Message Count at the time the message is added to the QUEUED_MESSAGE list.

I think this says it all. "When the responder is able to provide the required information...." I do not count another ACK_TIMER as being the required information!

In 10.3.1, "single message" simply means that it replies with a single GET/SET _COMMAND_RESPONSE and does not send back a slew of queued messages. In other words, each request from the controller only generates a single response.

Your rant is well taken, everything in the Response Types and Queued Messages all evolved quite a bit over time while the standard was being written and ended up being quite a bit different from where they started for various reasons. A lot of the concerns aired were always over efficency on the wire which is where we ended up with so many things "optimized" for the fewest number of transactions. At any rate, it is what it is now :)

nomis52 February 15th, 2012 10:08 AM

I haven't seen the first case before.

Case #2 occurs if you have multiple layers of proxies. The ACK_TIMER as a response to the queued message will be the ACK_TIMER sent by the second proxy. You need to keep sending GET_QUEUED_MESSAGE until you empty the ACK_TIMER stack, or give up and decide there are too many proxies in the system.

Excuse the brevity, I'm extremely busy right now.

ericthegeek February 15th, 2012 12:41 PM

Simon is correct. A controller will regularly see Case #2 when one or more proxies are involved.

You can even see:


The proxy had to issue an ACK_TIMER to allow it enough time to get the real data from the responder. It then determines that the responder doesn't support the PID and queues a NACK.

Practically, you have to assume there can be multiple ACK_TIMERS queued before you get the final data. In my code, I allow up to 10 ACK_TIMERS before I assume something is stuck in a loop and abort.

Case #1 is a bit more interesting. For simplicity, it's probably best if a responder doesn't mix queued messages and ACK_OVERFLOW. Design the firmware so that any data that needs to overflow into a second packet is always available within the 2ms response time.

But when you have a proxy involved, it gets more complicated. The proxy may not know if the responder will use ACK_OVERFLOW. Once it gets the ACK_OVERFLOW, the proxy can start collecting the overflow messages independently.

I haven't fully thought this through, but from a controller standpoint, I think it has to assume that GET QUEUED_MESSAGES won't reset the ACK_OVERFLOW sequence.

ggallant February 16th, 2012 01:36 PM

Thanks for the quick responses, gents.

Scott, I didn't know QUEUED_MESSAGE was optional for the controller; thanks. I do try to handle both responder ACK_TIMER implementations anyway (http://www.rdmprotocol.org/forums/showthread.php?t=731) and RDM's lack of (TFTP/HTTP-style) sequence recovery.

Simon and Eric, thanks for the the proxy heads-up; I hadn't considered proxy cascading.

Following on Eric's thoughts, I suppose case #1 can appear even with only one proxy between the controller and responder, if said proxy doesn't bother aggregating the responder's ACK_OVERFLOW/ACK sequence ahead of the controller's requests as Eric has advised. Consider the following example that results in an {ACK_TIMER, ACK_OVERFLOW, ACK_TIMER} sequence:

controller->proxy: GET LAMP_HOURS (addressed to the responder).
proxy->responder: GET LAMP_HOURS
proxy: waits 2ms; no response
proxy: queues response

controller: waits 3 sec
controller->proxy: GET QUEUED_MESSAGE

controller->proxy: GET LAMP_HOURS <-- (correct follow-up to ACK_OVERFLOW)
proxy->responder: GET LAMP_HOURS
proxy: waits 2ms; no response
proxy->controller: GET_RESPONSE LAMP_HOURS ACK_TIMER* <-- case #1

*(also note proxy must typically guesstimate the ACK_TIMER timeout, which can lead to the many ACK_TIMERs that probably led Eric to tolerate 10 in a row).

So I guess I'll handle both cases in my controller and log more error/warning conditions (e.g. "responder returns ACK_TIMER but doesn't support QUEUED_MESSAGE", "high RDM latency/loss on branch proxy1->proxy2->responder").

Eric, I don't think the controller can strictly assume that GET QUEUED_MESSAGE won't reset the ACK_OVERFLOW sequence, because that assumes the responder programmer interpreted the spec carefully enough to except QUEUED_MESSAGE from his ACK_OVERFLOW reset code. But as neither you nor Simon have seen case #1, I'll go with your assumption and fix it if it breaks in the field. :-)

Thanks again, guys.


sblair February 16th, 2012 01:52 PM


Scott, I didn't know QUEUED_MESSAGE was optional for the controller; thanks. I do try to handle both responder ACK_TIMER implementations anyway (http://www.rdmprotocol.org/forums/showthread.php?t=731) and RDM's lack of (TFTP/HTTP-style) sequence recovery.

As I said, my belief is that everyone SHOULD use QUEUED_MESSAGES, however it is not strictly required for the controller to implement them. Of course it will be a far better controller that DOES implement them. Either way, it doesn't mean the controller can't just wait for the ACK_TIMER to expire and send the PID request again and *hopefully* the responder will have it available immediately to provide at that point.

ericthegeek February 16th, 2012 08:54 PM

From a practical standpoint, it is possible to implement a responder that does not use queued messages at all. You'd have to design your firmware to ensure that all results are available within the 2ms timeout, and thus will never need to issue ACK_TIMER. Many simple responders behave this way.

But the controller effectively has to support queued messages if you want to achieve any level of interoperability. It needs to support them enough to retrieve the followup to an ACK_TIMER.

Doing this is not as scary as it seems. Any time you receive an ACK_TIMER, you can simply wait the requisite amount of time, then issue GET QUEUED_MESSAGES until you receive a response with the PID, Command Class, and Sub-Device ID that you are looking for. If you receive other Queued Message in the meantime you can simply discard them.

Obviously a more featurefull controller will handle every Queued Message is receives rather than discarding the PIDs it doesn't care about.

As a practical example, the DFD RAD supports Queued Messages. You won't find an RDM controller that's much simpler than the RAD...

All times are GMT -6. The time now is 04:06 PM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2022, vBulletin Solutions, Inc.