CSC/ECE 517 Spring 2015 M1502 WSRA

Implement Rust Websocket

This project concentrates on implementing Rust WebSocket API for Mozilla's web browser engine, Servo

Introduction

Servo<ref> https://github.com/servo/servo </ref> is a Web Browser engine written in Rust. It is an experimental project build that targets new generation of hardware: mobile devices, multi-core processors and high-performance GPUs to obtain power efficiency and maximum parallelism. Implementing WebSocket API for the Servo engine would allow a persistent single TCP socket connection to be established between the client and server that will provide bi-directional, full duplex, messages to be instantly exchanged with little overhead resulting in a very low latency connection and supporting interactive, dynamic applications.

Rust

Rust <ref> https://github.com/rust-lang/rust </ref> is a Systems programming language built in Rust itself that is fast, memory safe and multithreaded, but does not employ a garbage collector or otherwise impose significant runtime overhead. Rust is able to provide both control over hardware and safety which is not the case with other programming languages like C, C++, Python that provide only either control or safety but not both.

WebSocket

WebSockets is a protocol that provides full-duplex channel for a TCP connection and makes it possible to open an interactive communication session between the user's browser and a server. With WebSockets, you can send messages to a server and receive event-driven responses without having to request the server for a reply. The WebSocket specification defines an API to establish a "socket" connection between a web browser and a server. This establishment involves a handshake following which there is a persistent connection between the client and the server and both parties can start sending data asynchronously.

Cargo and Crate

Cargo <ref>http://doc.crates.io/guide.html</ref> is a application level package manager that allows Rust projects to declare their various dependencies. Cargo resembles the Bundler in Rails that is used to run Rails app, install required Gems mentioned in the Gemfile. Gemfile correspond to Cargo.toml file and Gem correspond to Crates

Cargo introduces two metadata files with various bits of project information, fetches and builds project's dependencies, invokes rustc or another build tool with the correct parameters to build the project.

Project Description

The goal of this project is to implement WebSocket functionality in to Servo using the Rust WebSocket project. Once this is completed, tests following the HTML spec [1] for websockets should pass, as the same spec will be driving development. The project will be completed when the following conditions are true, and all tests have passed.

• The client can establish a websocket connection
• The client can send objects to the server through the websocket
• The client can receive objects from the server through the websocket
• The client can successfully close the Websocket

If Servo, as the client, is able to successfully perform all of these tasks, then our project will be completed.

Requirement Analysis

The requirements for the implementation is well detailed in the HTML spec shown here [2]. The majority of the requirements have to do with the feedback for the protocol. The entire reading can be seen there.

Outside of the HTML spec, a couple other requirements are necessary. First, Servo must successfully compile with the websocket components included. There are a number of warnings currently with compiling Servo not related to Websocket, but no new ones should be introduced.

Second, we should pass a set of tests already included in Servo's tests/wpt/web-platform-tests/websockets directory. These tests determine if the current websocket implementation fulfills all the requirements for Servo's use.

Finally, we should successfully issue pull requests for each feature as it is completed.

Implementation

When the WebSocket connection is established, the user agent must queue a task to run these steps:

• If the WebSocket object's client-specified protocols was not an empty list, but the subprotocol in use is the null value, then fail the WebSocket connection, set the readyState attribute's value to CLOSING, and abort these steps.
• Change the readyState attribute's value to OPEN.
• Change the extensions attribute's value to the extensions in use, if is not the null value.
• Change the protocol attribute's value to the subprotocol in use, if is not the null value.
• Act as if the user agent had received a set-cookie-string consisting of the cookies set during the server's opening handshake, for the URL url given to the WebSocket() constructor.
• Fire a simple event named open at the WebSocket object.

When a WebSocket message has been received with type type and data data, the user agent must queue a task to follow these steps:

• If the readyState attribute's value is not OPEN, then abort these steps.
• Let event be a newly created trusted event that uses the MessageEvent interface, with the event type message, which does not bubble, is not cancelable, and has no default action.
• Initialise event's origin attribute to the Unicode serialisation of the origin of the URL that was passed to the WebSocket object's constructor.
• If type indicates that the data is Text, then initialise event's data attribute to data.
• If type indicates that the data is Binary, and binaryType is set to "blob", then initialise event's data attribute to a new Blob object that represents data as its raw data.
• If type indicates that the data is Binary, and binaryType is set to "arraybuffer", then initialise event's data attribute to a new ArrayBuffer object whose contents are data.
• Dispatch event at the WebSocket object.

Design Patterns

Factory Pattern
For every web application application running on the web browser that requires a websocket for communicating with the server, a new thread needs to be spawned that creates a client end of the socket associated with the web app. Spawning this thread can be considered to be similar to instantiating an object for which Factory Pattern can be employed.
Thread Pool Pattern
Servo's primary objective was to provide concurrency. This concurrency can be attained by scheduling tasks which can be run in parallel. Threads help execute these tasks in parallel. Thread Pool Pattern helps manage these thread. For example, one thread could be to accept new requests for websockets, as a result of which new thread would be spawned (client side of websocket) for that application.

Proposed Test Cases

The test cases for websocket are already included in servo, under the Servo directory tests/wpt/web-platform-tests/websockets. To break down how each should be tested, here are the proposed scenarios:

• The send function should send some object, then wait for confirmation of sending.
• The constructor should make a websocket connection to the URL and either open the connection or close it based on the response coming in.
• The receive function should trigger on receiving an object, then send confirmation.

All of these are tested thoroughly in the directory given at the beginning of this section.

References

<references/>