I'd like to show you around the DDP server object itself. What we're looking at here is the live data server file in the DDP package, and you can see the server constructor function. This is actually going to be the constructor function used to create a new server object when we fire up our Meteor server. So the key thing to know here is that there's actually two servers running in Meteor.
There's an HTTP server, and that's responding to regular HTTP requests, like to load up our app, and then there's the DDP server, which gets created as well, and that's what responds to DDP requests. And so when we open up our persistent connection with the server, we're opening it up with the DDP server. And there's one DDP server that's created per Meteor application.
I've created a simple server side Meteor application up top, and I've put a debug line right here in a startup callback, so that we can pause in the debugger. I created one method and a published function, so that we can see what they look like in the server object. So let's start up the Meteor app, and again, to do that, we're going to pass along a node option to debug, and also to break on the first statement. And so I'll start up Meteor this way.
And then down in the bottom console we'll start up Node Inspector. Once we've done that, if I refresh the debugger on the right, it should drop us into the first line of the application. We can get rid of the console here. And I'll press Play to get us to our debug statement. What I want to show you is over in scope variables, if you expand the local scope variables, take a look at the server object.
Next, take a look at the published handlers. Similar to method handlers, this stores all of our published function handlers. So we have the one that we created here, called Welcome, but then there's one that Meteor creates called Auto Update Client Versions, which comes from one of the Meteor core packages.
The sessions property is responsible for storing all of our client connected sessions, and so for each connected client we'll have a session, and those will be stored and accessible by the server sessions property. The Universal Publish Handler stores an array of all of the published functions that should be automatically published. So when we have auto publish turned on, all of our publish functions will be pushed onto this Universal Publish Handlers array.
If we take a look at the prototype for the server object, we can take a look at some of the methods that we use all the time. For example, we have apply and call, so that we can call other server side methods. And then here's how we define methods on the server, and here's how we create publish functions. And then right here is a callback, or a function that we can use to register callbacks to run some code every time a client connects to the server.
One last thing I'd like to point out is the stream server property. This is actually the object responsible for handling socket connections with clients, and so if you look at the open sockets property of that, you'll see that we don't have any because there's no connected clients. But if we had some connected clients, you would see a socket opened for each client.
In summary, when we start up a Meteor application, we actually get two servers-- the first is an HTTP server that responds to HTTP requests, like to get the initial Meteor app, and the second server is the DDP server, which we spent this video looking at. There's only one DDP server per Meteor instance, and it's responsible for handling new DDP connections, keeping track of the sockets, and then providing us an API for registering Meteor methods and published functions.