View Single Post
Old June 14th, 2012   #3
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

To me, a NR_BUFFER_FULL response means that the responder could not handle the request and therefore dropped it without acting on it. This is most similar to what you described as behavior #2.

But: The better answer is to design the responder in such a way that this condition can never occur. A well designed responder will be able to handle every possible queued message and thus never be subject to the kind of message queue overflow that you describe.

Traditional software queues tend to take a lot of memory (doubly linked lists, etc), but despite it being called "Queued Messages", a responder typically doesn't need to implement it as a queue. All you need is a bitmask with one bit for each possible PID that can result in a queued message indicating whether you need to send that PID in response to "GET QUEUED_MESSAGE". That's typically only a handful of bits in RAM. I also recommend you sent any Queued Messages that were triggered by an ACK_TIMER before sending any message that are due to internal events, but even at the worst case this is only 2 bits per PID.
ericthegeek is offline   Reply With Quote