HTML5 Real Time and WebSocket Code Lab (SFHTML5, GTUGSF)

Editor's Notes

• #5: http://mrdoob.com/projects/multiuserpad/
• #6: CollectdViewer plots the output of the collectd statistics collection dameon in the browser at a rate of 2x per second. Visithttp://bergmans.com/WebSocket/collectdViewer.htmlfor more information.
• #7: Rawkets – Developed by Rob Hawkes (Mozilla)
• #12: What WebSocket is really good for is real-time applications. You wouldn't necessarily use WebSockets for everything, but for real-time applications it has some real value. Imagine you want to have instant updates in your browser application. It's hard to get those instant updates in a scalable manner using existing techniques like Ajax or Comet. So WebSockets are good for all kinds of real-time activity, data, monitoring.Today everyone is under pressure to provide applications in the browser. Think about your browser usage: sometimes you open a tab in a browser and read a page, such as the news, and then you click a link which takes you to another page. You read that page, click another link, and so on. This is traditional browsing or surfing the web. But there is also another use case for browsers and that is applications. You open a tab in your browser and go to your Yahoo Mail or Gmail or whatever and you read some mails, send some mails, and so on. Now you're not surfing the web but doing something task-oriented. In fact you probably leave that tab open so you can return to it and check your mail over time. If it's a good email client, like Gmail it doesn't even have page refreshes but stays on the same page. Another example is banking. You open a new tab, go to your banking website and perform some tasks like checking your balance or transferring funds. When you're finished you close the tab (hopefully!). Again you're not surfing the web, but are doing something specific.This is like running traditional applications on a desktop. You open an application, do some work, then close it. Or some applications you probably leave open all day.Running applications in a browser has some nice advantages: users can run them from anywhere (home, work, mobile, overseas, etc). It also doesn't matter what the underlying operating system is. However there are also some barriers to creating applications for the browser. One of those is the GUI itself. This is why Flash (or Silverlight) is popular, because it allowed developers to create rich GUI interfaces which run in a browser. As you've been learning over the last couple of days, this trend of running applications in a browser is starting to be addressed by HTML5 and the standards it encompasses.But a big barrier to creating real-time applications in a browser is the network communication. Right now the only option for your application to communicate with the backend server is to use HTTP. An exception to that is to use sockets in Flash or Silverlight, but that comes with its own problems such as not being able to traverse firewalls and proxies which explains why that's not prevalent. For many applications, using HTTP is fine. But HTTP has limitations -- which we'll see -- which means that for many real-time applications it is not fine.Different aspects of HTML5 address different needs for real-time applications. And it's the WebSocket standard that addresses the communication needs.
• #14: Request/response drivenMust open two connections: one for upstream, one for downstream, but traffic can only flow in one direction at time (added latency)--Full-duplex communication is where data can travel in both directions simultaneously. A desktop application that communicates with a backend is typically full-duplex. HTTP is what is known as "half duplex". It is request-response driven. That is, a client sends a request to the server, and the server then sends a response back to the client. Only then can the client send another request. (That is with a single TCP connection. A browser could open another TCP connection and therefore be doing HTTP requests in parallel, but now you have multiple TCP connections. Browsers do this.)HTTP can also be said to be bi-directional. A clients sends a request one way, and the server sends a request the other way, so data can travel in two (i.e. bi) directions. But it is not full-duplex. With a socket connection that is full duplex, a client can send multiple messages to a server while at the same time the server can send multiple messages to the client. There is no need to have to wait in a request-response fashion.
• #15: So HTTP is not the optimal protocol for this kind of communication.In addition, every HTTP message comes with a set of headers on top of the actual data payload. This means every time you poll – "Do you have a message for me?", "Do you have a message for me?" – it includes the HTTP headers, too. So that's additional stuff in addition to the payload.
• #16: The Web was originally designed for this request-response and the way to get real-time data would you have to refresh over and over, many times. So the next thought was to build this refreshing in under the covers, and you can do that by using Ajax. Ajax is common today and with it you can communicate to the server and then update the page without a page refresh. To an end user it gives the appearance of a low-latency real time application.(Back to diagram) So if you have an HTTP request to ping the server, "do you have some data?", and then process that and display that on the page.. You can do all that and it makes for a pretty dynamic looking page. You can do that once a second, even. The user wouldn't be any wiser. It would seem like a responsive application even though you're polling. But even though the user doesn't see it, the browser is still sending all of these messages constantly to the server so you can imagine the kind of traffic that's going over the wire.
• #17: Three ways to request info: polling, long-polling, and streaming
• #19: Never-ending request to the server. There’s no response.Very efficient but not legal HTTP – should be request/response (proxies/firewalls do expect this information to be long-lived, so it waits/buffers until it’s complete, which then causes problems)You can only make so many connections to one domain
• #22: And when the server responds it also has the HTTP Response Headers. And this hasn't included any data yet. The data, remember, is the prices of the stock.In this example the overhead was 871 bytes. Sometimes it's lower but it can also go quite a bit higher. In the range of 1,000 bytes is common.
• #25: Ian Hickson, the HTML5 spec lead, has an interesting quote. Because of the latency reduction and reduction in the number of bytes going over the wire – these are huge to Google who operate on a such a scale that any saving in network traffic is worthwhile. So this will probably guarantee that WebSocket has a prominent place in the future.Think of, for example Google Docs. If I'm in a Google Doc and Bob is too, I can see changes as he's making them; almost character for character. Imagine what that looks like without WebSocket. You're polling and for every character a user types, that 1 byte requires nearly 1,000 bytes of header traffic. That just doesn't scale.So you can see that in lots of different areas, such as where you pay for your bandwidth, or mobile communication, cloud computing it suddenly becomes interesting to reduce your header throughput by 1000x.
• #26: This is where WebSocket enters the picture. WebSocket is a new HTML5 API, but also it was clear that you couldn't necessarily just keep building on the same HTTP protocol. So WebSocket is also a new protocol as well.
• #27: Does anyone know what WebSockets have to do with model trains? Ian Hickson, who works for Google, is the HTML5 spec lead – not just for WebSocket but for all of HTML5. He does this both in WHATWG and W3C. And he is a big fan of model trains and had been playing with them for a long time (since before the internet was invented). He wanted to be able to control a model train from a browser, but just wanted a TCP connection running his own protocol to connect to the train controller. But of course you can't open a full-duplex socket connection from a browser. So he started doing it with techniques, called things like Ajax or Comet, available at the time. Other names are "long polling" or "hanging get.” But all of these techniques involved polling or querying the server for an update as well as translating text-based data to TCP-based data and overall it was an inefficient and painful process.So Ian added something called "TCP Connection" to the HTML5 spec. At that point Kaazing had been going for a year, and they were working on building a better Comet server. When they saw the "TCP Connection" in the spec, they realized it was what they needed: a socket connection in a browser. So almost from one day to the next they realized they could throw out what they'd been doing and begin contributing to the spec. The bulk of WebSocket today comes out of the work of Kaazing, although it's now an open standard and driven by the community including the likes of Apple, Google, browser vendors, and so on.So if want to build a model train controller, it will now be much simpler with WebSockets. 
• #29: So there is the WHATWG that first created these new ideas. Then things are proposed to put into the official HTML5 spec, under W3C. But protocols are typically handled by IETF (Internet Engineering Task Force). We are actively involved in IETF meetings about the protocol.WebSocket is a protocol that allows you to create a full-duplex text-based socket. I say text-based because that's what it does at the moment, but there's already work in the spec to make a binary socket connection. In fact at Kaazing we've already implemented binary sockets. It's pretty easy to do if you have that WebSocket foundation. What's nice with WebSockets is that they are able to share ports with existing HTTP traffic. It starts out as an HTTP handshake and then upgrades the underlying TCP connection to WebSocket. The first thing in the handshake is where the client says to the server, do you speak WebSocket. The server says yes and agrees to upgrade to the WebSocket protocol.It's cross-domain capable so it implements the CORS spec. And this is already powerful by itself, letting you do things you couldn't do with Ajax or Comet.And because of this HTTP handshake it can run over port 80 which means you don't have to open separate ports in firewalls and proxies.
• #30: You can use JavaScript to evaluate if the browser has native support for WebSocket using code like this.Demo: Open Chrome, Ctrl-Shift-J for console, and type "window.WebSocket” The same thing in other browsers comes back blank or undefined indicating no native support.
• #31: The WebSocket API is straightforward and simple to use.First you create a new WebSocket and you pass in the WebSocket URL using the WebSocket scheme (ws://).Then it's a matter of associating these listeners. It's similar to actual socket programming: you have a listener so you know when messages arrive and then you can process them. It's truly asynchronous; you don't know when you're going to get this message. You're not polling anymore, you just get messages when they arrive.You have a listener for onopen so that you can react once the connection is open. Similarly you have an onclose listener to take any actions you want when the connection is closed. The main one is the onmessage listener so you can react every time a message arrives.
• #32: With WebSockets you can also send messages back to a server. This is the full-duplex part. You use the send() function and simply specify the message you want to send. It's very easy.A close() function is used to end the connection.
• #37: Having all of those servers with WebSocket support is great but to use them, you need a browser that supports WebSocket. Today only the Google Chrome and Safari browsers do that. So what do you do for users who are using other browsers? In particular there are a lot of corporate environments that strictly control browsers and versions. There are a surprising number of companies that are still on IE6, particularly in the financial industries. You have little hope of getting them onto Chrome or Safari just so they can use WebSocket.The solution is emulation. One way is using Flash. Flash has a way that lets you open a socket. With Flash, though, for secure WebSocket connections you need to host what is called a policies file and to host that it needs to be on a different port which means opening a new port in the firewalls. This negates the whole point of running on port 80. And as we'll learn later, in an enterprise environment when you start having proxy servers in the middle, a lot of the WebSocket connections don't work anymore. To counter that you need secure WebSockets. So the Flash emulation is not a great solution. Also, remember, Flash doesn't work on the iPhone or iPad.At Kaazing we spent a lot of development effort getting client emulation right. It is plugin-free and completely transparent so a developer doesn't have to care if the browser supports WebSocket or not. When you use the Kaazing client libraries it introspects the browser. If it supports WebSocket then great, if not, we automatically fall back to emulation mode. As far as the developer is concerned they are using the same API and have no idea if the browser is using native WebSocket or not. In either case their application just works.And when emulation kicks in because you're using a browser that doesn't support WebSocket, the performance is almost as good as native WebSocket itself. So even in the fallback scenario of using emulation, you still get better performance and scalability that can be done by the best Ajax or Comet solution today. The Kaazing client emulation will work in all browsers, including the dreaded IE6, so you aren't forced to wait until browsers get around to implementing WebSocket natively in the browser.
• #43: - Former author: Ian Hickson, Google- Current authors: Ian Fette, Google and Alexey Melnikov, Isode- Former IETF HyBi Working Group co-chair - Joe Hildebrand, Cisco- Current IETF HyBi Working Group co-chairs - Salvatore Loreto, Research Scientist, Ericsson Research, Finland - Gabriel Montenegro, Microsoft- Last Call notification: http://www.ietf.org/mail-archive/web/hybi/current/msg07725.html
• #44: This is what the handshake looks like. If you use the WebSocket API, this is what happens under the covers. It's normal HTTP, and in the first part, the GET, there is an "upgrade" header asking for an upgrade to WebSocket. This header triggers a response from the server which agrees and returns a bunch of headers back to the client with the origin and information on how to establish the WebSocket connection.
• #45: Once you have this WebSocket connection setup you can start sending WebSocket frames. Again, you don't have to worry about creating these frames, you just use the WebSocket API to send your message – this is done under the covers. Your message is taken and put into a WebSocket "frame" that starts with hex-0 and ends with hex-FF bytes, and contains your data in UTF-8 format.You send this data along and effectively there's no real limit to how much data you can send. All of the chunking and lower-level stuff is done for you by the protocol. When binary support is added, the protocol will most likely add a length prefix because binary data may contain hex-0 and hex-FF bytes.
• #48: Remember when we looked at HTTP earlier and saw an example with 871 bytes of header data? For WebSocket that number is 2 bytes. It's always fixed at 2 bytes while HTTP is variable. So you're going from 871 bytes to 2, which is huge reduction in overhead.We didn't explicitly cover it before, but each HTTP message is a brand new TCP connection which comes with some overhead. WebSockets maintain the same TCP connection. So you have two nice advantage of WebSocket over HTTP.
• #50: Here is a graphical view of the data which shows the dramatic reduction in overhead relative to Ajax or Comet for any number of clients.
• #51: Additionally you have a huge latency reduction because every time, as you can see in the polling example, you have a request and response. And each time a request has to be fired from the client. In the meantime, once the WebSocket upgrade has passed and WebSocket connection is established, the server can send messages at will. It doesn't have to wait for a request from the client.So you get 3x improvement in latency with WebSocket.
• #52: Run by the Jetty folks on their optimized Comet server. Emulated a chatroom on EC2. Left: Comet implementation, 2-4ms latency for 5-50K emulated clients @ 10Kmessages/sec. Starts climbing linearly from there up to around 180ms @ 50K messages/sec, except for the 50K client case (hits an internal network limit @ Amazon.)Right: WebSocket implementation of same. 2-4ms latency for all cases _except_ a new 200K client setting that looked like it would start hitting the same internal network limit. (4x as many client, still 5-6 msec.)
• #55: Objective – to show how a real application can be developed using WebSockets.Distributed applications require sending messages between two or more entities. For large, complicated system, the use of existing message broker software can simplify message handling. A standard API, known as the Java Messaging Service (JMS) API has bee developed to provide a standard way for Java applications to interface with these brokers.Kaazing WebSocket Gateway provides JavaScript libraries to access JMS broker via WebSocket
• #56: Client server programming for the web--So what can you do with WebSocket? WebSocket is really nice, you have a way to speak to a remote server using this full-duplex communication. And the remote server can be anything, any WebSocket endpoint – a message broker, a database, a chat server, a game server, a web server, etc.Look at a desktop client that uses a socket, what do you do? Do applications send data back-and-forth in raw TCP? No. TCP is the transport layer and you run more useful protocols on top of that. If you're talking to a web server you'll use HTTP, which runs on top of TCP. If you're talking to a chat server, you'll use XMPP, which runs on top of TCP. If you're talking to a database then you'll use JDBC (if you're in Java), which runs on top of TCP.So the most useful aspect of TCP is that you don't actually use TCP, but rather you use higher-level protocols on top of it.And WebSockets are sockets, for the web. You can pass data back-and-forth using raw WebSockets if you want. But the most useful aspect of WebSocket is that it allows you to run higher-level protocols on top of it. Remember why we are doing this in the first place: because we have some back-end system and we want to build browser-based applications that can communicate with it. But these back-end systems already have some protocol to talk to them. And now with WebSocket can you use that protocol directly from the browser.Here's another way to look at it. If you have a client talking to a server (the middle-tier server, in this case) they have to agree on a contract. That is, they need to both understand the same protocol. If the server is sending stock data such as "ORCL: 23.45, MSFT: 18.63, IBM: 126.92,” then the client needs to be able to understand it so it can parse it. So you're effectively creating your own syntax or protocol.But there might be something out there for a variety of things you want to do. If I'm building a chat application I can say that I'm expecting my messages to look a certain way. But someone's done that already, it's called XMPP and it's been around a long time. Why not take advantage of protocols that are already created? This is what people do with socket programming. They don't send data out on raw TCP, but use these higher-level protocols (like HTTP, XMPP, etc.). WebSocket is like client-server for the web. While you can use WebSocket by itself to send data, the real value comes from being able to run higher-level protocols on top of it.There are protocols for publishing and subscribing, for gaming, and so on. With WebSocket you can extend any TCP-based protocol.Going to the Web was a big step forward in most regards, but it was a big step backward in others. But now the browser is a first-class network citizen. It's like a desktop application you might have on an intranet. I like how some other person put it: “With WebSocket, the Web just got an upgrade.”
• #66: Point to demo – rememberwhen we logged into Google Chat and chatted in real time.
• #68: Draw diagram on thewhiteboardthat shows ActiveMQ is the message broker and Stomp is the protocol thatletsyou talk to the server
• #78: Required to prevent unwanted eavesdropping, man-in-the-middle attacks, and packet sniffingHTTPS is HTTP running on top of a TLS connection (default port is 443)
• #91: If you want to be sure, use WebSocket Secure!
• #92: DiagramBrowser (WS)  Load Balancer -> WS Service