Our mobile app communicates with our Meteor server in two ways:
- A native C# WebSockets library, and
- The regular Meteor frontend running in a web view
I tested this setup under weak network conditions (EDGE) and found out that
- the native code still connects to the server without any issues, however
- the embedded web frontend fails to establish a websocket connection
The reason for this is that SocksJS reports
WebSocket is closed before the connection is established
every two 2 seconds or so.
This timeout is way to low for unstable, bad mobile networks. I am wondering why it is has been set that low. More important: How can I change it so SockJS won’t kill the socket after such a short time?
Update: This even appears using a 3G connection setup. Not as often, but still.
3 Likes
Shameless bump. This is really serious in our use-case, as it prevents us to establish a stable connection to the server over slow connections on Android. iOS works fine, interestingly.
Hi @waldgeist I believe you are not using Galaxy, right?
On Galaxy we control and customize this timeout in our custom Proxy layer written in Go. But we use a low timeout for WebSockets like 5 seconds and we don’t have problems with this. If you are using a custom set up of Ngix or something else you could try to increase there because it could be a server timeout.
But maybe in your case it’s a client timeout?
Did you confirm that sockjs is used in your case and not a standard WebSocket? meteor/browser.js at f82685d0c8c1d3b0bbb02b4e826222e123ffd506 · meteor/meteor · GitHub
The onclose event is being fired? If so you could reconnect there. If we don’t provide good hooks for this you could add a new one 
We can merge additions like this very quick.
Is this happening on every connection from old devices?
Hi @filipenevola, thanks for your response!
Yes, we’re not on Galaxy, we’re hosting our servers on AWS, using mup. I don’t think the problem is really on server-side, though, since the problem does seem to mainly appear on Android, iOS works fine. Also, the native WebSockets I use in C# in parallel (on Android) are not affected either. It’s just the Meteor web client on Android (running in a web-view) that shows this.
I think it is WebSockets, because the error reports that a “WebSocket connection” could not be established. I just mentioned Sockjs, because the error is actually thrown by that library (as I can see in the path).
I’m not sure if the onclose event is being fired, will try. But I don’t think this will solve the problem, because Meteor actually tries to reconnect automatically. These errors show up every 1 or 2 seconds. The problem seems to be that within this short time-frame, the server doesn’t respond (or the client doesn’t get a response).
It’s happening on all Android devices, also pretty recent ones (like the Samsung Galaxy 10 5G), once I throttle the speed to 3G or lower. I am using the Network Link Conditioner of my iPhone to simulate this, since users have reported frequent connection losses “in the field”. That’s how I became aware of this and started to analyze further.
Hi @waldgeist my suspicious about a server side problem is that I’ve ran many apps in Brazil (not the best network out there and also a lot of cheap Android phones) and I never had this issue but I was always using Galaxy.
Some apps that I’ve developed were target for low income population so it would definitely affect them, I would guess.
I was also studying this code better (with SockJS in the client) and it seems SockJS is being forced as you can read in this PR Statically import SockJS in both modern and legacy bundles. by benjamn · Pull Request #9985 · meteor/meteor · GitHub
Maybe you could try to remove this import and see if the standard implementation of WebSocket would present the same problem. I’m assuming you can reproduce it easily.
Let me know your findings.
Hi @filipenevola Thanks for the additional insights. Strange thing here is: Only the Android webview is affected, not the Android native C# WebSockets nor iOS.
You mean by forking this package or hard-resetting it to version 0.2.1?
Yes, my idea was by cloning the package into your local repository to test with standard WebSocket so you could check if the problem is really in the client (sockjs) or not.
Hi @filipenevola, another update on this: Today, I ran into the very same problem on my dev machine (macOS + Chrome) connecting to the dev server on localhost. The reason was that I worked in a pretty hot room, so my MacBook clocked down to 0.8Ghz. This made things so slow that even Chrome ran into this timeout. So it’s definitely not caused by the server setup.