Problems with Non-Standard Ports

@jzimmerlin:

Have you found that any ISPs/mobile carriers block requests from their customers when they use a non-standard port?

Many companies block outgoing ports other than 80 and 443. So for example, I cannot hit http://[any domain]:8080 from the office at my day job.

James

You could Apache's ProxyPass and ProxyPassReverse combination to direct traffic to your port 8080 server. Or are you saying you're doing that and running into issues?

@jebblue:

You could Apache's ProxyPass and ProxyPassReverse combination to direct traffic to your port 8080 server. Or are you saying you're doing that and running into issues?

No, the Apache server and the Node.js/Socket.IO server are completely separate. I'm not proxying or anything like that.

@zunzun:

Many companies block outgoing ports other than 80 and 443. So for example, I cannot hit http://[any domain]:8080 from the office at my day job.

If that were the case, what would my options be? I suppose I could get another Linode to host the Node.js/Socket.IO server on, on port 80. Alternatively, would it be possible to get a second IP and host the Node.js/Socket.IO server on that IP on port 80? Any other solutions I haven't thought of?

Thanks for all of your help!

@jzimmerlin:

If that were the case, what would my options be? I suppose I could get another Linode to host the Node.js/Socket.IO server on, on port 80. Alternatively, would it be possible to get a second IP and host the Node.js/Socket.IO server on that IP on port 80? Any other solutions I haven't thought of?
Or just differentiate the different services based on hostname or URL. Whatever one then listens on port 80 (say Apache) proxies URLs for the other internally.

If the Apache overhead is too much for proxying, something like nginx (which could front both Apache and Node.js servers) could be placed in front of both.

(Oh, this assumes your Node.js app is still using HTTP for communication - if it's raw traffic, you'd have to invert things so it was probably the main app listening on port 80 and only if it detected HTTP would it proxy over to Apache. Proxying in this case could be done at a raw stream level, as pure socket forwarding. You'll only be stuck if there's no way to distinguish HTTP from the raw protocol.)

– David

@db3l:

@jzimmerlin:

If that were the case, what would my options be? I suppose I could get another Linode to host the Node.js/Socket.IO server on, on port 80. Alternatively, would it be possible to get a second IP and host the Node.js/Socket.IO server on that IP on port 80? Any other solutions I haven't thought of?
Or just differentiate the different services based on hostname or URL. Whatever one then listens on port 80 (say Apache) proxies URLs for the other internally.

If the Apache overhead is too much for proxying, something like nginx (which could front both Apache and Node.js servers) could be placed in front of both.

(Oh, this assumes your Node.js app is still using HTTP for communication - if it's raw traffic, you'd have to invert things so it was probably the main app listening on port 80 and only if it detected HTTP would it proxy over to Apache. Proxying in this case could be done at a raw stream level, as pure socket forwarding. You'll only be stuck if there's no way to distinguish HTTP from the raw protocol.)

– David

I'll mess around with that. Thanks!

@jzimmerlin:

Alternatively, would it be possible to get a second IP and host the Node.js/Socket.IO server on that IP on port 80?

If you're using IPv6, you have a large number of IP addresses available. Not the case with IPv4 any more, alas. (And IPv6 support is probably spottier than non-standard port support.)

It's worth noting that while nginx rocks, it does not support HTTP/1.1 to backend proxied servers. This would make WebSockets not possible, and thus eliminate one of the best features of socket.io. I would recommend using Apache in this case, because it fully supports HTTP/1.1 to both the client and to backend proxied servers (like your socket.io process)