Celso Henrique 8 Posted December 2, 2020 Hello people, I developed an application to work in a critical environment. My application has 4 modules: 1. Server 2. Manager 3. Terminal 4. Handheld All modules connect to the Server module by Tethering. All modules have only 1 Manager and 1 Profile. The modules Manager and Terminal are executed on remote machines, while the Handheld module is executed inside the same machine where the Server module is executed. The problem I am having is that the Server module starts executing very well and for a while it communicates with the other modules without any problem, but after some time, it starts to refuse connections. Looking through WireShark, I found the message: Destination Unreachable (port unreachable). To work around this problem, I changed the Windows registry to increase the number of available ports (65535) and to decrease the wait time (30s). Even so, I continued to have problems. My last attempt was to increase the range of ports used by the component. I'm working with 2020-2119 for ManagerPort and 2120-2250 for AvPort. This also did not resolve. Whenever the Server starts to refuse connection, I am obliged to restart the machine. I really need your help. Share this post Link to post
Celso Henrique 8 Posted December 16, 2020 Hello people, I figured out that the problem is not the time, but incomplete connections. My application has a timer that runs indefinitely until get the connection with the Server. Some machines start the connection negotiation but it never ends because of local firewall rules. When this happens, the Manager stops to respond other connections (new or old) just trying to make this connection. Look the Wiresharck log attached. The IP 10.106.1.8 is the Server and the IP 10.106.22.95 is the Client. I would like to know how I can avoid this. Is there a way to identify these machines without use Wireshark? Is there a way to make Manager not stop to respond other machines? Thanks! BR. Share this post Link to post
Celso Henrique 8 Posted December 27, 2020 Nobody can help me? Neither you, @Remy Lebeau? Share this post Link to post
Remy Lebeau 1394 Posted December 28, 2020 (edited) On 12/27/2020 at 6:04 AM, Celso Henrique said: Nobody can help me? Neither you, @Remy Lebeau? Sorry, no. I've never worked with App Tethering. Edited December 28, 2020 by Remy Lebeau Share this post Link to post
Celso Henrique 8 Posted December 29, 2020 But App Tethering is based on Indy components... Share this post Link to post
Remy Lebeau 1394 Posted December 29, 2020 (edited) 9 hours ago, Celso Henrique said: But App Tethering is based on Indy components... But the issue would still be dependent on HOW AppTethering is using Indy internally. Why the Server is using so many ports, and why there are so many incomplete connections between components. What you describe sounds like port exhaustion, but you shouldn't be getting that on a TCP server, only on a TCP client. Without these kind of details, I couldn't say whether the problem is due to an error in AppTethering itself, or in the user's configuration for AppTethering, etc. Edited December 29, 2020 by Remy Lebeau Share this post Link to post
Celso Henrique 8 Posted January 4, 2021 Thanks Remy and sorry to bother you. At first moment, when we were working with the Tokyo version, we had port exhaustion. Because that, we increased the number of user ports and reduced the time wait on Windows. One problem was solved, but a new problem appeared. Working with the Sydney version we stopped to have port exhaustion, but continue have connection problems. I am giving up to work with App Tethering. I will probably create my own communication structure using just TCPServer and TCPClient components. I think that will be less stressfull Thanks again. Share this post Link to post