These options have been considered, but are considered to be error-prone for several reasons.
The problem with the TCP model is that it either establishes back-pressure into the ZK servers or requires unreliable delivery mechanisms. The first option is completely unacceptable and the second is just a form of what we have now wherein the application has to look at state after getting the notification. So the conclusion is that we don't want to pretend that the client will be able to keep up with all notifications. Once you have that conclusion, then it makes sense to not have permanent watches. Having transient watches as we do now provides automatic metering of the flood from the server since the watch will not be reset until the client gets around handling the event. Also, giving up on complete delivery of all events means that we have to relinquish the idea of event handling and switch to state handling with change notification. These finally lead to the model that ZK has right now. Ben relates stories about how he started with passing the data with the notifications, but he repeatedly saw cases where programmers used that data as if it were authoritative (which it cannot be) and repeatedly wrote code with bad race conditions because they used the stale data in the notification and set the new watch against the current state. This led to data loss because of the gap between the data and when the new watch was set. On Sun, May 8, 2011 at 1:14 PM, Justin Bailey <[email protected]> wrote: > To any developers out there, how difficult would it be to customize the ZK > code to both send data along with notifications and to have permanent > watchers? This would allow notifications for all changes to be guaranteed, > sacrificing latency. Having both options would be analogous to having both > TCP and UDP protocols available for use depending on the particular > requirements of the application. >
