View Single Post
Old February 14th, 2012   #2
Join Date: Feb 2006
Posts: 432
Send a message via AIM to sblair Send a message via MSN to sblair

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
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote