Hi,
We’ve got about 30K concurrent rtmp connections on our network.
We have a very busy client that is setting up the rtmp net connection but only actually consumes media on a very few of them and the connections are hanging around for too long…
How do I reduce the amount of time an inactive rtmp connection stays alive for?
Thanks,
Joe
You can set this in /conf/VHost.xml /Client /ClientTimeout
Value is milliseconds.
Richard
Client timeout only applies to unhealthy connections. If we have not recieved and data from the client through the normal validation process and ClientTimeout has elapsed then we will close the TCP connection. I would not suggest going much below 30 second (30000).
Charlie
There is a little known configuration reference in the documentation folder where Wowza is installed, that I’m sure you will find interesting generally, and has this info on ClientTimeout and IdleFrequency:
Client/[ClientTimeout, IdleFrequency]
ClientTimeout is the time in milliseconds the server will wait before shutting down a non-responding client connection. IdleFrequency is the time in milliseconds between idle events. For basic video on demand streaming a value of 250 milliseconds will provide the best reliability versus performance ratio. For live streaming a value of between 125 and 250 milliseconds is more desirable. It will increase the frequency at which media data is sent to the Flash client. If you adjust this value, be sure to also adjust the IdleWorkers/IdleFrequency to a value that is at least four times smaller.
Richard
There is not a way to prevent such things from happening, but Wowza will clean up the loose connections.
Richard
Hi Richard,
What is the minimum value we can set for /conf/VHost.xml /Client /ClientTimeout? We are having problem with MAC rtmp clients not closing the rtmp connection.
Thank you
Thanks a lot Charlie. Anyway, are you guys familiar with the issue of OSX rtmps client not disconnecting properly from wowza after closing the window/browser? Any suggestions on how to fix it? Just found out that this issue happens only for rtmps and not in plain rtmp