Make app resilient to connection type changes?

[alepodj]

Describe the problem
Is there a way to make an app resilient to connection type changes? By that i mean if an app is open and the user is on WIFI and they change their connection type to WIRED(Ethernet) or even establish a VPN which creates a new virtual network adapter, the app then crashes, tried setting a callback function, but cant think of anything to do there since the app is already gone at that point.

Desktop (please complete the following information):

• OS: Windows 10 1809
• Browser: Chrome/Brave 79.x.x.x

[samuelhwilliams]

Hi @alepodj - thanks for reporting this issue. I think it's definitely something that we should address. I'll have a look at it.

[alepodj]

Thanks for taking a look @samuelhwilliams I experienced it the most while on WIFI and then establishing a VPN session and the other way around. I have to do more testing for the WIFI to WIRED and vice versa cases. Let me know if u need any other details. Cheers

[samuelhwilliams]

Hi @alepodj. I think the prospective change here may also help you: https://github.com/samuelhwilliams/Eel/pull/353. Although addressing connection resilience isn't the main goal, it does add code to the Eel JS side that will get it to try to reconnect to the Python server when the websocket is closed.

There's currently still a hard-coded 1 second shutdown on the Python side if no websocket is connected. This may be too short - so it would be useful if you could test it and see if we need to either make that shutdown timer configurable or longer by default.

You can test it, if you like, with pip install https://github.com/samuelhwilliams/Eel/archive/eel-development-reloader.zip

[alepodj]

Hello @samuelhwilliams this is excellent. So far all my tests have passed. Apps stays running on the following cases:

• No VPN to a VPN Session Established
• VPN Session Established to No VPN
• WiFi to Completely Offline
• Completely Offline to WiFi

I played with the shutdown timer backwards from 10 seconds to the default 1 second and they all work the same, so no change there. Haven't got a chance to test WiFi to Ethernet, but based on the above is kinda safe to assume it should work fine.

The only one note and not even a big deal, and probably not even eel, when using host=socket.getfqdn() and port=443 i kept getting Network Access Denied on the Javascript console, but honestly it was probably me and resorted back to the defaults: localhost:8000

Thanks for this man :)

[samuelhwilliams]

Awesome - glad to hear it's helped. I'll see about pushing it into a release over the next day or two.

Re: Network Access Denied - I suspect that's more related to using a port <1024 that needs special permissions. Feel free to open a new issue about it if you like - but it feels to be probably not a fault of Eel directly (happy to be proved wrong if it is though).

Mind if I close this off for now?

[alepodj]

By all means please close this issue. Im quite happy with the outcome :)

Cheers