In delta mode, a subscriber receives only the changes (but all the changes) to an object's attributes.
On the first read, since a subscriber knows nothing about the state of an object, PPS assumes everything has changed. Therefore, a subscriber's first read in delta mode returns all attributes for an object, while subsequent reads return only the changes since that subscriber's previous read.
Thus, in delta mode, the subscriber always receives all changes to an object.
The figure below illustrates the different information sent to subscribers who open a PPS object in full mode and in delta mode.
Figure 1. Comparison of PPS full and delta subscription modes.In all cases, PPS maintains persistent objects with states—there's always an object. The mode used to open an object doesn't change the object; it determines only the subscriber's view of changes to the object.
Delta mode queues
When a subscriber opens an object in delta mode, the PPS service creates a new queue of object changes. That is, if multiple subscribers open an object in delta mode, each subscriber has its own queue of changes to the object, and the PPS service sends each subscriber its own copy of the changes. If no subscriber has an object open in delta mode, the PPS service doesn't maintain any queues of changes to that object.
Changes to multiple attributes
If a publisher changes multiple attributes with a single write() call, then PPS keeps the deltas together and returns them in the same group on a subscriber's read() call. In other words, PPS deltas maintain both time and atomicity of changes. For example:
write() write()
time::1.23 time::1.24
duration::4.2 write()
duration::4.2
read() read()
@objname @objname
time::1.23 time:1.24
duration::4.2 @objname
duration::4.2