Ben, > I have now applied those changes you outlined above (I had before but the > way I did it, by leaving the old code there and commenting it didn't seem to > work from what you're saying) I've now applied the changes exactly as > outlined and rebuilt the server, is there anything else that I need to do as > now the entire server isn't responding at all even though the line 980 is > exactly as you mentioned in the socket.io.js file. I did notice that > permutation 4 of the compilation threw an exception.
What was the exception? (It might help if we knew) I tried cherry-picking the 2 changes onto the current trunk, and it compiled without issue. (And ran correctly without issue). > It would be nice to be able to have a polling solution available as it seems > to be the only solution for getting through the ISA proxies, even if it was > only as a fallback solution when websockets fail. The method of forcing socket.io (as I am trying to get your server to use) is a bit of a nasty hack as you can see. Unfortunately, the way the code is setup ATM doesn't allow a better way of doing this. At best, it would be possible to export a new configuration variable, (forceNoWebsockets perhaps?), write it to the page, and then patch the used version of socket.io to understand the variable, such that if set it forces the only transport to be XHR-Polling via Socket.IO. But this also feels like a bit of a hack. Letting WIAB perform actual detection of this situation doesn't seem to be possible. Ali PS. @Wave: I referred to the wrong commit for the 'hacked' socket.io binary. It should have been: 8626aa5d0b10eb8627ae1a38ff3c944390c73b22