The leak exists when Citect attempts to make an asynchronous connection to another Citect.

Due to the complicated issue of this problem it was necessary to develop a work-around. The following Citect ini parameter will enable the work-around:

[LAN]
ServerHeartbeat=1

It is important that this ini parameter is enabled on all machines on the network that will talk to each other using TCP/IP. Basically the Citect client will send a request to another particular Citect on the network asking if it supports the required server (i.e. report, alarm, trend, io). If the server responds within an allowed time (see below ini parameter "ServerHeartTimeout") then the Client will make a connection attempt to that Citect knowing that the attempt will be successful. Note: this system uses a cache so the actual timeout will not cause Citect to hang for the timeout each time a connection attempt is made. The table is kept updated by a background task (see below ini parameter "ServerHeartTime").

Further parameters:

[LAN]
ServerHeartTimeout=1
ServerHeartTime=10000

ServerHeartTimeout units are seconds. This is the time you would expect to get a response from a Citect server. 1 second would usually be sufficient on hard wired LAN. To determine if you would need to change this then you can simply use the Windows ping utility to determine how long the machine takes to respond on the network.

ServerHeartTime units are milli-seconds. This determines how often the Citect client will check all its configured servers. The default is once every ten seconds.

The traffic produced by this system is very low.

Citect has confirmed this to be a problem in CitectHMI/SCADA version 5.XX. We are researching this problem and will post new information here as it becomes available. The work-around is valid for CitectHMI/SCADA 5.50