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.

Controlling UA

start session

sequence diagram of starting session on controlling UA and establishing TCP transport

1. PresentationService.startService is invoked, with a list of presentation URLs, presentation Id, and other parameters provided
   1. device selection procedure is triggered if no device is specified
2. PresentationSessionInfo is created after device selection complete
   1. corresponding device, control channel, and transport builder constructor is bind to that session
3. a nsIPresentationSessionTransportBuilder is created according to the type of transport channel when control channel is connected
4. transport establishment procedure is executed
   1. OnSessionTransport is invoked when nsIPresentationSessionTransport is created by transport builder
   2. NotifyTransportReady is invoked when the transport is ready to send/receive data

• TCP transport establishment

1. a TCP server socket is created by transport builder
2. obtain self IP address using platform dependent mechanism
3. an offer is composed with self IP address and server socket port number and send to remote peer via control channel
4. a nsIPresentationSessionTransport is created when both onSocketAccept and onAnswer is invoked

• DataChannel transport establishment

1. transport builder is created on content process, with a proxy object in chrome process
2. create a RTCPeerConnection and pass the corresponding offer SDP and ICE candidates to chrome process, send to remote peer via control channel
3. answer SDP, ICE candidates are received in chrome process and pass to content process
4. a nsIPresentationSessionTransport is created when ondatachannel event is invoked

Receiving UA

handle presentation request

sequence diagram of handling session request on receiving UA and establishing TCP transport

sequence diagram of handling session request on receiving UA and establishing DataChannel 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. a nsIPresentationTransportBuilderConstructor is provided to PresentationSessionInfo for creating transport builder object later on
   2. 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
   1. create a nsIPresentationSessionTransportBuilder according the type of transport channel
      1. TCPSessionTransportBuilder is created in chrome process
      2. DCSessionTransportBuilder is created in content process, with a proxy object in chrome process
   2. OnSessionTransport is invoked while a nsIPresentationSessionTransport is created with the provided offer/answer/ICE candidates
   3. NotifyTransportReady is invoked while the session transport is connected and ready to send/receive data

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'