Tcp binding in my AutoIt executable is being rejected after a month of working properly - (Moved)

[BenfnJovi]

I have a tcp server script that has been compiled and running fine on 49 Win 10 machines for around 30 days. These machines will be going into a production environment soon, and I'd like to get to the root cause of this issue before deployment. 

A little background on what I'm doing so as to not confuse anyone with the unique nature of how these are setup: The machines that are running the script are a secondary or daughter machine, if you will, to a more robust main machine in a cabinet, and they just listen for commands from the main machine to start browser apps on other monitors, depending on what the main machine requests. The main machines all have a secondary nic specifically to communicate with the daughter machines and all daughter machines have identical images, with identical ip configurations that the tcp server binds to.

When I came back to work from the weekend, two of the secondary machines do not allow the tcplisten() command to bind to the IP and/or port. I'm not sure which is being rejected, because I didn't include returning the error code in the error message when I compiled. I just show a message that it cannot connect. I've went through everything I could think of to figure this out, to no avail. I finally added in _WinAPI_GetLastErrorMessage ( ) so that I could see specifically what was being returned by the OS, recompiled, and it started binding again as if there were no issues. Literally, the only thing I added was the necessary include and a variable to store the WinAPI returned information to print in the error message. Nothing else was changed. I went back to the previous compiled version, and the connection was again rejected. The 47 other machines are still functioning just fine. It's just these two that are not. This leads me to believe that, for some reason, something happened in the OS and it is now rejecting the binding based on the earlier executable's file signature and not the new version(they are named exactly the same), since that's all I can think of that's truly changed. While it's technically working right now, I do not want them to go out into the field and randomly have the issue again. Have any of you ever came across an issue like this?

[argumentum]

2 minutes ago, BenfnJovi said:

leads me to believe that, for some reason, something happened in the OS

Firewall ?

[Jos]

Moved to the appropriate AutoIt General Help and Support forum, as the Developer General Discussion forum very clearly states:

Quote

General development and scripting discussions.

---

Do not create AutoIt-related topics here, use the AutoIt General Help and Support or AutoIt Technical Discussion forums.

Moderation Team

[BenfnJovi]

@argumentum... The firewall was setup when I first deployed the app on the machines... I did, however, double check and also turned it off, to no avail. I don.t believe the firewall is signature/timestamp based either, so the second compile shouldn't have worked, if that was the cause.

[argumentum]

I have my head on a thousand things right now. But would a watchdog work ?, to check on the script and restart it ?. ( if it was functional to start with )
Also, have you tried other ports ?, see how they behave ?  ( I'll do testing if you provide the code )

[BenfnJovi]

A watchdog app would not work as tcplisten() fails to bind every time, even on a reboot, until I recompiled. It also doesn't make sense to change the port since a simple recompile allowed the script to begin binding with the same IP and port again. The port is hardcoded on my compiled script, as well as the c++ app on the main machine. It is not something we want to reconfigure often, as we need all machines to use the same version in the field.  I'm 99% sure this isn't actually a code problem, but an OS problem, because like I said, it worked fine for over 30 days on these two machines and is still working fine on the other 47 machines, and simply recompiling the code with no change allows it to start functioning again.

 

Edited February 13 by BenfnJovi