New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Socket.io not serving its .js file with connect #500

Closed
margh opened this Issue Mar 5, 2012 · 15 comments

Comments

Projects
None yet
7 participants
@margh

margh commented Mar 5, 2012

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

This comment has been minimized.

Show comment
Hide comment
@xcoderzach

xcoderzach Mar 5, 2012

same issue here

xcoderzach commented Mar 5, 2012

same issue here

@tj

This comment has been minimized.

Show comment
Hide comment
@tj

tj Mar 5, 2012

Member

@margh with 2.x or 1.x?

Member

tj commented Mar 5, 2012

@margh with 2.x or 1.x?

@xcoderzach

This comment has been minimized.

Show comment
Hide comment
@xcoderzach

xcoderzach Mar 5, 2012

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

xcoderzach commented Mar 5, 2012

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

@tj

This comment has been minimized.

Show comment
Hide comment
@tj

tj Mar 5, 2012

Member

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

Member

tj commented Mar 5, 2012

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

@margh

This comment has been minimized.

Show comment
Hide comment
@margh

margh Mar 6, 2012

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

margh commented Mar 6, 2012

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

@snodgrass23

This comment has been minimized.

Show comment
Hide comment
@snodgrass23

snodgrass23 Mar 21, 2012

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.

snodgrass23 commented Mar 21, 2012

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

This comment has been minimized.

Show comment
Hide comment
@tj

tj Mar 21, 2012

Member

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
Member

tj commented Mar 21, 2012

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

This comment has been minimized.

Show comment
Hide comment
@snodgrass23

snodgrass23 Mar 21, 2012

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.

snodgrass23 commented Mar 21, 2012

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

This comment has been minimized.

Show comment
Hide comment
@hunterloftis

hunterloftis Mar 21, 2012

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.

hunterloftis commented Mar 21, 2012

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

This comment has been minimized.

Show comment
Hide comment
@tj

tj Mar 21, 2012

Member

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

Member

tj commented Mar 21, 2012

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

This comment has been minimized.

Show comment
Hide comment
@rauchg

rauchg Mar 21, 2012

Contributor

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

Contributor

rauchg commented Mar 21, 2012

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

This comment has been minimized.

Show comment
Hide comment
@hunterloftis

hunterloftis Mar 21, 2012

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.

hunterloftis commented Mar 21, 2012

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

This comment has been minimized.

Show comment
Hide comment
@rauchg

rauchg Mar 21, 2012

Contributor

@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.

Contributor

rauchg commented Mar 21, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@tj

tj Mar 21, 2012

Member

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);
Member

tj commented Mar 21, 2012

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

This comment has been minimized.

Show comment
Hide comment
@matthewmueller

matthewmueller Aug 2, 2012

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

matthewmueller commented Aug 2, 2012

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment