WebAPI/PresentationAPI:CoreService

Introduction

The page explains the implementation detail of core service.

Architecture

Architecture of Presentation API Core Service (In process case)

Architecture of Presentation API Core Service (Data Channel OOP case)

PresentationService

A mediator among WebAPI classes, IPC and |PresentationSessionInfo|.

Live in chrome process.

PresentationSessionInfo

Maintain grotty details around session transports, receiver page and connection state.

Session infos use the established control channel to negotiate the SDP of session transport and create a transport builder to do the transport establishment.

Two subclasses, |PresentationControllingInfo| and |PresentationPresentingInfo|, stands for the controller and presenter. Presenting info will establish the transport after the receiver's page ready.

Live in chrome process.

PresentationSessionTransport

Maintain the underlying transport. We have TCP transport now and work on RTCDataChannel transport.

TCP transport lives in Chrome process. RTCDataChannel lives with the DOM. That is, live in content process in e10s mode.

PresentationIPCService

A mediator between IPC and WebAPI. Also manage PresentationIPCSessionInfo if the underlying transport is RTCDataChannel.

Only lives in e10s mode and in content process.

PresentationIPCSessionInfo

Manage PresentationDataChannelSessionTransport.

Only lives in e10s mode and in content process.

Call Flow Example

Establishing OOP RTCDataChannel Transport

Since RTCDataChannel should be accompanied with DOM, we should build our transport in content process in the case. Here's the procedure:

1. Hook handler: |SendRegisterTransportBuilderHandler| in |PresentationIPCService::StartSession| (controller) and |PresentationIPCService::NotifyReceiverReady| (presenter) hook a handler (|PresentationParent|) to |PresentationService| which lives in the chrome process.
2. Create a session transport builder: As chrome process ready (receive control channel|NotifyOpened| for controller; receive control channel |OnOffer| and receiver page ready |NotifyResponderReady| for presenter), |PresentationSessionInfo| create a transport builder to establish a transport.
3. Build a transport in content process: The transport builder is |PresentationParent| hooked by first step. It will triggered an IPC call to |PresentationIPCService| and build the underlying RTCDataChannel in the content process. It will call back to |PresentationService| the result of building.

Message Transmission for TCPSessionTransport

sequence diagram of message transmission over TCPPresentationTransport

• message transmission over TCPPresentationTransport

1. when connection.send is invoked, PresentationService will delegate the message content to corresponding session info object
   1. session info object will used the associated TCPPresentationTransport object for sending message to remote peer
2. when incoming message is received by TCPPresentationTransport, the message will be delegate to corresponding PresentationConnection object
   1. onmessage event will be fired on that PresentationConnection object.

Receiving UA

handle presentation request

sequence diagram of handling session request on receiving UA

• establishing TCP Transport

1. PresentationService observe incoming presentation request via "presentation-session-request" topic
2. create receiving browser context via nsIPresentationUIGlue and navigate to presentation URL
   1. presented content should be loaded in a browser element with "mozpresentation" attribute set to the requested presentation URL
3. a (windowId, presentationId) mapping will be created at content side while document begins to load
   1. corresponding session info object will be removed if failed to load within time limit
4. In parallel, establish transport channel between controlling page and presented content

monitor incoming connection

sequence diagram of monitoring incoming connection on receiving UA

• monitor incoming connection

1. register PresentationReceiver as a RespondingListener to PresentationService while navigator.presentation.receiver.connectionList is touched first time.
2. PresentationService will report the available presentationId via nsIPresentationRespondingListener::NotifySessionConnect.
3. corresponding PresentationConnection object will be created in connecting state and register it as a SessionListener to PresentationService.
4. transport channel state will be sent to presented content once PresentationConnection object is created
   1. if fail to create transport channel, PresentationConnection state should be set to 'closed'