Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug 2 in send #82

Open
bkp7 opened this issue Oct 28, 2020 · 2 comments
Open

Bug 2 in send #82

bkp7 opened this issue Oct 28, 2020 · 2 comments
Labels
bug Something isn't working

Comments

@bkp7
Copy link

bkp7 commented Oct 28, 2020

I believe that whilst the first call to send is successful, subsequent calls fail. This I believe is due to the code at line 356 in samsung.ts whereby the command is only actually sent following the opening of the websocket connection. Subsequent calls don't open a websocket so are not actually sent. This Hypothesis needs to be checked by someone more familiar then I.

@Letrab
Copy link

Letrab commented Jan 4, 2021

How would you tackle this @Toxblh ? Happy to contribute.

I saw you moved from keeping the WS socket as a global state. But now, the WS socket is not closed on each possible path (error, ...) and thus also created this bug.

I would suggest to move it back to global, but check whether it's still connected on each send call?
As e.g. here: https://dev.to/karlhadwen/node-js-websocket-tutorial-real-time-chat-room-using-multiple-clients-24ad (search for init())

Or use a library for this, which even buffers send calls when the socket is disconnected?https://www.npmjs.com/package/reconnecting-websocket

@Toxblh
Copy link
Owner

Toxblh commented Jan 4, 2021

It's not a problem to keep a connection. A big problem to match requests and responses in async. I can send requests 1, 2, 3 and receive 2, error, 1, and I can't pass an independent token to each request, that is why I use the approach open -> req -> res -> close to resolve this.
Another way it creates a queue and resolve requests like "sync" mode "open connection, pop from stack request, awaits a response, to receive a response, exec callback -> repeat from the step pop from stack"

I chose just to recreate a connection. A bit slower, but also easy to implement

I understand your point. Will improve works after any errors

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants