View Single Post
Old December 17th, 2018   #17
Task Group Member
Join Date: Aug 2008
Posts: 369

Originally Posted by peternewman View Post
Actually re-reading your post, I'd perhaps suggest there are three states, and maybe that's where our disagreement comes from:

Fully agree. You probably noticed that I didn't include every NACK Reason code in my category list because, as you point out, there are varying degrees of finality.

Please don't think I'm trying to give a prescription on how to handle NACKs. Rather, I'm suggesting a way to think about NACKs and what their purpose is.

Some requests won't ever work. Some might work if the personalty changes. Some might work if an external factor changes ("can't strike the lamp now, but might be able to if the line voltage increases"). Some requests just got unlucky and might work 10 milliseconds later. It's a range rather than two or three hard categories.

When implementing a responder, you need to pick a sensible Reason Code based on what you want the controller (and user) to know. Most importantly the responder must NACK. There are lots of responders out there that never NACK (they just ignore any requests they don't understand). This causes *lots* of problems.

When implementing a controller you need to determine how to handle each NACK. Retry? Write an error in a debug log? Notify the user. The "Right" way to do this will vary from controller to controller. Any "Well thought through" implementation is probably fine since you've taken the time to think about it.
ericthegeek is offline   Reply With Quote