Interpretation of NR_BUFFER_FULL

[nomis52]

Originally Posted by ericthegeek

Since the console received an ACK_TIMER, it now does a "GET QUEUED_MESSAGE". If the responder has implemented a true queue, it receives a "GET_RESPONSE DMX_START_ADDRESS 300". This data is 15 minutes out of date.

On the other hand, the controller would also see a non-0 message count, which indicates that there is more messages in the queue.

Originally Posted by ericthegeek

If the responder implemented a true queue, any time you did a GET QUEUED_MESSAGE you'd have to completely drain the queue of all messages before you could act on any of the messages because there *might* be newer data waiting later in the queue. On a busy responder that's generating lots of queued messages you may never be able to drain the queue.

The problem is though that if there are proxies in the network you do see FIFO queuing behavior. This is the reason why the RDM tests drain all queued messages prior to each test.


Simon (who prefers the real queue method and NR_BUFFER_FULL responses)

[sblair]

I agree with the best practices Eric mentioned. My implementations have always pretty much reflected what he posted so that I avoid returning stale data.