Root / Assembly / ARCCore / Class / ClientUpdatePosition
|_Member||ClientDatastoreIsEmpty, ClientDatastoreIsEmptyInstance, Filename, Index, IsAtEndOfStream, IsGoBack, OnlyNewDataIsRequested, OnlyNewDataIsRequestedInstance|
|Description||Describes from WHERE (from WHEN) in the historic PropertyStream new data is to be returned.|
(or actually, it describes up to which point in time client already has updated data).
Communicated between client and server as follows:
1) At initialization of ActualConnection:
Sent by client to server in order to inform the server about the client's update status.
2) For every new PropertyStreamLine sent from server to client:
Sent by server to client. Done by prepending to the PropertyStreamLine being sent, with '::' (double colon) as a separator.
Explains from where in the PropertyStream this line originated.
The server also keeps track of the last value sent to the client as long as the ActualConnection is active.
Used in connection with Subscription which describes WHAT data is required from the PropertyStream.
TODO: Clarify difference between ClientUpdatePosition and FromTime / ToTime.
TODO: Build revision number into this? (DataRetention or keep in filename?
TODO: Ensure that the format being used suits the encoding mechanism well (see EncodeValuePartStringToPropertyStreamFormat) (no special encoding should be necessary as want a human readable format also after encoding)
Describes status of a client's up-to-date level.
Note that client in this case not only means Client but any ARNodeType.
1) 'ClientDatastoreIsEmpty' (see ClientDatastoreIsEmpty).
2) 'OnlyNewDataIsRequested' (see OnlyNewDataIsRequested).
3) 'GoBack|1000' (see IsGoBack) means start from 1000 elements back.
4) 'StorageFile0042|42042': The common scenario. Last update was index 42042 in 'StorageFile0042', next update should be at least 42043 (or index 0 in next file)
An 'IsEndOfStream' marker may be added, like this:
'StorageFile0068|42042042|IsEndOfStream' (see IsAtEndOfStream).
|LongDescription||This class is immutable.|
TODO: Note how we assume that if we have multiple outgoing connections, that is, if we
TODO: have multiple CoreDB's to choose from, they are all compatible regarding clientUpdateStatus.
TODO: This would probably not be the case with how clientUpdateStatus is built up today
TODO: (Apr 2020) with filename + index.
TODO: Consider adding timestamp, actual property line or similar, in order for different CoreDB instances to more TODO: accurately decide from where to 'pick-up' from when receiving a new incoming connection with a subscription request.TODO: OR, alternatively, ensure that CoreDB instances coordinate among themselves so that they always have the exact same TODO. storage-layout (having a master instance at any given time for instance).
TODO: If we add timestamp, it can then be up to the client to keep track of it, by 'listening' to Timestamps / 'Heartbeats' inserted in the TODO: property stream. The client can then transmit it to the server, as a backup, in case the ordinary filename + index TODO: information makes no sense. Using only Timestamp would of course lead to some overlap (duplicate property stream lines being sent), TOOD: since it is probably quite coarse.
TODO: Other ideas for keeping clients correctly in sync:
TODO: Server can inject the current position at regular intervals in the property stream. This serves the same purpose as injecting a TODO: Timestamp / 'Heartbeat' but the position becomes exact instead of approximate. When the client understands that there is someTODO: corruption present, it can look for the last such value, delete stored data after that position, and update from server from this TODO: exact known position. (actually the client can inject the position itself, since it receives the position with any value sent)
Generated 2020-10-13 11:11:03.503 UTC