The online demo doesn't seem to match the actual source code

[mikkorantalainen]

The demo at https://codepen.io/thealmarques/full/YzqOrWV seems to use websocket connections but the code published at https://github.com/thealmarques/tinymce-collaborative-editing-plugin seems to use polling instead.

Is this intentional? I would have expected the published code to match the published demo but it doesn't look like it.

[thealmarques]

Hey! There is no polling! If you look carefully you can find the module that also uses websockets: collaborative.ts

[mikkorantalainen]

It seems that if socketUrl starts with letters https://(by mistake) the code will automatically switch to polling but it will try websocket connection if socketUrl starts with wss://. It also seems that any path in socketUrl is always ignored and replaced with hardcoded string /socket.io.

Also worth mentioning is that socket.io is not standard WebSocket connection but a custom protocol (https://socket.io/docs/v4/#what-socketio-is-not). I'm using HAProxy as reverse proxy (and TLS termination) and I can't get socket.io connections to go through the proxy even though native WebSocket in client + ws WebSocket Server work just fine. I'm still not sure if this is caused by something in socket.io or in HAProxy.

It might be that you can get non-polling behavior with direct port connection.

[mikkorantalainen]

The demo at https://codepen.io/thealmarques/pen/YzqOrWV seems to have socketUrl starting with https:// but the browser still connects with WebSocket connection. I still don't understand how it can work unless the code depends in some specific behavior of some non-updated dependency. I started with updating all dependencies after cloning the source.

[mikkorantalainen]

In addition, running the server code with ts-node ./src/server.ts seems to randomly crash with following error:

Error: read ECONNRESET
    at TCP.onStreamRead (internal/stream_base_commons.js:111:27)
npm ERR! code ELIFECYCLE
npm ERR! errno 1

I think this is a bug in ts-node. I think it's related to nodejs/node#23169

This crash happens when I run the server behind HAProxy but it suggests that if the browser client TCP/IP traffic looks similar to HAProxy traffic in some situations, the server would also crash with direct client connection.

[mike-mgt]

Hi @mikkorantalainen, did you ever get this to work? I'm looking to implement this in a project, but I wonder if the project is dead. Thanks.