Hi,
Are there any restrictions of using TCP/IP sockets in Ignition modules (Irrespective of Ignition version 7.6 or 7.7 or which ever web server) ? If yes then what are they?
Best Regards
PRAMANJ
No restrictions.
but i observed a socket client works fine on same host but not from another machine on the network! it gives some run time error! Is my observation correct or there must be some coding error?
regards
PRAMANJ
Must be an issue with the code, we don’t restrict what your module does in any way.
Dear Kevin,
Thanks a lot for the reply. I will relook at the code and give exact code snippet and error messages that I got.
Best regards
PRAMANJ
Perhaps there might have been a port number conflict. Are there any reserved ports in Ignition? I should avoid using them. I think i used 4444. It is reserved?
regards
PRAMANJ
No Kevin! A client on network is unable to connect to server in my ignition module. Whereas a local client on the host server works fine! Any clues why its happening?
regards
PRAMANJ
Then you should check the firewall. If the client running locally on server connect and client running in another machine not, maybe could be a firewall filtering or another network configuration issue.
But a stand alone socket server outside Ignition is connecting to network client!
regards
PRAMANJ
You can use netstat to see what ports are active and the PID (process ID) using it:
Windows:
netstat -a -o | FIND "LISTENING" | MORE
Linux:
netstat -l -p | more
as per the list displayed, there is no conflict of port number. However the list is quite big surprisingly! There are 43 processes and 14 unique PIDs and 5 different IP addresses! 127.0.0.1; 169.254.213.64; 192.168.1.3; 0.0.0.0; [::]. This is only LISTENTING filtered, without it list is even bigger! I am wondering why so many sockets!
Regards
PRAMANJ
localhost (127.0.0.1), 0.0.0.0, and 169.x.x.x are all internal. Windows (and Linux) use TCP/UDP as a transport layer between applications and services. Found that out the hard way, when I managed to delete the loopback adapter off my linux machine! 
Your next step is to see if the port is available to use outside the server. 
nmap or netcat are good command-line tools. So is PortQuery.
Thanks for the clue, that explains the IP addresses and presnce of other TCP sockets.
Best Regards
PRAMANJ
Hi,
I would like to once again open this topic!
I am unable to connect to a TCP server socket created in my Ignition module from a TCP client running on a remote machine in the network. Whereas the same client code works if executed on the Ignition server (localhost). 
If I create a TCP socket outside the Ignition module in a standalone java program then the same TCP client works fine from a remote machine on the network as well as on the local server machine where the standalone java program (TCP server) is running!
This gives me a doubt if somehow the Ignition module is blocking direct TCP connection from a remote machine having TCP client socket!
Can someone clarify what could be going wrong!
BR
PRAMANJ
There’s absolutely nothing in Ignition restricting your ability to open up sockets.
When you try to open one in you module do you get an error message? What’s the error message when the client on the other end tries to connect?
The client on other machine cannot connect (times out with an exception) to the TCP server socket in side my Ignition module. Where as if I have the Server socket in a standalone application, it works fine. I would prefer the client directly to the TCP server in my ignition module.
BR
PRAMANJ
The connection request from TCP/IP client to Socket server is timing out, as if the host name is not recognized by server in the request to connect to socket server! Where as if the client application is on the same physical machine as the Server then request works fine! Does ignition do something to hide the server name? I tried giving IP address as well but that also doesn’t worked.
Any clarification will help.
Regards
PRAMANJ
Did you ever get anywhere with this? I am having the same exact problem.
Nine years later?
Yes it was resolved long back! If I remember correctly there was an error in my code where a python socket server was getting opened in the script locally rather than a java socket imported from java.net library. Hence the socket server was accessible from local machine but not from other machine on the network!
Kevin was right in his reply in the above trail.