This course has been updated! We now recommend you take the Complete Intro to Real-Time course.
Transcript from the "Web Sockets" Lesson
[00:00:04]
>> Kyle: Next we can talk about WebSockets, this will be our last thing that we talk about with 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.
[00:00:19] I initially had envisioned that someday I would write a WebSocket client facade. A facade that wraps around the client API for WebSocket, cuz there is a client API, it's capital W capital S WebSockets and it's built in the browser. So if there's a native API for it, we should have a facade, that was my initial goal.
[00:00:39] But I got to realizing that almost everybody, I don't think I've ever met somebody that actually does WebSockets directly against the API. And 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.
[00:00:57] And the server side's a lot harder. And so we use frameworks like socket.io or push 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.
[00:01:14] So I'm actually going to show you socket.io. Now that's just because I'm most familiar with it and I'm not at all saying it's the best it's 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.
[00:01:27] So that's what 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.
[00:01:45] 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, responding and all of that transfer of data. And plus all of the overhead because each of the HTTP packets have 1200 or more bytes for every single request that's getting sent across and things like that.
[00:02:07] So these sorts of requests are not terribly efficient. They work when we just 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.
[00:02:30] Real time gaming for instance, if you're playing a first person shooter game you're expecting. In terms of your ping time and your latency, you're expecting like 30 to 40 milliseconds at the longest or you're just going to lose because everybody else on the screen is updating faster than yours.
[00:02:46] 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 a sort of a general broad brush thing on the global scale, as an average.
[00:03:06] And ajax request probably averages anywhere from 500 to 800 milliseconds total round trip. From the time you make the request, the time you get a response back 500, 800 milliseconds is just a general average. When we start talking about WebSockets, it's a different technology entirely. Well not entirely but when it makes the initial HTTP requests there's an initial round trip, so we have that initial latency.
[00:03:29] But then we keep the socket open, it's a persistent socket, so we keep the WebSocket 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 WebSocket header has 8 bytes.
[00:03:55] That's drastically smaller so we're sending a lot less information. We have persistent socket so we're not paying 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 WebSocket connection on average you're gonna get anywhere from 50 to 100 milliseconds latency in terms of your round trip times and in communication.
[00:04:15] So we drastically reduced from 500, 900 milliseconds, that huge range all the way down to a 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 round trip time might be too slow for the most high performance of games.
[00:04:36] Not all games are too slow for that. So I worked at a gaming company a couple years back, I won't name them but they're big gaming company you probably know about them. And we built an online game that was a bingo game. And bingo, it's a real live thing, I'm playing against other people.
[00:04:55] But the difference between 100 milliseconds and 90 milliseconds isn't usually going to determine different winners. There's a possibility of that, but for the most part that gameplay could tolerate WebSockets and so we built the game off a WebSocket. Certainly it would not have tolerated ajax. If we had 60 million people playing based upon ajax technology, not only would that have killed our servers but also everybody would have been going too slow.
[00:05:20] If they were having to wait a whole second or more to hear back responses on the bingo calls or whatever. So WebSocket 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.
[00:05:35] That phrase real time is kind of a misnomer because I took computer science, I don't know if 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.
[00:05:55] He had actually spent time writing true real time software for things like controlling a nuclear reactor, where the response time had to be submillisecond, 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.
[00:06:16] [LAUGH] All right, you're going 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.
[00:06:30] So full page requests back in the HTTP 1.0 days could take anywhere from 2 to 20 or 30 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.
[00:06:49] And now WebSockets have gotten us down to that around 100 milliseconds or somewhere below 100 milliseconds. So it's opened up a whole new world of things that we can do. And WebSockets are really powerful. Where we're headed is by the end of today is we're going to talk about that next leap in terms of technology and whatever when we talk about peer to peer technology.
[00:07:07] And where that's gonna get us terms of [INAUDIBLE].
>> Speaker 2: I have a question. Does it take more bandwidth for WebSocket because-
>> Kyle: 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 request scale.
[00:07:29] 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.
[00:07:47] 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. All right, so WebSockets are really powerful and cool. The nice thing about this API that I'm a show you in socket.io, is that it provides a framework where if you're working with node.JS, if you're working with JavaScript on the server JavaScript in the client, the API is basically identical.
[00:08:14] So you really don't have to do very much mental context switching at all, you write the same kind of code. And it really works in this event mechanism which you're gonna see is true of almost all the web these days, we're moving to this event mechanism. So we listen for events by saying .on, like this reset player event from one of my games that I wrote.
[00:08:33] And then we send events back by saying .emits 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.
[00:08:55] You pick whatever names you want, it's up to you to decide what your names are called. And 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.
[00:09:11] We're sending some game session id along and 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.
[00:09:28] Okay, 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 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.
[00:09:47] And you could send it out 100 individual times because you've got a socket you could do emit 100 times. But really the more performant thing to do is do a broadcast. Okay, 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.
[00:10:04] So they're not technically identical but the on and emit parts are exactly the same. So you don't have the context switch in terms of. And when we get into the exercises later today right after lunch when we, you're gonna get practice writing socket.io coding, you'll see how easy it is.
[00:10:20] You just write .on and .emit and it just magically sends these events back and forth.