Questions about maintaining an eternal connection #3301
Comments
|
You should look at the Secure Streams version of the same example. In the -lowlevel version, the app deals with a wsi which represents a connection. The wsi is destroyed when the connection fails or ends. Retrying this with a new wsi when needed is the job of the app. In the -ss version, the app deals with a higher level object that represents the endpoint (via JSON which describes how to connect to the endpoint, including the rules for reconnecting). The wsi representing a particular connection attempt is "inside" the Secure Streams object, such that the SS object outlives any particular connection, and is in a position to auto-retry, since it isn't destroyed like the wsi when the connection attempt fails or ends. |
|
Thanks for the explanation about the difference between the -lowlevel and -ss versions. |
|
Nothing you can do at the client can avoid data loss during downtime. You can have n connections from different places that are combined uniquely to try to reduce it, but in the end the server itself can have downtime. I explained why you should look at the ss version. Lws can detect connections becoming invalid (not passing valid data for some timeout) and auto-retry the connection. https://github.com/warmcat/libwebsockets/blob/main/READMEs/README.lws_retry.md |
This is not a bug report, the library is working perfectly.
I just would like to know exactly which parameters must be set in a client code to maintain a permanent connection to a server.
In particular, with the following example:
https://github.com/warmcat/libwebsockets/blob/main/minimal-examples-lowlevel/ws-client/minimal-ws-client-binance/main.c
Let us suppose that the server requires a ping every 60 seconds to keep the connection alive,
and that the client needs to have as few disconnection as possible (for example the client is receiving high frequency data, incrementally computes a variable from this data as it arrives, but the variable would be badly constructed if some data were missed).
What exact parameters should be set, with which optimal values ?
Now, once the client code is correctly set up with respect to 1), how should be managed the case where the server disconnects the client, but it is not the fault of the client (for example the server is experiencing issues).
What parameters should be set in the client code, so that it reconnects to the server, without any constraint of retry limit (as the connection needs to run eternally) ?
The text was updated successfully, but these errors were encountered: