Transcript from the "Making a Socket Connection" Lesson
>> Kyle Simpson: Let's do some more Save As, moving on to Exercise 8, 8.server.js.
>> Kyle Simpson: And 8.html.
>> Kyle Simpson: Okay, in 8.html, I want you to take out that console.log statement, and I want you to do something different. What I want you to do is, var, or I'm sorry, I want you to do, io.connect.
>> Kyle Simpson: And here in the connect statement, you just need to do a /. And the return value from our connect statement, we're gonna call var socket = io.connect.
>> Kyle Simpson: By the way, this looks like a path, but we're not putting a path in here because it's not really a URL path.
[00:01:02] It's a name spacing thing path for socket name spacing, so we're just gonna use the slash namespace.
>> Kyle Simpson: Now, I want you to listen for the connected event.
>> Kyle Simpson: And console.log out that you've connected.
>> Kyle Simpson: Might be connection. Might have to test this and see. Sometimes I forget the server, the names that they make.
[00:01:36] All right, there's one last change that we wanna do here, which is that we need a handler for our incoming socket connections. So what we're gonna do is we're gonna say,
>> Kyle Simpson: io.on, this one I believe is connection, and we're gonna say handleIO. It doesn't matter what you call it, but I'm gonna call mine handleIO.
>> Kyle Simpson: Let's check against my solutions files to see if I'm getting off track here.
>> Kyle Simpson: Yep, it's called connection.
>> Kyle Simpson: Okay, so every time we get a new incoming websocket connection, it's gonna call this function in the exact same way that every time we got a new incoming HTTP, it called our other handler.
[00:02:37] This one is our handler for incoming socket connections. And in fact, will be passed in a socket object which represents our connection with some particular client. So if ten people connect to our website, this will get called ten times with ten different sockets, okay?
>> Speaker 2: Can you do the HTML?
>> Kyle Simpson: Yeah, just one sec. All right, now the last thing that we wanna do here is also listen for,
>> Kyle Simpson: The disconnect event,
>> Kyle Simpson: On the server side,
>> Kyle Simpson: And we'll say client disconnected.
>> Kyle Simpson: But here, we'll say client connected.
>> Kyle Simpson: So our handleIO is kind of our connection handler, that's when a connection is established.
[00:03:42] And then our disconnect is an event that's gonna fire whenever the client gets disconnected.
>> Kyle Simpson: On the client side, we have a connection. We can also listen for disconnection.
>> Kyle Simpson: All right, do you see what you needed to see there in the HTML?
>> Kyle Simpson: If I haven't gotten my event names mixed up, we should now be able to come back to our console, stop this 7.js, and start up 8.server.js,
>> Kyle Simpson: Oops.
>> Kyle Simpson: What did I do wrong?
>> Kyle Simpson: Saw a little thing that I didn't catch here. Okay, so, IO needs to be, rather than having those separated out, the better way to do this is to have it be the actual all-in-one line. Cuz IO needs to be the result of that listen call, rather than the result of the socket IO library.
[00:05:24] [COUGH] All right.
>> Speaker 3: Why is that? Can you repeat the last point?
>> Kyle Simpson: It's just a peculiarity of socket IO that their listen command returns back a different object than the actual socket IO module, so. We wanted our IO to point out the actual socket IO library, rather than the module itself.
>> Kyle Simpson: All right, now, we should be able to run node 8.server.js. And we come back here to our browser, and we change /7 to /8.
>> Kyle Simpson: Okay, I got client connected.
>> Kyle Simpson: And then if I were to go away for, oops, I forgot to change my HTML page to actually say 8, so that's gonna be awfully confusing, isn't it?
[00:06:24] Okay, but what if I refresh my page? We can see in my server logs that the client was disconnected and then it reconnected. So we know the server side of the events is working, but we don't see the server side of our client events working, so let me see, I think it might be.
>> Speaker 4: I got connect and disconnect for the.
>> Kyle Simpson: Are you saying that?
>> Speaker 4: Yeah.
>> Kyle Simpson: Okay, so the connected event fired. Now what happens if we were to kill the server?
>> Kyle Simpson: We should see the disconnected event fire in the client. Everybody see that? And this is socket IO trying to reconnect cuz reconnect is built in.
[00:07:20] Now [COUGH] it should be obvious to you that we're getting a whole bunch of really verbose logging that's going on, and that's pretty annoying. So let's turn off some of that logging cuz we don't need any of that kind of stuff going on in our server. And just as a shortcut, you can open up the solutions folder, open up 8.server.js, and it should have it down there at the bottom.
[00:07:43] Nope, it's not there. It's gonna be in 9, I think. It's kind of annoying how verbose it is by default. Let's see if it's in 9.
>> Speaker 5: [INAUDIBLE]
>> Kyle Simpson: What's that
>> Speaker 5: On line 60, in 9.server.
>> Kyle Simpson: Yep, I'm just gonna copy that whole thing over, this is just the way that socket IO configures itself.
[00:08:08] So we don't need all of this stuff, but it's not a bad idea to have these things in there, minifying the socket IO client, sending out etags, but the important one is this log level 1, reducing all that logging. So, if we save that and restart our server, now we'll notice that it's only gonna get messages that we are logging out, it's not gonna have all that extra verbosity to the socket IO logging.