You can ditch the channel function, that was really to show where to initialize your app code. So all you need to do is check if you have yet to establish a connection on socket.onError, then disconnect and instantiate a new LiveSocket with the long poll transport.
chrismccord
Creator of Phoenix
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
I’m finding that disconnecting is not doing what I’d like. The socket initially created still attempts to reconnect even after calling disconnect until it reaches its maximum retry count.
0
LostKobrakai
I got curious how socket.io handles the issue and I found this information:
Since Socket.IO 1.x, the fallback algorithm changed from a downgrade approach to an upgrade approach.
Long polling pretty much works everywhere, so that is used at first so you can get a “connection” right away. Then in the background, an attempt is made to upgrade the long polling connection to a websocket connection. If the upgrade is successful, the long polling stops and the session switches to the websocket connection. If it’s not successful, the long polling “connection” stays open and continues to be used.
I’m wondering if something like that would be possible in phoenix?
6
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
Perhaps the concern there is latency? You effectively double the time required to have a working websocket connection.
1
florish
To follow up on my own post: we tried to fix the issue by enabling longpoll transport as a fallback (Elixir side). This did not fix the connection issue for our customers in their Citrix environment. We then did what @chrismccord suggested in post #8 (making longpoll the default and disabling websockets). This did the trick.
Given the above, I think I can conclude that in our case, the fallback mechanism did not do anything somehow. Haven’t had the opportunity to assess why (hard to do as we are not able to reproduce the error locally), but if Citrix disables websocket connections somewhere on the network level, I can imagine that this is an unhandled case, as the fallback mechanism may be based on a browser not supporting websockets.
If anyone has ideas on how to get to the root of this, I’d love to help, but I’m afraid I need some initial pointers to get started.
4
Thibault
Yes, this was my problem. Browser worked fine, but the client (bank, they tend to be paranoid) infrastructure involved proxies that blocked any websocket. So this was blocked at the network level too and fallback was not applied.
I don’t think this is a rare use case in big companies.
2
chrismccord
Creator of Phoenix
To be clear, the “fallback” only happens if window.WebSocket is undefined. Transport fallback after trying websockets must be user implemented. As you so also, you can hardcode the transport.
3