There are three
sources of device history: a per-device history queue, an
all-events history queue and per-device current state. When a
device event occurs in real-time it is added to both its per-device
queue and the all-events queue. Also, if appropriate, the event is
used to update a device’s current state information (for example,
display devices have a current state). The idea behind the separate
history queues is to ensure that there is history available for
each device even if one device has been so busy, such as the
printer, that it dominates the all-events queue. Current state is
kept for certain devices (displays particularly) so the current
state of the device can always be viewed. The reason current state
is needed separately from history is because the history queue may
not contain events that define the state of the entire device. For
example, the device history buffer may be full with events that
only update line 25 of a Vdisplay device.
When a client
(UI) starts monitoring a terminal, it can choose to get historical
events from 3 source categories:
·
per-device
history queue
·
all-events
history queue
·
per-device
current-state events
After that, the
client will be sent real-time per-device events.
It is likely that there will be duplicate events between the
per-device history queue and all-events history queue. Events are
uniquely identifiable by an event sequence number and timestamp for
that terminal.
In addition to device-specific events, each history queue may also
contain one or more time/date synchronization events. These events
allow the clock time to be displayed accurately for each event.
| Converted from CHM to HTML with chm2web Pro 2.85 (unicode) |