0.7 doesn't work on Dotcloud, but 0.6.18 does.

[Qard]

I'm not sure what changed to cause this issue, but Socket.IO 0.7 isn't working on Dotcloud. They don't support WebSockets yet, so I've been using the XHR-Polling transport, but even that fails on 0.7--in fact; ALL transports fail on 0.7. The initial XHR request to acquire the session ID works fine, but once it starts trying to poll with it the requests just hang.

It works fine on localhost, so I asked Dotcloud support about it and they are pointing the finger back at Socket.IO so I'm not sure what to do about that. Any ideas?

[Charuru]

Does anyone know what's going on?

[Pita]

Are you using a reverse proxy in front of it? It didn't work for me too with a reverse proxy in front of it, the old socket.io doesn't have a problem with that

[Qard]

Yes, it's behind nginx.

[Pita]

I tried it with nginx and lighttpd, both didn't work for me. Both work fine with the old version. This is at the moment the reason for me not using the new version. I will do some resarch the next days about it and post them here

[Qard]

Same here. I'd love to use the new features in 0.7, but I can't. :(

I built my own hacky custom events code to use for now;

// Client
socket.msg = function(type){
  socket.send(JSON.stringify({
    type: type
    , args: Array.prototype.slice.call(arguments, 1)
  }));
};
socket.on('message', function(msg){ 
  msg = JSON.parse(msg); 
  socket.emit(msg.type, msg.args); 
  socket.emit('*', msg.args); 
});
socket.on('echo', function(msg){
  console.log(msg);
});
socket.msg('echo', 'echo this.');

// Server
client.msg = function(type) {
  client.send(JSON.stringify({
    type: type
    , args: Array.prototype.slice.call(arguments, 1)
  }));
};
client.on('message', function(msg) {
  msg = JSON.parse(msg);
  msg.args.unshift(msg.type);
  client.emit.apply(client, msg.args);
});
client.on('echo', function() {
  var args = Array.prototype.slice.call(arguments);
  args.unshift('echo');
  client.msg.apply(client, args);
});

[jozefdransfield]

I am seeing a simular issue, but even with 0.6.8 the initial message is sent but subsequent messages just hang in the browser, until i get the disconnect event on the server side.

[Charuru]

just in case, you should be using 0.6.18 rather than 0.6.8... I learned that the hard way.

[jozefdransfield]

Yes sorry i meant 0.6.18

[Pita]

I found out that this problem is solved in the latest socket.io version. This version is so far not avaiable via npm

[Qard]

Nice! I hope it's published to npm soon. :)

[3rd-Eden]

I'm closing this based on @Pita's input, if this issue persists after the next release feel free to re-open or to create a new issue.

[mawkor2]

Just tried this on dotcloud using 0.7.7, still does not work.
I never had these problems on duostack.

[mawkor2]

Error in chrome is
Error during WebSocket handshake: 'Connection' header value is not 'Upgrade'

[mawkor2]

Sorry, I think dotcloud might have a different WebSocket implementation... this might not be fixable(if they need to backcompat support some other spec).

[Qard]

Dotcloud doesn't have any websocket support. It should work with xhr-polling, but hasn't so far in 0.7. I've yet to test 0.7.7 though.

[mawkor2]

Ah, my mistake, I thought I was using websockets on an older project on duostack, maybe not...

[Qard]

Duostack had experimental support for websockets, Dotcloud has no support for websockets.

[mawkor2]

Both websocket fallback requests are failing (Chrome 13, Firefox 6) -
http://9aef7181.dotcloud.com/socket.io/1/xhr-polling/21022852571958964169?t1310501523879
http://9aef7181.dotcloud.com/socket.io/1/jsonp-polling/21022852571958964169/?t=1310501533880&i=0

[michaelcurtis]

This is still an issue for me with 0.7.7. All transports are failing on dotcloud. I have a repro case running on dotcloud right now. Has anyone determined if it will be fixed in the next release?

[3rd-Eden]

Have you reported the issue at dotcloud?

[michaelcurtis]

I decided to come here first because 0.6.17 works properly with dotcloud, just not the 0.7.x versions. Sounds like Qard also already spoke with dotcloud support.

[Qard]

Yes, I spoke to the guys at Dotcloud before the supposed fix that didn't actually fix anything. They directed me here suggesting that the changes introduced in 0.7 somehow conflicted with nginx, and that the Socket.IO devs would have a better idea what could be the issue.

[jpetazzo]

DotCloud support here — we would be happy to help to find a fix!

Node.js apps running on DotCloud have (at least) one layer of nginx in front of them. It's very probably the root cause of the problem, since that's the only extra layer, compared to a "raw" Node.js app.

If you have suggestions of specific nginx settings which might affect Socket.IO behavior, we can setup testing proxies quite easily to validate that.

Off-Topic: regarding real WebSockets support, that's totally on our roadmap. We just need to find a stable proxy able to handle WebSockets and thousands of vhosts :-)

[Pita]

I descriped the problem with nginx and other reverse proxies here: #406
For nginx, the best fix is to just set proxy_buffering off. But this creates problems with IE cause many connections keeps open. And there is another bug in combination with nginx -> #401

[Qard]

@jpetazzo Have you tried HAProxy, or are you tied to nginx? If so, nginx_tcp_proxy_module might work. https://github.com/yaoweibin/nginx_tcp_proxy_module

[jpetazzo]

Thanks, very insightful. Well, we could easily have a 2nd set of gateways with "proxy_buffering off" for people willing to use recent versions of Socket.IO.

One (probably dumb) question, though: why did it work with 0.6, and not with 0.7?

[Pita]

cause 0.6 works with connection:closed, 0.7 with connection:keep-alive. But reverse proxies only talk to the backend with connection:closed, but socket.io ignores that and keeps the connection open. That makes the reverse proxy think that the answer isn't complete and it doesn't flush the buffer

[Pita]

proxy_buffering off is a ugly work around, not a solution

[jpetazzo]

@Qard We need something able to support thousands of vhosts (and even millions in a not-so-distant future). I did not inspect HAProxy's code, but I don't think it really supports vhosts, other than by settings ACLs on a "Host" header; and I assumed that it would lead to linear vhost lookup cost (which would be prohibitive with large number of vhosts). HAProxy is still awesome for load-balancing, but unless I'm wrong, it would be a bad pick for our use-case. Also, nginx_tcp_proxy_module is just a poor man's HAProxy — it doesn't even support vhosts, unfortunately. But we're not tied to nginx (we're actively investigating zedshaw's mongrel2, for instance).

@Pita got it, thanks for the explanation!

[gaara87]

I'm feeling good that i found this discussion and the fact that its an ongoing issue. I'm having the same issues with hosting it on dotcloud. 0.7 seems to be acting up for the same reasons. though i'm guessing a 502 error is because the same reason, i am really hoping it gets fixed really soon.

[Qard]

We are onto 0.8.4 now and it still doesn't work. :(

[audreyt]

Yeah, same here re 0.8.4 not working by default with DotCloud.

Here's a working workaround (due to sugyan++): https://github.com/audreyt/ethercalc/blob/master/dotcloud.coffee#L17

[ashtuchkin]

The same workaround described in blog:
http://stephenbelanger.com/2011/09/21/how-to-make-socket-io-work-behind-nginx-mostly/

[jpetazzo]

dotCloud now has beta websockets support, so this hack should no longer be necessary. Just point your custom domain to ws.dotcloud.com instead of gateway.dotcloud.com and you will be using a websockets-aware load balancer instead of the default one running Nginx.

Although Socket.IO supports lots of different transports, most of them are quite broken when used in real-life scenarios (for instance, the long polling transports handle volatile sends in a very naive way, discarding all but the first packet of data sent in a single round). Therefore, it's really better to upgrade to websockets — unless you want to do long polling for another reason, in which case it's best to be aware of those Socket.IO issues.

Updated: use ws.dotcloud.com instead of experimental-gateway-1.dotcloud.com.

[audreyt]

Confirmed the CNAME experimental-gateway-1.dotcloud.com now works correctly with Socket.IO 0.8.7.

http://www.ethercalc.org/ is now running behind the new websockets-aware load balancer (which one, I wonder? :-)), and websocket connections seems to work just fine with FF8/Chrome16.

[jpetazzo]

We are currently using 3 different websockets-aware load balancers. Which one were you thinking about? :-)

