Author, instructor, ultra-marathon runner Peter Lubbers gives a talk at the San Francisco HTML5 User Group he founded, discussing the latest news in the exciting HTML5 feature area of Real-Time and Connectivity.

There is a lot of new stuff to talk about when it comes to the related HTML5 APIs and protocols. For example, the official RFC (RFC 6455) for the WebSocket protocol was recently published and it has changed significantly since its earlier protocol drafts.

Join SFHTML5′s own Peter Lubbers as he takes an in-depth look at WebSocket, Server-Sent Events, XMLHTTPRequest Level 2, Cross Document Messaging, and related standards like CORS and SPDY. These HTML5 features will allow you to easily build kick-ass web applications with unparalleled functionality, speed, and responsiveness. Pay attention and you might even win a signed copy of Peter’s latest edition of Pro HTML5 Programming.

Tavant Technologies, a leading provider of specialized IT solutions and services, and Kaazing, leading provider of technology for the living Web, today announced that the two companies have established a technology partnership. The partnership with Kaazing will enable Tavant to offer the most secure, real-time web communications platform to deliver a wider breadth of enterprise applications to its customers.

You can read the full press release: Tavant Technologies Partners with Kaazing to Deliver Real-Time Web Applications - Kaazing’s WebSocket Platform Accelerates Time to Market for Social, Mobile and Cloud Initiatives

There’s a lot of fud out there around WebSocket security that can only be tackled by learning about those concerns and how they can be addressed. Here are a few snippets from our Delivering Security Over Native Full-duplex Web Connections paper with this very objective in mind:

Security within the WebSocket standard is simple and certain, as long as the WebSocket solution you use implements it, since it’s not enabled by default. The WebSocket standard takes care of core security by providing for unencrypted and encrypted transport, and by defining WebSocket as a frame within which all existing security protocols can operate. However, because WebSocket is a standard and not a development environment, the inherent security features are somewhat limited.

Often, security features have been limited at a high cost – one that obstructs the creation of robust, full duplex web applications. Developers are often faced with the difficult design and coding challenges, trying to figure out how to work within or around limitations without frustrating their users with awkward and time consuming processes.

The WebSocket standard is sufficient to secure traffic (if its security features are used). It supports whatever security is in place. But securing the flow is only part of the real security challenges you face. That traffic has to be able to seamlessly traverse proxies and firewalls. Issues of authentication delay and obstruct the web experience.

If you’re in a couch potato mood today, just lean back and  let me walk you through our quick start guide. You’ll see messages sent back and forth between browsers (a’la chat), messages bundled up into JMS transactions, and a streaming stock demo. All in less than 6 minutes (including download, install, and start-up). Ready for the ride?

ITOCHU Technology and Kaazing, leading provider of technology for the living web, today announced that the two companies have entered into a partnership. By working with Kaazing, ITOCHU Technology can now offer its customers in Japan and the United States the most secure, real-time web communications platform for new enterprise applications.

Being the first to offer Kaazing’s solutions to the Japanese market allows us to continue to build on the leadership we have built over decades by introducing some of the most important, market changing technologies to Japan,

said Shinichi Uemura, President and CEO, ITOCHU Technology – which introduced Sun Microsystems, Cisco Systems, Oracle and Siebel Systems to Japan.

Read the full article…

First, this isn’t something you need to loose sleep over, your WebSocket server should take care of this automatically for you, that is falling back to the most efficient emulation if native support is not available (for whatever reason, such as browser limitations or proxies or other network intermediaries breaking the native WebSocket connection). The Kaazing WebSocket Gateway does this exceptionally well in a 100% transparent manner, providing virtually the same performance with emulation as native WebSockets – for details see the Industry’s Best WebSocket Emulation post.

Possibly the easiest way to confirm whether your connection is native or emulated, is by using the Chrome or Safari Developer tools. Point your browser to http://websocket.org, and bring up the Developer Tools (Safari: Develop > Start Debugging JavaScript, Chrome: View > Developer > Developer Tools). Select Network, and optionally the WebSocket filter down below. Upon establishing the WebSocket connection, a new entry shows up in the Path column. Click the path to see its contents information about it.

If the WebSocket connection is native, you’ll see an HTTP request with the Upgrade header: WebSocket and an HTTP response with Upgrade header: WebSocket.

In case of emulation, you won’t see the upgrade header in the response:

In this recorded presentation we walk through the challenges the legacy Web is posing and how HTML5 and WebSockets are changing it into a new, living Web. In the webcast we discuss questions like HTML5 and WebSocket support in older browsers, the WebSocket API and protocol, trends how the full duplex low latency messaging will change enterprise topologies, and how higher level business protocols can be extended all the way to desktop browsers and mobile devices.

This 3 minute demo features a windows machine running a VNC server. The Windows desktop is accessed remotely from a vanilla Safari browser, simply leveraging the canvas tag and WebSockets.

First you see an environment Windows running as a virtual machine, then I show two physical machines connected, and last I walk through the building blocks used for the demo.

All you need is:

1. A desktop browser: The game is “hosted” by the desktop browser. It renders the UI of the game using HTML5 canvas and WebGL.
   Note: You can check here if your desktop browser supports WebGL.
2. A smartphone (with a browser): Smartphones can take a variety of input source, like touch, tilt, GPS, proximity, compass, camera, microphone. Many of these input sources are accessible from JavaScript, allowing you to easily control your game.
3. A WebSocket server: The desktop and the smartphone(s) have to communicate through a fast, low latency channel – exactly what WebSocket was designed to do. The WebSocket standard doesn’t provide peer-to-peer connectivity, so you’ll need a server that routes the messages between the smartphone(s) and the desktop.

If you use a WebSocket server, like the Kaazing WebSocket Gateway that provides higher level protocols on top of WebSockets, your architecture can be kept very simple. You don’t need to write a single line of server-side code, the JavaScript code running in the desktop browser and the smartphone do all the work.

To demonstrate the power of no server-side code, we built a demo using the Java Message Service (JMS) edition of the Kaazing WebSocket Gateway. The advantage of using JMS in your JavaScript code directly is that with the pub/sub model of JMS you can very easily direct the messages between the smartphone(s) and the desktop browser.

The flow for the player is very simple:

1. Bring up the game in your desktop browser: http://demo.kaazing.com/racer
2. Enter the URL in your smartphone browser, as shown in the bottom of the desktop browser: http://demo.kaazing.com/racer/ws
3. Enter the unique ID when prompted by your smartphone. This unique ID connects the game instance running in your desktop browser to the smartphone you use as your remote controller.

The race car is controlled simply by tilting your phone. Tilting the phone triggers JavaScript events which result in JMS messages sent through the WebSocket gateway to the desktop browser.

Note: For this demo to work you need a smartphone that supports the JavaScript tilt APIs. We tested the demo with devices running iOS 4 and above.

After watching the video how it works, take it for a test drive.