ref.Kyle Simpson

WebSockets, this will be the last thing that we talk about HTML5 at the moment. Now, I’m not going to actually show you a facade for WebSockets, I’m actually going to show you a snippet of code that comes from a framework for WebSockets, and there’s a purpose to that. I initially had envisioned that someday I would write a WebSockets client facade. A facade that wraps around the client API for WebSockets, because there is a client API it’s capital w, capital s, WebSockets and it’s built into the browser.

So if there’s a native API for it, we should have a facade, that was my initial goal. But I got to realizing that most of, almost everybody, I don’t think I’ve ever met somebody, that actually does WebSockets directly against the API. The primary reason for that is that we’re all using frameworks because we not only have to do the client side, but we also have to do the server side. And the server side is a lot harder. And so we use frameworks like Socket.IO, or Pusher, or any of these other ones, and those frameworks already wrap around the client for you.

So there’s just a much less need for a facade, it doesn’t mean that there’s zero need. But it’s a lot lower on the priority list. So I’m actually going to show you Socket.IO. That’s just because I’m most familiar with it. I’m not at all saying it’s the best, it hasn’t been updated in a while, and it may or may not even be alive as a project, I don’t know, but it’s the one I’m most familiar with, so that’s the one I’m going to demonstrate today. There’s lots of other ones. So, what is WebSockets all about? Well, when we talk about communication technologies, we know that we’ve got Ajax, we’ve had that for years.

We know that involves a round trip from the client browser back to the server and then back. And the problem with those Ajax requests from a performance perspective is the overhead involved in the client initiating a request, the server initiating a response thread, and responding, and all of that transfer of data, and plus all of the overhead because HTTP packets have 1,200 or more bytes for every single, you know, request that’s getting sent across and things like that. So, these sorts of requests are not terribly efficient.

They work when we just, you know, once every couple of minutes we need to ask for an update, but if you’re asking for something five times a second, you don’t want to be making Ajax requests, it’s highly inefficient. So, there’s a whole class of things that we wanted to do with the web that we really couldn’t do because Ajax just wasn’t performance enough for us to do, real time gaming for instance, if you’re playing a first person shooter game you’re expecting, you know, in terms of your ping time and your latency, you’re expecting thirty, forty milliseconds at the longest.

Or you’re just going to lose because everybody else’s screen is updating faster than yours. Well we couldn’t do that with Ajax it just wasn’t practical. So the web was limited in terms of its capability. So, think about Ajax as a communication medium. Ajax was capable in general just as sort of a general broad brush thing. On the global scale. As an average, an Ajax request probably averages anywhere from 500 to 800 milliseconds total roundtrip.

From the time you make the request to the time you get a response back. 500 to 800 milliseconds is just a general average. When we start talking about WebSockets a different technology entirely, well not entirely. But, it makes the initial HTTP request, there’s an initial roundtrip. So we have that initial latency. But then we keep the socket open. It’s a persistent socket. So we keep the WebSockets open and the next time we need any interchange in either direction the server to the client, client to server, or both, we don’t have to establish a new connection.

We have that connection already established. And rather than needing to send a packet that might have 1,200 or more bytes as the header, the overhead the WebSockets header is eight bytes, which is drastically smaller. So we’re sending a lot less information we have a persistent socket so we’re not paying the penalty to open up and close connections all of the time. And we see again a general average that if you’re able to establish a WebSockets connection on average you’re going to get anywhere from 50 to 100 milliseconds latency in terms of your roundtrip times and communication, so we drastically reduce from 500, 900 milliseconds, that huge range all the way down to 50 to 100 milliseconds, almost an order of magnitude in terms of improvement.

But even 100 milliseconds is still too slow for a lot of things. Even 100 milliseconds, if that was the roundtrip time, might be too slow for the most high performance of games. Not all games are too slow for that. So, I worked at gaming company a couple of years back. I won’t name them. But they’re a big gaming company, you probably know about them. And we built an online game that was a Bingo! game and Bingo! is a real live thing, I’m playing against other people. But, the difference between 100 milliseconds and 90 milliseconds isn’t usually going to determine different winners.

