Sockets get lost/stuck during communication

[legion151]

Hi there and thanks for your work.

I opened this to describe a very strange behaviour of the nativescript-websockets plugin where i cannot really explain what and where the bug lies, but maybe someone here might have the right idea. Or it might point to a bug somewhere in the software stack. Since it is a rather complex scenario i don't know if i can provide a minimal code example.

We use websockets to communicate between a web-app and a nativescript app and xchange data in an encrypted way. There are severeal messages included in a bidirectional way.
After initiating the communication it just stops at some point. Browser and Relay-Server are sending the message but the app just doesn't receive it. There is no error, no timeout, just waiting for the next message.
It mostly stops if a message is not sent immediately, which might happen during the first automatic steps. But it always happens at a message we only sent after human interaction in the browser app. Thus we firstly assumed issues with timeouts, but weren't able to find any timeout which would stop the communication silently. We also don't configure any.
During my attempts to figure out what happens, i noticed the "strange" behaviour mentioned.

I added a subscrption to monitor the socket reference:

interval(1000).subscribe(() => {
            console.log("This socket: ", this.socket);
        });

But instead of seeing more information about the problem, it just works. oO
I reproduced this several times and also on both platforms: android and ios.

We have a class encapsulating the websocket reference and details of our protocol.
This class also constructs the Socket and is adding the Eventhandlers.
That "floating" subscribtion above is added after creation of the socket.

This behaviour was introduced during upgrades from ns6 to ns8 which also includes switching to this nativescript-websocket-implementation. The ns6 variant works without this behaviour. The typescript code didn't change except for some minor changes due to the upgrade.

As said, i don't really have an idea where this fails, and after days of diggin i fear i never will find one.
I assume that somehow the reference or the thread waiting for the next message gets suspended without waking up anymore or collected or some other stuff which shouldn't happen and that that floating subscription somehow prevents that since it changes how the code is interpreted by the runtime.

For the time i will live with this hack, without sleeping well though.
But as said this might point to other problems in the stack.

Thanks
legion

[edusperoni]

Hello!

Can you share some kind of project where the issue is reproducible?

It might be due to some GC issue. Try setting globa.mySocket = this.socket once and see if the problem resolves. It might be because the websocket reference isn't being strongly held so it GCs the native socket.

[legion151]

Hi

as described our production code is rather complex at this point, so i can't provide a matching showcase. In addition we will replace it soon, so it is not that relevant anymore.

However we just built a showcase which also fails, and with a high propability that the underlying problem is the same.
https://github.com/legion151/socketDisappear

The repo can be build with

ns run android

The global referenced websockets work. As you suggested.
However the socket instance given to the callback as "this" is undefined as soon as the sending-callback tries to send.

We assume that the reference is lost somewhere in the WebSocket implementation and our original code fails for the same reason.