Trying to send mouseclick to remote computer

[UnitedStatesian]

 

I'm trying to send mouseclick commands to a remote computer.  I was attempting to do this with a TCP server on the machine originating the clicks and a TCP client on the machine executing them.  I was doing this using verbatim the example code in the helpfiles for TCPConnect() and TCPAccept() with the only modifications being the addition of a single mouseclick() function call, the use of a port number close to the example code's 65432 that is assigned to $iPort in both the client and server code and the use of the local and public IP addresses for the computer running the server code, with the local IP used for the server code and the public IP used for the client code. 

I know next to nothing about networking, so this might not even be the best way to accomplish a one-way remote mouseclick command.  The client computer doesn't need to send anything back to the server after initiation. 

It is not working.  I tried it initially on the 127.0.0.1 test IP address and it worked fine.  The computer acting as a server is on a router, currently wifi.  I can also plug it into the router via ethernet, but that seems to still require both a public and private IP address to be used.  I therefore attempted to set up port forwarding.  The IP address for the port forwarding assignment is the computer's local IP address, and both the external and internal ports are a number that is close to that used in the example code of 65432. 

I compiled the script and attempted to add it to Windows Firewall.  When I try to run the server code followed by the client code a second or two later, it simply fails, setting @error to 0 and TCPConnect() returning -1. 

What am I doing wrong?  And is there a better way to send a one-way mouseclick command, e.g. could I somehow broadcast it?   Thanks.  

Update:  Strangely, I got the server code to respond using a port forwarding tester.  There must be something wrong with the client code or a firewall is stopping it somehow.  But that is strange because I tested the IP address earlier with autoit's ping function and it worked.    

After further testing, the help file version of the client, using IP 127.0.0.1 and port 65432, works fine.  My version of the server script, using a real IP address and port 65400 also works fine when tested with yougetsignal.com.  My version of the client side, which attempts to connect to the same real public IP address that I am typing into yougetsignal, doesn't work at all.  I also compiled the client script and added it to be allowed through Windows Firewall, with zero effect.      

The TLDR; at this point is that the server and client code work in test mode on loopback IP, the server code works fine when being "pinged" by yougetsignal.com.  The server IP address also returns a pong in like 120ms when pinged from the client computer over the internet, but that doesn't trigger the server code even when the port is appended, like 72.x.x.x:65400.  And client code doesn't work at all over the internet, period, no matter what I do. 

At this point I might go with a duct tape solution.  After spending the entire day on this yesterday, the complexity level of this networking stuff is so extreme it might take 1000 hours to figure out how to send "hello world".     

*It appears I probably have client and server sides installed on wrong machines, but at this point I just want to prove that a connection can be established.

Edited July 9 by UnitedStatesian

[UnitedStatesian]

Wow.  I've had some dumb time-wasting adventures in programming but this one might take the cake.  I got so distracted by trying to figure out all the networking jargon, tools, and concepts that I failed to notice the IP address was somehow missing a digit that must have not been fully copied when I was installing the client on the other computer.  

I fixed the IP address and it works fine.  SMDH.