Share via

3.4 Metering Aggregation Server Details

  • Article

The Metering Aggregation Server (MAS) hosts a metering protocol service on the internet which is reachable via HTTP [RFC2616] and HTTPS [RFC2818]. The device communicates directly with the MAS, if it is web enabled, or uses an indirect license acquisition host over MTP [MTP].

The license synchronization server retrieves the license synchronization challenge over MTP [MTP], and uses it to renew expired or invalid licenses. ere this is a requirement. Metering content usage is defined as counting the number of times a content file is used. Metering data is collected over time as a user plays content on the device. Periodically, such as when the user connects the device to a computer, a metering application or plug-in on the computer requests metering data from the device and sends it to a metering aggregation server. If the device is disconnected from the computer for a long time, a large quantity of metering data can accumulate. When this happens, it can take a long time to upload all the metering data from the device. This section contains best practices for original equipment manufacturers (OEMs) describing how to improve the metering experience, performance, and functionality for end users.

The implementer will want to consider the following best practices when implementing metering for portable devices:

  1. Use the latest version of the Windows Media DRM for Portable Devices Porting Kit.

  2. The metering requests from a computer SHOULD be returned by the device within one minute. If the device cannot return metering data within the time-out period, the metering report fails and the user receives an error message from the metering application or a metering plug-in on the computer. In the event the metering data is not processed, the metering data continues to accumulate and is never cleared from the device.

  3. Reduce the size of the metering challenge that is sent in each metering report. When calling the DRM_MGR_GenerateMeterChallenge function, pass a value for pbChallenge to limit the size of the buffer. The metering challenge data can then be divided into smaller amounts, and will require multiple transactions to complete the report.

  4. The optimal size of this buffer depends on the processing power and transfer speed of the device. The buffer SHOULD be small enough that the data can be sent before the time-out limit is reached. The OEM will need to test multiple values, and test a worst-case scenario to find the optimal value.

  5. Partial transactions are flagged as such when the DRM_MGR_ProcessMeterResponse  function is called to clear the data store of the reported data (DRM_METER_RESPONSE_PARTIAL is returned in pfFlagsOut). The metering application on the computer SHOULD repeat the process until 0 is returned, indicating that the entire process is complete.

The following figure shows a conceptual overview of metering message flow.

Conceptual metering overview

Figure 6: Conceptual metering overview

The metering flow is documented in section 3.4.5.2.