You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am using the tungstenite client in some integration tests and I wish to test the case in which the client stop responding to pings.
Quoting the documentation:
..For example, upon receiving ping messages tungstenite queues pong replies automatically. The next call to read, write or flush will write & flush the pong reply. This means you should not respond to ping frames manually... ...Note that if read returns a ping, you should flush before passing a custom pong to write, otherwise the automatic queued response to the ping will not be sent as it will be replaced by your custom pong message.
It seems I might be able to overwrite the pong if I do not flush, but is there a way to disable this auto-pong behavior altogether? If not, would it be welcomed as a new feature?
The text was updated successfully, but these errors were encountered:
Currently, there is no way to disable this behavior.
As for the feature - I personally don't have any arguments against it as for now - we could have an additional flag in the config to change this behavior so long our defaults are sane and don't make the usage of the library more complicated; also, it should be relatively easy to implement (if we're talking only about auto-pongs; a bit more complex if we want to disable all auto-replies, such as replying to the close frames, etc);
Disabling auto replies effectively means disabling most of the impl WebSocket code. Looks like just using protocol::frame::Frame directly does the trick.
I am using the tungstenite client in some integration tests and I wish to test the case in which the client stop responding to pings.
Quoting the documentation:
It seems I might be able to overwrite the pong if I do not flush, but is there a way to disable this auto-pong behavior altogether? If not, would it be welcomed as a new feature?
The text was updated successfully, but these errors were encountered: