Confirmed users
192
edits
CloudServices/FirefoxMobileServices/ChannelService: Difference between revisions
CloudServices/FirefoxMobileServices/ChannelService (view source)
Revision as of 22:34, 16 July 2014
, 16 July 2014→Cloud Services Channel Service
| (6 intermediate revisions by 2 users not shown) | |||
| Line 5: | Line 5: | ||
==Overview== | ==Overview== | ||
Channel Service is a service for Mozilla Cloud Services that need to communicate with Firefox on the client-side (FxOS, Desktop, etc). It unifies bidirectional communication | Channel Service is a service for Mozilla Cloud Services that need to communicate with Firefox on the client-side (FxOS, Desktop, etc). It's public API is HTTP/2 which unifies bidirectional communication via HTTP/2 multiplexing, internally the HTTP requests are serialized to messages to reduce resource requirements of Mozilla Cloud Services. | ||
The HTTP/2 connection is held open via WebPush, clients using other WebPush providers will retain the benefit of a single channel anytime multiple client requests to Mozilla Cloud Services are needed. All return traffic to a client is via WebPush which ensures Mozilla Cloud Services retain simple bidirectional communication regardless of the clients WebPush provider. | |||
==Project Contacts== | ==Project Contacts== | ||
| Line 15: | Line 17: | ||
==Goals== | ==Goals== | ||
To develop a single multiplexed communication channel between clients and Mozilla Cloud Services. | To develop a single multiplexed communication channel between clients and Mozilla Cloud Services that reduces the complexity in implementing and operating server-side resources. | ||
This will result in: | This will result in: | ||
* Server-side API for Cloud Services that need to talk to a client | * Server-side API for Cloud Services that need to talk to a client | ||
* Cleaner code in the client that is not entangled with a specific service | * Cleaner code in the client that is not entangled with a specific service | ||
| Line 32: | Line 33: | ||
The first candidate for using the ChannelService is [https://wiki.mozilla.org/WebAPI/SimplePush Push], which is already on FxOS. At the moment the code handling the socket connection is mixed in with the code handling the DOM API's for Push. By splitting the channel out, future Push updates could be easier to land in the client. The server architecture will also be drastically simplified by no longer needing to handle the scaling challenge of all the socket connections. | The first candidate for using the ChannelService is [https://wiki.mozilla.org/WebAPI/SimplePush Push], which is already on FxOS. At the moment the code handling the socket connection is mixed in with the code handling the DOM API's for Push. By splitting the channel out, future Push updates could be easier to land in the client. The server architecture will also be drastically simplified by no longer needing to handle the scaling challenge of all the socket connections. | ||
=== Loop === | === Loop === | ||
| Line 48: | Line 44: | ||
=== Firefox OS === | === Firefox OS === | ||
* Client-side | * Client-side HTTP/2 implementation that can multiplex HTTP calls over an existing HTTP/2 connection | ||
=== Firefox Desktop === | === Firefox Desktop === | ||
* Platform dev's that can land the client-side | * Platform dev's that can land the client-side HTTP/2 code | ||
=== Fennec / etc === | === Fennec / etc === | ||
| Line 70: | Line 65: | ||
=== Client === | === Client === | ||
Clients | Clients may make regular HTTP calls to the Mozilla Service that utilizes Mozilla Channel Service. If the client is using WebPush then the HTTP calls will multiplex over the existing HTTP/2 connection, otherwise a new HTTP/2 connection will be established and used for any remaining Mozilla supplied services wishing to use the Channel Service. Unless the client is using Mozilla for WebPush, this connection will be transient per HTTP/2 keep-alive timeouts. | ||
=== Server-side Services === | |||
Cloud Services can utilize an API to communicate with clients, based on message-passing from the outbound router and inbound relay. These messages are translated at the Connection Node border into normal HTTP responses. Server initiated communication messages are carried as WebPush notifications and must have a WebPush channel. | |||
The Outbound Router will send WebPush messages to other WebPush providers if Mozilla is not supplying the WebPush channel for a client. | |||
The | The inbound message queue for a Cloud Service contains the body of the message and metadata: | ||
<pre> | |||
Type: Data | |||
Headers: ................. | |||
TTL: 123214212442323 | |||
Metadata: | |||
MessageID: AABCDC-550e8400-e29b-41d4-a716-446655440000 | |||
Payload: ................ | |||
</pre> | |||
The headers are the HTTP headers that were included in the request, the TTL indicates the amount of time since the epoch for which the Connection Node will wait for a reply. If a message is past the TTL it should be dropped as the CN will have already returned a 504 timeout error to the client. | |||
The payload is an opaque blob that should be significant to the Cloud Service utilizing the channel. This will be the contents of any PUT/POST body sent if applicable. The headers will indicate if the request could include data. | |||
The Outbound Router ensures that message responses, and service initiated communication is delivered to a client. Message responses must include the MessageID that the response corresponds to, while server initiated communication must include the WebPush endpoint to deliver the message to. | |||
Outbound response: | |||
<pre> | <pre> | ||
Metadata: | Metadata: | ||
MessageID: ce3488ea-cf7c-41c3-8110-9907b1fe80e8 | |||
Headers: ............. | |||
Payload: ................ | Payload: ................ | ||
</pre> | </pre> | ||
Headers can be any arbitrary HTTP response headers that should be included. | |||
Outbound message: | Outbound server-initiated message: | ||
<pre> | <pre> | ||
Metadata: | Metadata: | ||
MessageID: ce3488ea-cf7c-41c3-8110-9907b1fe80e8 | MessageID: ce3488ea-cf7c-41c3-8110-9907b1fe80e8 | ||
Endpoint: https://some.webpush-host.com/some-channel | |||
Payload: ................ | Payload: ................ | ||
</pre> | </pre> | ||
If the endpoint is handled by Mozilla Channel Service, then it will be routed appropriately, otherwise an external endpoint call will be made to deliver the message. | |||
Outbound router response messages: | Outbound router response messages: | ||
| Line 126: | Line 119: | ||
</pre> | </pre> | ||
This indicates that the message of the given MessageID could not be delivered | This indicates that the message of the given MessageID could not be delivered. Every message will generate a response indicating if it was successfully delivered or not. More messages may be transmitted at once and will be processed at once, in such a case responses may occur out of order. | ||
==Platform Requirements== | |||
===Firefox OS Modifications=== | |||
Firefox OS needs a HTTP/2 implementation and WebPush. | |||
===Cloud Services Channel Service=== | |||
The Cloud Services Channel Service (fondly pronounced '''koos'''-koos) handles the server-side termination of the channel from each device. These servers run HTTP/2 and terminate the WebPush connection along with multiplexing HTTP traffic to the internal message streams. | |||
Channel Service is deployed as a series of clusters, each managing about 2-3 million clients, with a dozen or so nodes when under full load. Each Cluster has a single Inbound Relay and Outbound Router for messages respectively sent to and received from upstream Services. Every inbound message ID has a cluster prefix so that the service knows which Outbound Router the message should be sent to for a response. | |||
Services utilizing ChannelService may be deployed as a central service that talks to all the clusters, or could be deployed per cluster if that arrangement is better suited to the service. | |||
The Central Service model of interaction with the ChannelService: | |||
NEW_IMAGE_COMING_SOON | |||
The | The Distributed Service Model of interaction: | ||
NEW_IMAGE_COMING_SOON | |||
==== Connection Nodes ==== | ==== Connection Nodes ==== | ||
| Line 166: | Line 147: | ||
These nodes are responsible for: | These nodes are responsible for: | ||
* Routing inbound-client | * Routing inbound-client requests to the appropriate Services Inbound Relay | ||
* Routing outbound-client | * Routing outbound-client data received from Outbound Routers (in response to WebPush Endpoint push requests) | ||
* | * Routing outbound-client responses from Outbound Routers (in response to an incoming HTTP request) | ||
* Broadcasting to the Outbound Router indicating what WebPush channels are connected to this node | |||
* Holding very high quantities of connections to clients | * Holding very high quantities of connections to clients | ||
| Line 179: | Line 160: | ||
Inbound relays are responsible for: | Inbound relays are responsible for: | ||
* Accepting messages from connection nodes for | * Accepting messages from connection nodes for services | ||
* Spooling a small amount of messages if a service is not available to relay them to | * Spooling a small amount of messages if a service is not available to relay them to | ||
==== Outbound Router ==== | ==== Outbound Router ==== | ||
| Line 187: | Line 167: | ||
Outbound routers are responsible for: | Outbound routers are responsible for: | ||
* | * Using their local mapping to determine what ConnectionNode to deliver to for a MessageID | ||
* Holding connections to | * Holding connections to ConnectionNodes for message delivery | ||
* Sending messages to deliver to | * Sending messages to deliver to ConnectionNodes and indicating whether they were delivered or not | ||
* Informing the service if a | * Informing the service if a MessageID can't be responded to | ||
* Informing the service if a WebPush Endpoint can't be sent to | |||
==Code Repository== | ==Code Repository== | ||