Earlier today we launched Super Sync Sports, a Chrome Experiment. It’s an interactive web game that enables up to four friends to compete in running, swimming and cycling events on a shared computer screen, using their smartphones or tablets as game controllers.



Super Sync Sports was built with the latest browser technologies:

• Touch APIs to recognise gestures made on your smartphone and tablet. 
• WebSockets are used to deliver immediate real-time playback across all the players in your group and to update the main game screen as you play. 
• Finally, CSS3, SVG and Canvas provide rich visuals and an immersive experience. 

In the next few weeks, we’ll be publishing an article on HTML5 Rocks with more information on how we built this experience. You can follow +Google Chrome Developers to learn when the article will be live.

In the meantime, enjoy competing with your friends at chrome.com/supersyncsports and be sure to open Chrome’s developer tools to see what happens under the track!

Posted by Paul Kinlan, Developer Advocate

Earlier today we launched JAM with Chrome. JAM with Chrome is an interactive web application that enables friends in different locations to play music together in the Chrome browser on their computers.



JAM with Chrome was built with the latest browser technologies:

• Web Audio for high fidelity playback without resorting to lots of pre-recorded audio samples. 
• WebSockets is used to deliver immediate real-time playback across all the members of the band ensuring they stay in sync and playing from the same tab sheet. 
• Finally, CSS3, SVG and Canvas provide rich visuals and an immersive experience.

To learn more about how we built this experience, check out “How we made the Audio rock”. This is the first of three HTML5 Rocks articles that describes how the team used Web Audio to deliver an absorbing auditory experience. Stay tuned for more developer stories by following +Google Chrome Developers.

Enjoy playing music with friends at www.jamwithchrome.com and be sure to open Chrome’s developer tools to see what’s going on backstage!

Posted by Paul Kinlan, Developer Advocate

The WebSocket protocol specification is now largely stable, having solved previous security concerns. As such, we’ve updated Chromium to support the latest version (draft-ietf-hybi-thewebsocketprotocol-10) on the dev channel (14.0.835.2). Given that the specification is now in “last-call” and and no further breaking changes are expected, it should now be safe to use WebSockets for production application development.

Please note that the new protocol is incompatible with one which Chromium previously supported (draft-ietf-hybi-thewebsocketprotocol-00), so existing WebSocket-based services may break. Please upgrade your servers to ones which support HyBi 10. Existing JavaScript code still works once the protocol version used by the browser and server match.

The new protocol introduces some exciting new features like binary message support and compression support, but these are not quite ready yet in Chrome and will come shortly - hang tight!

See the specs and discussion at W3C and WHATWG (spec, whatwg list) and IETF (spec, HyBi list) for more detail about the new protocol.

We’re more than happy to hear your feedback, and encourage you to file any bugs you find on our issue tracker.

Posted by Takeshi Yoshino, Software Engineer

WebSocket is "TCP for the Web," a next-generation full-duplex communication technology for web applications being standardized as a part of Web Applications 1.0. The WebSocket protocol is more efficient than HTTP as used in Ajax, so it is more suitable for real time and dynamic web applications. WebSocket also provides a very simple API that can be used to communicate bidirectionally between the web browser and a server, so it makes it easy to develop such web apps.

We initially implemented WebSocket in WebKit, which has been available in WebKit nightly builds and in Google Chrome. The initial implementation was based on draft-hixie-thewebsocketprotocol-75. Early adopters were able to start developing web apps using WebSocket on real browsers, and provide feedback about the WebSocket specification.

Based on community feedback, the WebSocket specification has been updated to draft-ietf-hybi-thewebsocketprotocol-00 (also known as draft-hixie-thewebsocketprotocol-76).

This version relaxes requirements on handshake messages to make it easier to implement with HTTP libraries, and introduces nonce-based challenge-response to protect from cross protocol attacks. These changes make it incompatible with draft-hixie-thewebsocketprotocol-75; a client implementation of -75 can’t talk with a server implementation of -76, and vice versa.

Developers should be aware that starting from WebKit nightly build r59903 and Chrome 6.0.414.0 (r47952), the client will talk to a server using -76 version of the protocol, so it will fail to open WebSocket connections with a WebSocket server based on draft-hixie-thewebsocketprotocol-75. Since -75 version of the protocol is obsoleted and no longer supported in future version of browsers, to support new clients you need to update the server implementation. (Note that Chrome 5 uses -75 version of protocol).

The WebSocket protocol is still actively being changed. Until there is more consensus, we will continue to update our implementation to follow the latest draft of specification, rather than worrying about breaking changes.

We’re more than happy to hear your feedback, and encourage you to file any bugs you find on our issue tracker.

Posted by Fumitoshi Ukai (鵜飼文敏), Software Engineer

Starting in the Google Chrome developer channel release 4.0.249.0, Web Sockets are available and enabled by default. Web Sockets are "TCP for the Web," a next-generation bidirectional communication technology for web applications being standardized in part of Web Applications 1.0. We've implemented this feature as described in our design docs for WebKit and Chromium.

The Web Sockets API enables web applications to handle bidirectional communications with server-side process in a straightforward way. Developers have been using XMLHttpRequest ("XHR") for such purposes, but XHR makes developing web applications that communicate back and forth to the server unnecessarily complex. XHR is basically asynchronous HTTP, and because you need to use a tricky technique like long-hanging GET for sending data from the server to the browser, simple tasks rapidly become complex. As opposed to XMLHttpRequest, Web Sockets provide a real bidirectional communication channel in your browser. Once you get a Web Socket connection, you can send data from browser to server by calling a send() method, and receive data from server to browser by an onmessage event handler. A simple example is included below.

if ("WebSocket" in window) {
  var ws = new WebSocket("ws://example.com/service");
  ws.onopen = function() {
    // Web Socket is connected. You can send data by send() method.
    ws.send("message to send"); ....
  };
  ws.onmessage = function (evt) { var received_msg = evt.data; ... };
  ws.onclose = function() { // websocket is closed. };
} else {
  // the browser doesn't support WebSocket.
}

In addition to the new Web Sockets API, there is also a new protocol (the "web socket protocol") that the browser uses to communicate with servers. The protocol is not raw TCP because it needs to provide the browser's "same-origin" security model. It's also not HTTP because web socket traffic differers from HTTP's request-response model. Web socket communications using the new web socket protocol should use less bandwidth because, unlike a series of XHRs and hanging GETs, no headers are exchanged once the single connection has been established. To use this new API and protocol and take advantage of the simpler programming model and more efficient network traffic, you do need a new server implementation to communicate with — but don't worry. We also developed pywebsocket, which can be used as an Apache extension module, or can even be run as standalone server.

You can use Google Chrome and pywebsocket to start implementing Web Socket-enabled web applications now. We're more than happy to hear your feedback not only on our implementation, but also on API and/or protocol design. The protocol has not been completely locked down and is still in discussion in IETF, so we are especially grateful for any early adopter feedback.

Posted by Yuzo Fujishima (藤島 勇造), Fumitoshi Ukai (鵜飼 文敏), and Takeshi Yoshino (吉野 剛史), Software Engineers