Concurrency

• Piksel Developer
• Playout
• Concurrency

The concurrency feature enables tenants to restrict the number of concurrent streams that a user can consume. The number of concurrent streams can be set at two levels.

• User’s total number of concurrent streams
• Number of user’s concurrent streams for a specific concurrency group

If a tenant wishes to impose concurrency restrictions on their content, their client application must be responsible for initiating a concurrency session and managing it for the duration of playback. To be compliant the client must initiate a new concurrency session before commencing playback. If content is encrypted this should be completed before requesting a licence for the DRM scheme.

If the concurrency service returns a successful response, playback may commence and the client must parse the concurrency response to retrieve the token for the next call and determine when the next concurrency check must be performed. If an unsuccessful response is returned, the client must not commence playback. Once playback has commenced, if the client fails to maintain an active session, playback must be stopped and in the case of encrypted content, any transient licences must be discarded.

Failed requests to update the session are allowed until the existing token expires. However, successfully requests that instruct the client to prevent playback must be adhered to and no further requests should be made to update the session.

The concurrency service will honour to the best of it’s ability the earliest session started. Therefore, if an attempt is made to create a new concurrency session when the limit has already been reached a new session will not be permitted. Also if, under failure, a new session was to be permitted that breached the limit then the new session would be the one selected for eviction during the healing process.

Total Concurrent Streams

A tenant may wish to restrict the overall total number of concurrent streams that a single user can consume.

Concurrency Group

Studio’s may place restrictions on content they provide to tenants. To meet their contractual obligation to a studio a tenant may need to impose a further restriction on specific pieces of content over and above the restriction of the total number of concurrent streams that their business rules limit users to.

NFRs

Persistence

The architecture of the service allows session data to be transient and disposable. The service will be resilient to complete loss of all session data. In this event consider the following example.

Bob has a limit of 5 concurrent streams and is watching 5 concurrent streams identified as streams 1 - 5.

The concurrency service looses all session data
Bob's 5 streams (1-5) continue to play as the steams are still inside the poll window

Bob plays an additional stream triggering a concurrency check (stream 6).
Concurrency check passes as no streams are represented in session data.
After the check, only stream 6 is represented in session data

Streams 1 - 4 perform the concurrency check and succeed. Concurrency is now 5 of 5

Stream 5 performs a concurrency check
    There are now to many concurrent streams
    The concurrency service identifies the last stream started was stream 6
    The concurrency service deactivates the session for stream 6
    The concurrency service allows session for stream 5 to continue

Stream 6 performs it's next concurrency check
    The concurrency service finds the session for stream 6
    The returned session is marked as deactivated
    The concurrency service prevents stream 6 from playing

Anti-tamper techniques will also be employed to prevent the request from being circumvented by a man-in-the-middle attack.

Recoverability

In the unfortunate event of an outage, the service can be restarted with no visible impact on the user’s experience if the service can be recovered within the expiry time of a token.

Scalability

The service is designed to be dynamically scaled horizontally.

Throughput

Suggested figures for a tier 1 customer was 200,000 concurrent viewers at peak for the F1 racing. This is a long program lasting several hours. For this duration, if the customer required checks every 30 seconds that would generate 400,000 requests per minute sustained over several hours. Thats 6666 requests per second.

Assumptions

Orphaned sessions

It is possible that concurrency sessions will be created and not ended due to network partitions, user behaviour etc. However these are exceptions which can mostly be mitigated. Any remaining scenarios may result in a small period of time when a user may need to wait for the orphaned session to expire before commencing playback.

This is considered to be acceptable as we expect this to be an edge case. Clients can mitigate this issue by tracking concurrency sessions within the client and terminating any active orphaned sessions before initiating a new session ahead of commencing playback.

Consistency

During session creation, the number of active sessions will be checked and could produce stale results. This will be mitigated by subsequent session updates that will cause active sessions to be revalidated eventually allowing the service to block invalid streams.

The assumption here is that in this edge case it is ok for a new session to be created as long as it is subsequently blocked ASAP once session state becomes consistent.

Further Reading

Full reference docs are available here.