Hello.
My question essentially is: does setting these two parameters in Application.xml lower than default impose significant load on WMS? What minimum would you suggest?
In my video conference, when someone gets disconnected from WMS (due to network issues), I want to inform subscribers that he is temporarily offline (but still listed in the conference - in hopes of connecting back soon). But this can only be done after my WMS module’s ‘onDisconnect’ call, which happens after a ping timeout. The subscribers are seeing an empty NetStream during the timeout.
The resulting pause equals + [milliseconds]
Hence the question. What if, for instance, I set both PingTimeout and ValidationFrequency to 1000?
Thank you in advance.
The affect of shortening these settings on overhead will increase with server-load. At the high end I think it would be significant. Of course you would have to test and measure to see actual difference. If all clients are Flash RTMP, and not RTMPT, RTMPS, etc, then I think you have more flexibility, i.e., you can make these values shorter. If some clients are RTMPT, etc, making these values too short might disconnect clients that shouldn’t be.
Richard
No, there should be no difference like that, in fact I there might not be any difference in this regard. RTMPT can be more fragile on the client-side, more easily affected by network difficulties that would not affect RTMP. I’m not sure if that affects the server-side PingTimeout mechanism.
Richard
here is other info:
PingTimeout and ValidationFrequency only apply to RTMP connections not RTMPT connections. Lowering these values will through the onDisconnect event earlier when there are network problems. Lowering these values could lead to more false disconnects
Sorry for the confusion.
Richard
I’m sorry, I don’t really understand the problem. Yes, PingTimeout and ValidationFrequency affect how RTMP clients are handled in this case.
Richard
Benny,
Right, okay, “…Same client ID as well”. I don’t think that is possible. Can you suggest steps to replicate that?
Richard
hey guys!
Wanted to revive this thread as I’m seeing some weird issues with when onConnect and onDisconnect are fired off…
When we test network connection drops (by un-plugging / plugging in an ethernet cable for example) we notice that sometimes onDisconnect gets fired a few seconds after a successful connect. Same client ID as well, so not sure why or how to prevent it other than lowering PingTimeout and ValidationFrequency significantly.
Any insight, dudes?
Hey Richard,
in my post I mentioned how onDisconnect gets called after a successful reconnect, that’s the issue. Anything we can do to prevent it?
Hey Richard!
Sure, we’ve seen it when we frequently disconnect and connect our internet connection to replicate wish-washy connections. I could be mistaken on the client id though, I can try to repro again and update here if that’s the case.
Even if it’s not the same client id, onDisconnect still gets called after the client reconnected and it kills the push publisher. I guess the first connection is timing out? The client has to reconnect in order to get the publisher working again. I’ll see what I can do about the client id stuff now though, will post an update if I can repro that part of it.
Thank you, Richard.
Could you please elaborate a bit on the protocols? Does it take longer for RTMPE to respond to pings from WMS than RTMP?
