WebSockets over a 3G connection

Question

I've been playing with Socket.io, node.js and WebSockets, all of which I can get working fine over a wifi connection.

However, when I test out a WebSocket-enabled app over a 3G connection (on my iPhone, for example) then it seems like falling back to long polling is the only workable solution.

With Socket.io the connection fails with "WebSocket connection invalid or Origin not verified" before falling back to long polling.

I don't know if WebSockets are meant to work over 3G - has anyone had success getting them to work like that? I've tried a number of different methods and the all seem to fail, which makes me think that I'm attempting the impossible.

Speakeasy

Does Socket.IO work on your iPhone over wifi? I.e. can you eliminate the iPhone/iOS as part of the problem? – Speedway

Yes, good point. Socket.io over wifi on the iPhone works fine, so it's the 3G side of things which is the problem. – Speakeasy

I'm having this problem only on iPhone 6 with 3G. Not Socket.io related, using Tornado and Nginx. Also on non-SSL connection on port 80. – Gat

Answer 1

Some mobile phone operators are notoriously known for setting up utterly broken transparent proxies that you're forced to pass through. This is a real annoyance that the WebSocket working group has had to deal with since the very beginning. The protocol is designed to ensure that it will fail very quickly in presence of such products so that your application can immediately fall back to other methods. If you find that it takes a long time to detect the anomaly and fall back, please report it to the hybi working group at the IETF so that the issue can be diagnosed and addressed.

In parallel, you can contact your mobile phone operator and ask them how you can access the net without passing through their broken transparent proxies or at least to know when they expect to get their broken proxies fixed to support HTTP according to specifications. Some of them might offer you multiple access options.

Digestif

Yes, this seems to be the problem. I have no problem with the speed of WebSockets failing, so that part of the problem is working fine. It's just frustrating not being able to use them over 3G. Thank you for explaining the situation. – Speakeasy

Same problem in the UK. Websockets fails to work on O2 and Orange. – Machiavellian

I'm on o2 in the UK, when I visit this site <websocketstest.com > on WiFi all services work, on 3G only port 443 (SSL) works. So it might be worth getting a certificate and using wss:// instead. – Garver

+1s all round. Great test site that one. I have just switched to port 443 and using wss on Android and all seems to be working now (port 80 would fail with a 503 when using with Pusher) – Hexateuch

Also Softbank in Japan blocks ws but not wss – Lita

@Garver I'm on O2 with an Android Chrome and, today, all tests are green, for all ports in the websocketstest.com – Hendon

Answer 2

As Willy Tarreau says, it's broken transparent proxies used by the mobile operators. I'm sure it's not exclusive to them either (corporate company firewalls for example). You can get around this by using a different port number (on the mobile operators at least). Something other than port 80. Using SSL might also work, but I have not tried it yet.

Then you will run into problems with folk behind firewalls blocking everything outside ports 80 & 443.

Write your websockets app to flip between port 80, and some other port on each connection attempt, and have your host listen on those two ports. Then you have a good chance of connecting to the server. Use iptables port REDIRECT if your using linux to listen to two ports simultaneously.

Machiavellian

Hi FlappySocks. That sounds like a great solution. Have you implemented it on any networks and confirmed that it works? I've tried port 81 on O2 UK but websocket connections still fail. Plus one and lots of kudos to you if this does work! – Uranography

Works fine on Orange using port 1442. There are also sim providers such as stream-communications.com and aaisp.net that offer APN proxys that work properly. But you shouldn't need this. I hope to support 443 SSL soon. – Machiavellian

Sadly it looks like even port 1442 doesn't work on O2. Still it's nice to know that I have the option of going to Orange. – Uranography

Answer 3

You can use Server-Sent Events protocol instead of WebSockets.

SSE is a simpler, HTTP-compatible and can go through proxies.

Tittivate

I am using SSE but having issues trying to access my endpoint over 3G mobile network. The same works fine over regular broadband. One observation I had though - I have 2 endpoints, one with https (ssl) works fine over my mobile network but the one with http (without ssl) does not work on my mobile network. Any ideas? – Beatnik

@ArpitAgrawal Do pending messages arrive when the connection is closed prematurely? It helps in case the connection is forced through proxies that try to buffer the whole response before sending anything forward. – Tittivate

I am not sure what do you mean by "Pending Messages when connection is closed prematurely"? Since it is SSE, isn't the connection always open? I have setup a question here: #30338866 with an example to my endpoint. Please help.. Thanks.. – Beatnik

Answer 4

Had these same errors with a bad web socket connection over certain mobile networks. Solved them by;

1. Moving ports: Moving over server and client for websocket over to the SSL port (port 443)

2. Ping keep-alive: Sending periodic "ping" messages from client to server every X seconds, and waiting for a "pong" to return from server. If server doesn't give "pong" back within Y seconds, restart the connection on client.

Implementing (1) will get you most of the way there.

Wrap