My scenario is a web socket server on Winows Server that various HTML5/Java-Script-clients connect to to play card games. Thousands of small commands are sent back and forth every minute. Everything is absolutely reliable and stable on Windows-Clients and Android-Clients.
If it weren't for Apple and its IOS. Here's what happens on the iPad with IOS15:
For quite a while, sometimes 10 minutes, sometimes an hour, everything works as expected. Then suddenly the onmessage event doesn't fire anymore. However, the connection is still active and data can still be sent to the server. The only option then is to disconnect and reconnect.
It doesn't matter whether ws or wss.
It also doesn't matter whether the frames are sent as text frames or binary frames.
I tried killing and reinstalling the onmessage-Eventhandler, when the event stops firing. Also without success.
I also tried following the tip of setting the papameter NSURLSession to false in the safary settings. No success. Besides, it would also be difficult to recommend to customers.
The idea of ​​disconnecting and reconnecting in the event of an error is problematic because data has been lost and the game flow is no longer synchronous as a result.
Related
I'm writing an application that first tries to open a WebSocket connection (to make sure no others are open; address collision checking) before firing off a custom protocol that will launch a one-time WebSocket server with the address that the browser tells it. All communication is done over localhost and some arbitrary port number, say 3000. I'm not doing anything special, just attempting to open a WebSocket:
var socket = new WebSocket("ws://localhost:3000/MyApp/");
socket.onclose = function(e) { console.error(e); }
When testing in Chrome, the WebSocket will actually stay in the CONNECTING state for a little bit, which is ideal, since it gives us some time to actually launch the app through the custom protocol. But in Firefox, the WebSocket immediately closes with code 1006 and I can't figure out why.
I've tried changing the about:config network.websocket.timeout.open setting to be 1000 (from 20), but that doesn't help. I've also found this related post: Websockets - chrome and firefox differences?. That hasn't lead me to finding an answer, either.
What am I missing?
Update 11/16/21
I'm using the Dev Tools in Chrome and FF to check out the requests. The weird thing is that Chrome is actually sending a request header as you'd expect, but in FF, the request is completely empty (0 Bytes). Maybe this is a problem with FF not supporting debugging native WebSockets (no wrapper libraries in use)? Is there some FF setting that nixes the request? But even more confusing is that the browser would hit the close event without ever hitting the open event.
Update 11/17/21
I realize that maybe this has something to do with launching a Custom Protocol Handler? I noticed that it will wait a second to try and connect to a web server if no CPH is launched, but then when I do launch a CPH, that is when it immediately closes the WebSocket. The CPH is launched via a link targeting "_parent".
It looks like the custom protocol is causing FF to stop trying to connect early. I created an anchor element, <a>, in the JS code and called "click()" on it after constructing it. No matter what target I gave it (e.g. _self), it would cause the connection attempt to stop.
So long story short, initiating a link, whether it be a a.click, window.open, or location.replace, will cause Firefox to nix any currently polling WebSockets!
The workaround is to just use an iframe to launch the custom protocol.
I am developing an app that uses Server Sent Events (SSE - basically one-way websockets). If the user uses the site on their mobile chrome browser and then tabs out for about a minute, the SSE connection breaks. If the user then tabs back into the site, it doesn't refresh the page (this is good). But I still need to re-establish the SSE connection so that the server can resume sending messages to them without a refresh.
I'm trying to debug my implementation but having to do it on mobile is very tedious. I have to grab my phone, refresh the page, then tab out, wait 1 minute (so the connection can break), and then tab back in to determine if my code for re-establishing the connection worked properly.
I would much rather be able to debug this on desktop, but I haven't found a way. I have tried the following:
Tried 5 different Chrome extensions for sleeping a tab. Unfortunately, when you navigate back into the tab it just refreshes the page rather than resumes it.
Tried using USB Debugging, but the desktop keeps the tab open at all times even if you tab out on mobile, so the tab never sleeps.
Tried running debugger; in the Chrome Developer Tools console, but even if I let the Javascript sit with its execution frozen for 5+ minutes, it never breaks the SSE connection, so I can't test if reconnecting works.
Tried using an extension to kill the internet for Chrome, but miraculously, this still maintains the active websocket/SSE connections. Apparently Google engineers have deprioritized this effort?
Basically, I am looking to simulate the behavior that happens on mobile when you tab out of your web browser, wait a minute, and then tab back in (the Javascript execution is frozen, the SSE connection is broken after a minute or so, and then tabbing back in resumes Javascript and attempts to reconnect the SSE connection).
Is this possible?
I think that best change you have by emulating your android device. You can do so by installing android studio from https://developer.android.com/studio and then here you have all you need to start and manage your virtual android env https://developer.android.com/studio/run/managing-avds
This it the way I debug my whole mobile development
The most obvious solution to me would be to attach a listener that tracks the events related to tab activation and build some custom solution upon that.
Simply:
window.onfocus = () => {
// Restore SSE session
};
window.onblur = function () {
// Inactive
};
Just for info, SSE is a different protocol from websockets.
In case you are interested in using websockets implementation, I suggest the following library which works very well in my experience: https://www.npmjs.com/package/#stomp/stompjs
Stomp is an abstraction over the websocket protocol, but it also means you would need to implement this on the server side as well.
You can use the chrome://discards to freeze your tab.
You should close and restore the connection based on the Page LifeCycle events.
You Can Try to use pause execution
goto:
Chrome javascript console (Ctrl+Shift+J) > sources > pause script (press f8)
This simulates like a mobile tab switching so you can debug easily
I think this is the simple and easy solution. thanks
I have a react web app and a react-native mobile app. I want to add a "Slow Internet Connection Detected!" warning whenever the users network connection is slow.
Checking the speed at one instant is fine (By checking the time taken to complete a download of known size).
I want to detect the internet speed of the user at all times such that whenever the speed drops the warning comes on.
I am not able to find a way to do that. Please suggest a solution.
I've been creating a site that's meant to work on all browsers, and connects to a nodejs server through a proxy (meaning, the client connects to the server through a proxy) using websockets.
The site works fine on all browsers, but I've noticed some strange behavior on IE. The more the client browsed through the site, and as a result, opened more websockets, the slower the tab the client was browsing through became. Eventually, the tab would stop responding entirely and had to be shut down entirely because it'd stop responding.
I tried to whittle the problem down as much as I could, and eventually noticed that when your browser uses an explicit proxy, and has websockets, after a set amount of connections (around 25) the tab you're using will stop being able to connect to the server, and may stop working altogether. It's easy to reproduce this using the following steps:
Take the example page from here and create an html page
Download fiddler and use it as your proxy
Browse to the example page that you created and keep refreshing your tab. You should notice a slowness, until an eventual stop
It's worth noting that without a proxy, the tab will not end up dying like this.
Has anyone else encountered this issue? If so, is there any fix to this, aside from changing the architecture?
Thanks a lot
I'm using Express and Node.jx 0.6.7. Server is EC2 Small instance..
For some reason, Node.js is sometimes not receiving my ajax requests (sometimes). Firebug would say "pending..." and the spinning wheel would show.
It would take about 30 seconds before my node.js server actually gets the request. (When I hit it, I console.log, to check).
I've read information that a browser only allows 6 parallel connections. But, in my Firebug, I never have more than 3! In fact, I make sure everything loads, and all my ajax requests loads. After I see that everything has loaded, I "click" to call the AJAX...and it hangs. THis is the only spinning loading wheel. Everything else is loaded...so the simultaneous connections cannot be the problem, right?
The server returns responses very fast--the problem is that it's not receiving the response. Literally, the server does not get the request until like 30 seconds later.
This happens with static images just as well. (basically any request. It's really random)
I'm on Firefox 10 and Chrome (latest stable), and this happens. On Safari, it never happens. It's random and this problem happens in different spots.
Note: this does not happen in my EC2 Micro instance (only on my small instance). They are both the latest versions of Ubuntu.
Screenshot: http://i.imgur.com/X7801.png (as you can see, there is only 1 spinner. Everything else is returned. the Server is NOT under heavy load. it's idle. Yet, the server is not receiving the request)
Note: I am using AWS Load Balancer, but that's not the problem, because I turned that off and it's still happening.
Figured it out.
Cloudflare! I disabled the security crap.