There is a possibility of that but for the most part that game play could tolerate WebSockets and so, we built the game off of WebSockets. Certainly it would not have tolerated Ajax. You know, if we had 60 million people playing, based upon Ajax technology not only would that have killed our servers but it also, everybody would have been going too slow if they were having to wait a whole second or more to hear back responses on the Bingo! calls or whatever. So WebSockets enabled a whole bunch of other things that couldn’t be done before. Real-time stock updates and things like that.

Let me take just a moment by the way to talk about real-time for a moment. That phrase real-time is kind of misnomer because I took computer science I don’t know if any of you took computer science, but I remember I had this crotchety old professor that was so mad when anybody would use the phrase real-time dealing with software because they almost never actually meant real-time. He had actually spent time writing true real-time software for things like controlling a nuclear reactor.

Where the response time had to be sub-millisecond microsecond, nanosecond type response times. And that’s the kind of software that he thought of when he heard the phrase real-time. We’re obviously not talking about microsecond response times in our software. Alright? You’re going to have to find an entirely different line of work if that’s the kind of stuff you want to do. So when we say real-time, we don’t really mean real-time in that sense. We mean nearer real-time, we mean nearer immediate and it’s the spectrum. So full page requests back in the HTTP 1.0 days could take anywhere from two to twenty or thirty seconds to load up a whole brand new page.

Way too long to get any kind of information update. Then Ajax moved us down to around a second, or maybe two seconds at the most for most Ajax responses to come back. And now WebSockets have gotten us down to that around 100 milliseconds or somewhere below 100 milliseconds so its opened up a whole new world of things that we can do. And WebSockets are really powerful. Where we’re headed by the end of today is that we’re going to talk about that next leap in terms of technology and whatever, when we talk about peer-to-peer technology and where that’s going to get us in terms of latency. – [Audience Member] I have a question.

– [Kyle Simpson] Yeah. – [Audience Member] Does it take more bandwidth for WebSockets? – [Kyle Simpson] It takes a different kind of resource usage. The question was does it take more bandwidth. It’s a different kind of resource usage when you think about how WebSockets scale versus how HTTP like Ajax requests scale. So, on the whole it’s not taking more bandwidth. On the whole, it’s probably taking less bandwidth. But it is in some respects a little bit more resource intensive on your server because you only have so many ports that you can stay persistently open.

So you scale WebSockets a little bit differently than you scale HTTP Ajax requests. But it is possible to scale them this company scaled it out to 60 million concurrent users it is possible to do. But it’s different than you do old school scaling. Alright, so WebSockets are really powerful and cool. The nice thing about this API that I’m going to show you a Socket.IO is that it provides a framework where if you’re working with no JS, if you’re working with JavaScript on the server, JavaScript on the client, the API is basically identical.

So you really don’t have to do very much mental context switching. You write the same kind of code, and it really works in this event mechanism which you’re going to see is true of almost all the web these days, we’re moving to this event mechanism. So, we listen for events by saying dot on like this reset player event from one of my games that I wrote. And then we send events back by saying dot emit. And listening and sending are synonymous between the browser and the client. I mean the browser and the server.

The server can listen for events and send events. The client can listen for events and send events. Okay? And the names that you use are just arbitrary string values. You pick whatever names you want. It’s up to you to decide what your event names are called and what your what your conventions are. You can name space your events or whatever. But it’s just sending events back and forth. And you can of course send data along like you see on line 66 or sending some game session ID along things like that. But you just listen for events and send events.

That’s all you need to do. Now there’s one additional set of functionalities that you do on the server that don’t make even don’t make any sense on the client. And that’s what we call broadcast. So this is what it looks like in the client. This was actually some client code if I’m correct, I’m not positive. I think that was some client code. But on the server you might be needing to do something where you have one message that you need to send out to like 100 connected players for instance.

And you could send it out 100 individual times because you’ve got a socket and you could do emit 100 times. But really the more performance thing to do is do a broadcast. Well a client doesn’t need to do a broadcast. So that part of the API just doesn’t even exist in the client. And it does exist on the server. So they’re not technically identical but the on and emit parts are exactly the same. So you don’t have to context switch in terms of your own. And when we get into the exercises later today right after lunch you’re going to get practice writing Socket.IO coding and you’ll see how easy it is.

You just write dot on and dot emit and it just magically sends these events back and forth.