ACK_TIMER corner cases

[ggallant]

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->controller: GET_RESPONSE LAMP_HOURS ACK_TIMER*
responder->proxy: GET_RESPONSE LAMP_HOURS ACK_OVERFLOW
proxy: queues response

controller: waits 3 sec
controller->proxy: GET QUEUED_MESSAGE
proxy->controller: GET_RESPONSE LAMP_HOURS ACK_OVERFLOW

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.

Garrett

[sblair]

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.