Evidence suggests that for dbsrv11.exe 188.8.131.5261 running on Windows 7 the value returned by PROPERTY ( 'TcpIpAddresses' ) is cached at server startup, since after a network change it continued to return an IP value that now no longer existed (can't be pinged, etcetera)
The dbsrv11 server continued to function through the network change, and when the dbsrv11 server was subsequently restarted calls to PROPERTY ( 'TcpIpAddresses' ) began returning a new (correct) value.
This is an important question because it is difficult to determine with perfect accuracy the answer to the question "Am I connected to the right server?" in a complex and ever-changing network with a whackload of engines running. Until now, the PROPERTY ( 'TcpIpAddresses' ) value was regarded as an important piece of evidence, but... apparently not.
Is the behavior the same for V16?
PS: Feel free to propose solutions to the "Am I connected to the right server?" problem... it is possible that one of them has NOT been tried in the past and shown to fail, and regardless, NO proposal will be mocked :)
asked 05 Jul '13, 05:52
In version 11, yes. When the server starts up, it creates a list of IP addresses it is listening on. This list never changes throughout the life of the server, and this list is where we get the addresses for this property. After a networking change, the server may continue to function normally and things like TCP and HTTP will probably work fine in most cases. However it's likely that certain features (finding the server through UDP broadcasting, for example) may not work depending on the network configuration.
In version 12, we changed the server to recognize network changes (i.e. changes to the list of available IP addresses) and so in v12 and later, the value of the property will change as IP addresses change. How fast the values are updated is dependent on the value of the "IP Address monitoring period" as set with the server's -xm switch.
answered 05 Jul '13, 09:09