Although Reflection Desktop (and all the other thick-client programs like Extra!, InfoConnect, and Rumba) use TCP/IP connections to get to the host, these are considered “persistent” TCP/IP connections, unlike the connections used by web browsers using HTTP and HTTPS (which are quickly opened, established, used and then closed; over-and-over again). These Windows-based host emulators build a TCP/IP connection using a pair of TCP Ports, one on the PC side and one at the host side, and the TCP/IP connection between these pairs must be maintained the whole time the host session is connected or else the host session will drop and disconnect. Once the TCP connection is established, it is maintained by Microsoft Windows (as persistent), until one of the parties at either end (typically the Host or PC software), decides to intentionally terminate the connection.
Reflection Desktop does not talk directly to the TCP/IP stack of Microsoft Windows, but instead talks though the Windows Socket Interface (WinSock), which in turn then talks to the Windows TCP/IP stack. Thus, when you take a Reflection communication trace, or get log files from the Reflection software, you are getting information “above” the WINSOCK interface, and not from the TCP/IP stack or the Host directly. If a SocketClose() type command is seen in the Reflection communication trace, it could mean a number of things; from the Host sending a disconnect, something on the network dropping the TCP connection, or the Windows TCP/IP stack itself just closing the connection. All these events will cause the WINSOCK interface to report back to Reflection that the Host connection is gone, but will not give the real detailed reason as to why.
Although software communication traces and log files can be helpful, typically you will have to resort to a network level trace (like Wireshark) on the PC to see what is happening, even if the connection is encrypted. Start by looking for the TCP ports in use by the client for the TCP/IP connection (by examining the Telnet negotiation) and then follow this set of PC and host TCP ports to the disconnect event (TCP FIN or RST). Even if you can’t read the traffic in the packets because of encryption, you can examine the TCP Requests and Responses (ACKs) to make sure they match up, to determine if traffic is making it from the PC side to the Host side of the connection and back.
Some Wireshark traces recently examined have shown the Windows TCP/IP stack on the PC sending SNA data to the host but the PC never receiving a TCP/IP Acknowledgement packet back. This is an indication that the data never arrived at the Host end, or else the data arrived and the response did not have a path back to the workstation. Regardless, the Wireshark trace showed the PC waited a few hundred milliseconds and then it started to send TCP/IP re-transmissions to the Host. These packets were never acknowledged, and the time interval between re-transmissions was increased until after about 5 retries over 6 seconds or so, the TCP/IP stack on the PC terminated the connection (due to lack of response). Reflection eventually received a SocketClose() type of message from WIINSOCK interface, and a dialog appeared in the Reflection host session that the host connection was dropped. To the user it appeared that Reflection dropped the connection, since they had pressed the ENTER key and sent a request to the Host and never got data back and a failed connection message.