{"id":1918,"date":"2017-05-11T01:21:06","date_gmt":"2017-05-11T01:21:06","guid":{"rendered":"http:\/\/www.jaaronanderson.com\/blog\/?p=1918"},"modified":"2017-05-11T15:47:34","modified_gmt":"2017-05-11T15:47:34","slug":"html5-node-rtc","status":"publish","type":"post","link":"http:\/\/www.jaaronanderson.com\/blog\/html5-node-rtc\/","title":{"rendered":"HTML5 Node & RTC"},"content":{"rendered":"

Local Storage API & Session Tab-based storage : persistent storage in a user’s browser not cookies old school- where cookies made full trips w\/ every request .<\/span><\/p>\n

Canvas API<\/p>\n

HTML facade<\/p>\n

NPM<\/p>\n

 <\/p>\n

getUserMedia … webcam , mic , screencapture\u00a0 user data streams…<\/p>\n

 <\/p>\n

 <\/p>\n

\n
\n
\n
\n
\n

ref.Kyle Simpson<\/span><\/p>\n

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

You just write dot on and dot emit<\/span> and it just magically sends these events back and forth.<\/span><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Local Storage API & Session Tab-based storage : persistent storage in a user’s browser not cookies old school- where cookies made full trips w\/ every request . Canvas API HTML facade NPM   getUserMedia … webcam , mic , screencapture\u00a0 user data streams…     ref.Kyle Simpson WebSockets, this will be the last thing that […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1918","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"http:\/\/www.jaaronanderson.com\/blog\/wp-json\/wp\/v2\/posts\/1918","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.jaaronanderson.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.jaaronanderson.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.jaaronanderson.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.jaaronanderson.com\/blog\/wp-json\/wp\/v2\/comments?post=1918"}],"version-history":[{"count":6,"href":"http:\/\/www.jaaronanderson.com\/blog\/wp-json\/wp\/v2\/posts\/1918\/revisions"}],"predecessor-version":[{"id":1924,"href":"http:\/\/www.jaaronanderson.com\/blog\/wp-json\/wp\/v2\/posts\/1918\/revisions\/1924"}],"wp:attachment":[{"href":"http:\/\/www.jaaronanderson.com\/blog\/wp-json\/wp\/v2\/media?parent=1918"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.jaaronanderson.com\/blog\/wp-json\/wp\/v2\/categories?post=1918"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.jaaronanderson.com\/blog\/wp-json\/wp\/v2\/tags?post=1918"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}