What could be root cause of unstable connection btw server and client, and any workarounds?
Completed
When we have installed Nx Witness Media Server and Desktop in a private network, then the connection was really unstable between Server and Desktop. At launching the Desktop, Desktop displayed message like "disconnected, try to connect to server again" repeatedly and did not launch. It looked to failed to retrieve camera information.
In this situation, may I know potential root cause? For example, communication latency, narrow bandwidth, etc. and could you give me any workarounds: expanding timeout period, etc.?
-
Hi Keisuke Sawada,
Sorry, it's not completely clear to me what you mean by "did not launch". If it is because of the Client process itself, it might not be related to the networking at all. It would look more like interference of something like antivirus software that might block 3rd party application activities especially ones that depend on networking a lot like Nx Witness.
If it is not the case, let me address some of your concerns.
Almost anything that you do with the client(connection, open camera for the video view, changing the settings, etc.) relies on the granular independent https sessions. Even if some of them are lost/failed/timed out, you will not see the described issues. Each one of them has its own timeout of ~30 seconds which is usually more than enough.There is one connection though which if fails/timed out, client will be forced to reconnect. But it is pretty lightweight, the traffic does not exceed 100 kilobytes per second even for larger systems of many servers.
Basically, the software is pretty well-optimized for work in the internet environment that often means quite bad bandwidth and latency conditions. So as per your description it looks like there are signs of more crucial interventions such as:
- Firewall blocking/dropping some outbound connections
- Something blocking the inbound responses within the same sessions
- Antivirus influencing the software
0 -
Hello Sergey Yuldashev,
Thank you very much for your response. Your comment is exactly right. Actually the private network bandwidth is approximately up to 300kbps and looks not to allow multi sessions. That might cause this phenomenon.
To proceed our own investigation, may I know how to realize followings?
- Exceed time out for all independent session.
- Disable encryption communication for debugging purpose.
0 -
Hello Sergey Yuldashev,
Still we need to know following information to proceed our investigation, I have posted last time. If you can provide it, it would be really helpful for us. Regardless of the possibility, I'd like to know the response of it (supported or un-supported).
- Exceed time out for all independent session.
- Disable encryption communication for debugging purpose.
0 -
Hi Keisuke Sawada,
Sorry for the late response.
- Timeouts can not be modified, those are constants within the source code.
- Client is forced to https-only mode which can not be disabled. If you want to decrypt tls traffic, there are certain means depending on the tools you're using. E.g. in wireshark it is implemented like this.
0 -
Hello Sergey Yuldashev,
Okay, I got it. Thank you very much for supporting us.
0
Post is closed for comments.
Comments
5 comments