The CDN is prepared to scale with an increasing number of requests per second. If it receives CMCD via the request mode, it can decide whether to store the information or discard it.
On the other hand, the new modes (Response Mode and State-Interval Mode) are designed so that third parties can receive the information and decide what to do with it—whether to process it, store it, or discard it.
To give a control mechanism to these third-party endpoints in case of overload and to enable sub-sampling if needed to control costs, it is proposed to define a response that includes at least the following information:
For Response Mode, allow the server to instruct the player to disable Response Mode.
For State-Interval Mode, allow the server to specify how long the player should wait before sending the next update, setting a new Interval time and overriding the interval set by the application.
Example of a response for State-Interval Mode:
Response Code: 200 OK
Body:
{
"sendOnStateChange": true,
"setIntervalTime": 120
}
Also, an Ad tracking system that uses CMCD, could ask the player increase the "CMCD resolution" when an interstitial is detected ('int' key)
The CDN is prepared to scale with an increasing number of requests per second. If it receives CMCD via the request mode, it can decide whether to store the information or discard it.
On the other hand, the new modes (Response Mode and State-Interval Mode) are designed so that third parties can receive the information and decide what to do with it—whether to process it, store it, or discard it.
To give a control mechanism to these third-party endpoints in case of overload and to enable sub-sampling if needed to control costs, it is proposed to define a response that includes at least the following information:
Example of a response for State-Interval Mode:
We could also explore using CMSD for this...