I'm currently testing a project migration from Ignition 8.1.54 to 8.3.7 and have run into an issue with system.util.sendMessage().
Our existing implementation targets Vision clients using the client hostname. In 8.1 this worked because the hostname was returned as just the machine name. However, in 8.3 it appears that the hostname now includes the DNS suffix.
For example:
Ignition 8.1.54
system.net.getHostName() → PC-NAME
Client hostname in message responses → PC-NAME
Ignition 8.3.7
system.net.getHostName() still returns PC-NAME
However, system.util.sendMessage() responses list clients as PC-NAME.domain.local
I can also confirm the same behaviour from the Gateway Vision Diagnostics page. The screenshots below are from two cloned Windows 11 VMs with identical network adapter settings, one running 8.1.54 and the other 8.3.7.
What I'm trying to determine is whether this is an intentional change in Ignition 8.3 or if it's related to something else in my environment. I haven't been able to find any mention of this change in the migration documentation or release notes.
Has anyone else seen this behaviour, or can confirm whether 8.3 now reports Vision client hostnames as FQDNs? If this is expected, I'm trying to determine the best approach for updating our existing messaging scripts without having to modify every hostname comparison.
This particular thing changing was not intentional, but the way the client/designer resolve their hostname and send it up to the client was. This was always a fairly fragile, "best-effort" thing, and for the sake of performance and correctness we swapped to an explicit enumeration of local interfaces meeting certain criteria. You can run this in the script console and see if that's the source of the different results:
from java.net import InetAddress, NetworkInterface, Inet4Address
def getHostName():
interfaces = NetworkInterface.getNetworkInterfaces()
while interfaces.hasMoreElements():
iface = interfaces.nextElement()
addresses = iface.getInetAddresses()
while addresses.hasMoreElements():
addr = addresses.nextElement()
if (not addr.isAnyLocalAddress()
and not addr.isLoopbackAddress()
and not addr.isMulticastAddress()
and isinstance(addr, Inet4Address)):
return addr.getHostName()
return InetAddress.getLocalHost().getHostName()
print "8.3", getHostName()
print "8.1", InetAddress.getLocalHost().getHostName()
Hi Paul, I have tried with 'Resolve Client Hostnames' on and off, and did not seem to affect anything, at least for what I was looking at in hostnames.
I tried that function and the print out matches the difference between them, I think I may move forward using system.vision.getClientId() and system.util.getSessionInfo() to find the session hostname that will always match the hostname required for the sendmessage to reach it again.
The below snippet seems to work well and should be backwards compatible and going forward if it changes for any reason should keep the hostname consistent with what sendMessage will expect
hostName = ''
clientId = system.vision.getClientId()
sessions = system.util.getSessionInfo()
for s in sessions:
if s['clientId'] == clientId:
hostName = s['address']
Consider not using host names. If the client is supplying anything to be used to guide a later .sendMessage(), it should be the client ID. No need to involve DNS at all.
I also tried this and was simple enough and also agree this would be the most reliable method, but the implementation will end up with multiple sessions on a single host, and this will be used to limit control to a single point hence using user/host such that it targets all sessions for that user on that host.
Haven't thought of another idea to achieve this but will be keeping my thoughts open as we test for any improvements.
@paul-griffith We have it working now, but I do have a follow up question.
Should both the '[System]Client/Network/Hostname' tag and system.net.getHostName() not return the same hostname required by sendMessage? Regardless of how it its resolved, I would expect these two to be aligned, or at least be have this documented in the sendMessage documentation that it requires a fully qualified name and that the tag/function does not return a fully qualified name.
That's a fair question. One answer is that we consider the return value of system.net.getHostName() (and the system tag, which internally actually calls in to the same code as the scripting function) sacrosanct public API, subject to a backwards compatibility contract, but we don't consider the hostname the client/designer self-reports to the gateway to be stable public API.
And while that's true, a more honest answer is that we probably just didn't realize the discrepancy.
I will say that in general, what Phil suggested is the best advice. Using Ignition's internal identifiers is definitely going to be more future-proof.
I will add that when I was studying how to implement my Integration Toolkit's @system.util.runInClient decorator, I explicitly rejected attempting to implement anything other than client ID targetting.
IA may be stuck maintaining support for something that depends on the environment's DNS implementation, but I'm not putting my hand into that meat grinder. FWIW.
