Why was XHR fallback removed?

[netop]

I was wondering why XHR fallback was removed at #506? I am aware of the shortcomings and issues with the previous implementation, but still it did work in some cases.

Our solution targets the education space and the infrastructure there still features some pretty old proxies without WSS support - or some cases where the admins are not willing to enable that support.

Will it make sense for me to work on a PR to re-add XHR support, perhaps making it more reliable, optional and as separated from the WebSocket code as possible?

[afrokick]

Of course, it will be cool.

[netop]

@afrokick OK - will start from code just before #506, test on fork and submit for review. I was just wondering if this was something which is still of interest for the project. Thank you.

[netop]

@afrokick I've re-added the XHR streaming as fallback to websocket, in our fork of peerjs Here is the actual commit, if you have some time to review it.

The implementation is using the original (pre #506 ) ported code, but uses it only if the websocket connection fails within a timeout of 5 seconds. It works with the current version of the signaling server, as tested from Chrome. I've focused mainly on keeping the code as isolated as possible and making absolute minimal changes to the current upstream code - therefore there are a few choices which are not great from the OOP perspective (like the factory function or deriving a more general type of connection from Socket).

I am however unsure of the practicality of this fallback (beyond allowing a backwards-compatible upgrade of the peerjs library). Like I mentioned before, websockets might be unsupported by proxies that do HTTPS inspection on CONNECT and cannot or will not handle the websocket upgrade. But will these proxies support streaming chunked connections (which require response buffering to be disabled)? Also, depending on how websocket support is lacking, reusing websocket upgrade-pending server connections will affect the chunked fallback.

I believe that, while the fallback concept is useful, falling back to chunked transfer streaming is not really practical. Instead, from the proxy scenario perspective, a classic (long) polling would be preferable - with the server keeping a buffer of messages available for each peerId key, with an expiration TTL. The client would then use regular XHR polling to keep alive the peer and retrieve any pending messages, while the server would terminate individual requests with the response, when available. Disconnection for the client would then happen either through failure to connect to the server, or through an error response from it (like peerId not found/expired).

The 0.3.0 version of the server drops the XHR streaming altogether, in favor of websocket. Maybe implementing non-chunked polling in 0.3.0, and also in the client could be an option?

Any feedback would be appreciated - I would really like to stay as close to upstream as possible... Thank you!

[kidandcat]

Just for curiosity, have you tested webrtc in that environment? I find it hard to believe that in an environment wrapped by proxies old enough to not support websockets, webrtc works at all.

[netop]

@kidandcat Sometimes it's not about the possibility to connect the peers - since they might actually be in the same subnet and host candidates would work. Sometimes it's just about inspecting outgoing and incoming traffic which causes problems with the signaling server connection. I fully agree that the proxy idea in itself is an outdated concept, but it is still very much alive in these scenarios. One workaround is to suggest the installation of a local signaling service, but that is rarely acceptable.