Follow Us.
Become a Fan! 
A: The most common reasons that a Thin Client disconnects from the server are (1) a non-responsive terminal server, (2) a duplicate IP address, or (3) a saturated network.
All ThinManager Ready Thin Clients have a program that constantly monitors the Windows Terminal Server. Configuration for this program is found on the Monitoring page of the Terminal (or Group) Configuration Wizard. One of the main functions of this program is to check for responses from the terminal server. If at any time the server doesn't respond, the Thin Client will break the socket connection to the server and try to reconnect. If it determines that the server is unavailable, the client will move on and try to connect to the next terminal server in its configuration list.
Under normal conditions, the only way an ACP thin client will lose a connection to a terminal server is that the terminal server doesn't respond to the client, causing the client to drop the connection. One obvious reason the server may not respond is if it has been turned off. Assuming this is not the case, there are several things that should be checked.
The server may be non-responsive because it is locked up or because it is busy with another higher priority task. For a Terminal Server that is only hosting Thin Clients, the most common cause of this is that the client is requesting a screen that takes too much time to display. Whenever this particular screen is requested, the server begins the processing required to generate the screen and the initiates the file transfer. If this transfer is not completed before the Thin Client checks the status of the server, it is possible that the Thin Client may think the server is no longer available, causing the client to drop the connection. By the time the client checks a second time, the server has finished and so the client reconnects to the same machine, making it look like the screen simply knocked the client offline for a few seconds. This problem can be easily addressed by adjusting the Monitoring parameters from within ThinManager.
This is normally a problem that is only seen when the clients are using static IP addresses. The conflicts among devices with the same IP address frequently cause the client to drop-off and reboot. The Thin Client may connect again and then get dropped off in what becomes an endless cycle.
If the network is saturated with traffic, the Thin Client's monitoring requests can't get through. This may be a problem on a 10-based T network, but is unlikely in a 10/100 network. However, regardless of raw network bandwidth, poorly designed networks are probably the leading cause of thin client drop offs. This includes incorrect configuration of routers, hubs or switches.
One other cause that we have seen for a dropped connection is a faulty power supply on the Thin Client. This causes the client to turn off and then back on, making it look like a software problem instead of a hardware issue.
How does a Thin Client get "lost" anyway? And if the Thin Client somehow becomes detached from the Terminal Server, why does the server have such a problem with it?
A Windows Terminal Server has no knowledge of the clients that are connected to it. Once a client session is started, the session will continue to run on the terminal server. If the client is turned off, the terminal server will not notice until it needs to send a screen update to the client. When the update is sent, but the client is unresponsive, the server will change the session from "Active" to "Disconnected".
Unless specifically terminated (or the server is rebooted) a "Disconnected" session will stay on a server forever. The session can be terminated either manually or it can be set to be killed automatically via the user's profile. The reason that the disconnected session is not usually terminated is because it is waiting for the client to come back online. If the client reconnects to the same server, it will reconnect to the disconnected session and everything is as it was.
If the server hasn't recognized that the client was offline and moved the session to the "Disconnected" state (the session still shows up as "Active"), then the client will start a new, duplicate session. This is why ACP recommends that each client has an active graphic on the display - something like a clock or the network connection icon. These graphics are frequently updated, which allows the server to notice a turned off client quickly and mark its session "Disconnected"
For more information on ACP Industrial Thin Client computers, please visit our web site at http://www.thinmanager.com
To sign up for the E-mail newsletter go here: ACP newsletter signup
For an archive of past newsletter articles go to: ACP Newsletter Archive
Copyright © Automation Control Products, Inc. All rights reserved.