[audreyt]

All three? :-) Anyway it's just my curiosity at this point; this ticket can safely be closed imvho.

[randallb]

FYI- Dotcloud seems to have killed ws.dotcloud.com (sez @jpetazzo ) so now we're back to workarounds.

[jpetazzo]

ws.dotcloud.com will soon point again to a valid websockets gateway (our "new new" websockets gateway).

[jpetazzo]

(Soon as in "in a few hours, just let DNS do its thing")

[ghost]

Hi, should the "new new" ws.dotcloud.com be up and running yet? I'm trying to work out if I'm doing something wrong. I have pointed a subdomain to ws.dotcloud.com as CNAME and I can't seem to get a websocket connection working yet, I'm having to fall back to XHR-Polling, and it's not ideal. :)

Thanks!

[ghost]

.. just to add, I've checked the response, and I'm getting "frontend not found" for everything :(

[randallb]

Hit support up. They fixed my frontend not found bug pretty quickly.

[ghost]

Thanks, I'll give them a shout :)

[jpetazzo]

@classic44021: found your request on support; will followup through our ticketing system. Thanks!

[ghost]

@jpetazzo Thanks! I think that ticket got closed, but I've posted here too: http://answers.dotcloud.com/question/487/how-to-setup-websockets-with-socketio-via

[rase-]

Still having issues with the latest release, @Qard?