Socket.io not serving its .js file with connect

[ntr-808]

Socket.io doesn't seem to be serving up its socket.io.js file with connect. I swapped connect out for express and everything worked fine.
See https://gist.github.com/1977521

[xcoderzach]

same issue here

[tj]

@Margh with 2.x or 1.x?

[xcoderzach]

2.x for me, it still works in 1.x

[tj]

probably just needs a few tweaks for 2.x in socket.io or browserify

[ntr-808]

same here, connect 2.x on its own doesn't work but express with connect 1.8.5 works

[snodgrass23]

so far, with what digging I've done, it looks like the server events for connection, request, etc aren't making it out through connect. This isn't allowing socket.io to catch and act on those.

[tj]

k with 2.0.3 try $ DEBUG=connect:dispatcher node app and curl the path, you should see something like:

  connect:dispatcher logger +0ms
  connect:dispatcher bodyParser +1ms
  connect:dispatcher cookieParser +0ms
  connect:dispatcher cookieSession +1ms
  connect:dispatcher post +0ms
  connect:dispatcher clear +0ms
  connect:dispatcher counter +0ms
GET / 200 3ms

[snodgrass23]

We've figured it out with our setup. Basically, express/connect now returns the server object that will have the events when calling listen on the app. So, we're then storing that as a property of the app and then sending that property to socket.io instead of the app itself, which is how we did it with the old version. This also requires us to not startup our socket code until after the listen method has been called so that the server object is available.

[hunterloftis]

Yep, basically:

// where this = express();
this.server = this.listen(this.config.port);
console.log('[ ' + this.constants.name + ' ] worker listening on port ' + this.config.port);
this.emit('listen', this.server);

The connection and request etc events fire on this.server (where with older versions of connect/express they would fire on this). Maybe something like this is already exposed that we're unaware of?

I like that in Connect 2 / Express 3 it's possible to create an app without starting an http.server - so maybe our solution (creating app.server and emitting an event) is the way to go.

[tj]

moving forward both express/connect "apps" are just callbacks, giving people flexibility to apply it to both HTTP[S] servers if necessary, app.listen() is a convenience method but the app is not a http.Server, so socket.io may have to adjust things a bit depending on the internals, im not sure exactly what the code is for hijacking the server to transfer the js. /cc @guille

[rauchg]

We override the request event listener of the http server. Since at some point you'll have to be using a HTTP/S server, things should continue to work fine

[hunterloftis]

Yeah things seem to work okay now that we've added our own record for the HTTP server and are passing that to socket.io instead.

@guille Going forward should we look at engine.io or websocket.io in place of socket.io? We already opt for ws in simple cases.

[rauchg]

@hunterloftis
You still need Socket.IO for reconnection, multiplexing, events. And also because despite browser support other things can get in the way of establishing a WS connection, as explained in the engine.io README.

[tj]

going to close now that I get what the problem is :D haha yeah for future reference if anyone comes to this issue, you need to wrap the connect/express app in a node http.Server. The app.listen() method is a convenience method for this and returns the server:

var io = require('socket.io');
var app = connect();
var server = app.listen(3000);
io.listen(server);

or the following is equivalent:

var io = require('socket.io');
var http = require('http');
var app = connect();
var server = http.createServer(app);
server.listen(3000);
io.listen(server);

[matthewmueller]

How would this work behind vhost? My engine.io server (ws.localhost) isn't actually calling app.listen(8080).