Partager via

3.2.5.2 RefreshTimer Expiration

  • Article

When the RefreshTimer expires, the client MUST send zero or more REFRESH messages to make the server aware of FileIDs for files on the client's computer, and aware of VolumeIDs for volumes on the client's computer.

A REFRESH message is sent to the server by using a LnkSvrMessage request, as defined in section 3.1.4.1.

If the client's ClientVolumeTable and VolumeFileTable are both empty, the client MUST NOT send a REFRESH request to the server. Otherwise, one or more messages MUST be sent. The format and number of the messages sent are defined in the following paragraphs.

Each message is sent by specifying a MessageType in the TRKSVR_MESSAGE_UNION of REFRESH. This specification requires that the message include the TRKSVR_CALL_REFRESH structure, as described in section 2.2.12.2.

In each call, the client sets the Priority field of the TRKSVR_MESSAGE_UNION based on the timer's period and on when the timer was started. If the current time is greater than or equal to the timer's start time plus twice its period, then the Priority MUST be set to zero. Otherwise, the Priority MUST be set to a value calculated as follows, where all times are measured in seconds, and where division truncates any fractional part to return an integer result.

 9 - ( (Current time - Timer start time + Timer period) * 10 ) / Timer period

The adroidBirth and avolid fields of the requests, and the number of requests, MUST be determined as follows:

  • The first message MUST have an entry in the avolid array field for each entry in its ClientVolumeTable. The value of that entry in avolid MUST be that of the VolumeID from the VolumeInformation for that entry in the ClientVolumeTable. If the ClientVolumeTable is empty, the client MUST pass NULL for the value of the avolid field of the message (and zero for the corresponding cVolumes field).

  • The first message also MUST have an entry in the adroidBirth array for up to 128 of the entries in its VolumeFileTable. The value of that entry in the adroidBirth field MUST be that of the FileID from the FileInformation for that entry in the VolumeFileTable. If all of the VolumeFileTables are empty, the client MUST pass NULL for the value of the adroidBirth field of the message (and zero for the corresponding cSources field).

  • If there are more than 128 entries in the VolumeFileTables, and the previous message is successful (as defined in section 3.2.4.1), the client MUST repeat the previous step, followed by this step. Note that by this definition, subsequent to the first message, the avoid field of each message will be NULL (and the cVolumes field zero).

See section 3.1.4.3 for information on the server processing of the REFRESH message. See section 3.2.4.2 for information on the client's completion of that message.