ACK_TIMER corner cases

[ericthegeek]

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

You can even see:

request: GET QUEUED_MESSAGE
response: GET_RESPONSE ACK_TIMER LAMP_HOURS
request: GET QUEUED_MESSAGE
response: GET_RESPONSE NACK UNSUPPORTED_PID LAMP_HOURS

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.