easywsclient with TinyThread

[phlegx]

I'm not able to get work my program with TinyThread. In the main() I start the connection and a thread makes the loop with poll and dispatch. Any idea?

Regards

[dhbaird]

I'd like to help you get this working, but I'm going to need more information. Can you post a gist with the most minimal example possible that illustrates your issue?

[phlegx]

See my sample code here :) https://gist.github.com/phlegx/a1ac7869ac69a177616d

PROBLEM: After the wss->send("PING"); the connection get closed. Why?

EDIT: I have see that easywsclient don't holds the connection. If I use a javascript client all works fine! Any idea? EDIT2: If I use the simple em-websocket all works fine!

[dhbaird]

Let's break this into three distinct issues.

1. The way you are accessing wss from multiple threads is not safe. You'll need to guard each access to wss with a lock, here's an example: https://gist.github.com/dhbaird/c8f57409cdb35f769759 (there's probably a simpler way to do this, with less locking or fewer threads, but this gets you started with better thread safety)
2. It looks like an auto-reconnect feature might be useful to incorporate into easywsclient.
3. When I try your code with ws://echo.websocket.org (instead of ws://192.168.1.10:3000), I don't get disconnected, so your issue about frequent disconnection appears to be a localized issue with your server. Do you know how long it takes to get disconnected? What server are you using?

[phlegx]

Nice sample code! Thx :+1: i'm happy :D I check this code and your questions and write you back...

:D

[codervinod]

Hi dhbaird, I am trying to use library and would like to implement full duplex communication. Basically create 2 threads and send messages from one thread and receive messages in other thread. Is this easily possible? Your solution will make communication half duplex as mutex prevents sending and receiving at the same time,

[dhbaird]

@vinodg - You could open two (or more) web socket connections, one per thread. Then you can get even better than full duplex :) I am willing to consider API ideas that can address this issue in a generic way (i.e. the details of threading or mutexes should not be built into this library, unless it is done in a generic way that is optional; But if the API can be updated in a way that makes it more useful to a user who wants to use threads and mutexes from outside of this library, then that is worth looking into.).