prooto-client - ability to disable node-retry
See original GitHub issueHi guys,
At the moment protoo-client always auto retries WS connections due to wasConnected
check here.
The only way around this is to try to set _closed
true here.
Would you guys willing to accepts PRs to disable the usage of node-retry when creating WebSocketTransport?
The main reason is that for code maintenance, using event callback events can become hard to maintain. An example is when a mediasoup transport fails when connecting to a VPN during a call and the WS keeps the connection alive.
Tks.
Issue Analytics
- State:
- Created 3 years ago
- Comments:13 (13 by maintainers)
Top Results From Across the Web
HTTP Client and automatic request retry · Issue #14087 - GitHub
Does anyone know if there's a case where the node http client library would automatically retry a request? Has anyone else deeper insights?...
Read more >Configuring retry policy for grpc request - Stack Overflow
I wasn't adding the proto package name when listing the services. So the retry policy should be: var retryPolicy = `{ "methodConfig": ...
Read more >Publish with retry settings | Cloud Pub/Sub Documentation
Stay organized with collections Save and categorize content based on your preferences. Applies retry delay and/or retry timeout settings on the publisher ......
Read more >Agents - Configuration File Reference | Consul
Use agent configuration files to assign attributes to agents and configure multiple agents at once. Learn about agent configuration file parameters and ...
Read more >DataStax Node.js Driver - ClientOptions
Name Type Description
policies Object
policies.retry RetryPolicy The retry policy.
policies.reconnection ReconnectionPolicy The reconnection policy to be used.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
First, if the WebRTC transports “disconnects” it can still become “connected” alone. If its state becomes “failed”, then no. In the former case you don’t need to do anything but wait. In the latter you have a problem and may need to restart the transport (
transport.restartIce()
).If the WS disconnects then you have have to reset all your WebRTC status anyway.
The main issue is that when connecting to a VPN when in a call, the receiver(producer)Transport disconnects and other people loose the video/audio with that peer.
The client app could restart it but the callback logic become very hard to maintain, so the app just resets itself and just one loading code path to simplify.
I can see this issue on mediasoup-demo. Sure I know the demo is just a demo not a full product.