The introduction of the Publish Subscribe Infrastructure (PSI) in v7 reduces the amount of network traffic in steady state, since IO updates are pushed through when they occur instead of being continuously polled. However there is some overhead when changing pages in setting up subscriptions to all of the tags required for that page.

  The stages involved in setting up a subscription are as follows:

1. Determine whether tag exists. A request is sent to the IOServer, asking whether the requested tag exists on that server.
2. Resolve tag. This is the process of finding the highest priority online source ('best offer') for a given tag. This tends to be an expensive (slow) operation, as all IOServers must be contacted. From this point on the IOServers will send notifications of units going on/offline.
3. Subscribe tag. Once the tag is resolved, the client subscribes to the best offer. From this point on, the IOServers will send notifications of all value changes for that tag.

  There are a number of steps that can be taken to try and reduce the effects of this issue:

1. One approach is to subscribe to all tags on startup. This is done by using startup cicode to iterate through the variables database and call TagSubscribe() on each individual tag at a slow rate (say 30s). This makes page changes quicker, because all tags are already subscribed so no additional work is necessary when changing pages. The down side of this approach is that the IOServer is having to read all tags from all devices every 30s, even if that tag is not actually being viewed at the time. In addition, a notification will be sent to each client every time a tag changes, even if that tag is not currently in use by that client. This is not likely to be appropriate in low-bandwidth situations, or where the possibility of overloading PLC's is a consideration.
2. As of v7.10SP2, a better approach is to call the new cicode function TagResolve() on each tag at startup. This has the effect of causing the clients to always be aware of which server is the best one to contact for which tag(s). This substantially reduces the amount time required to set up the subscription, as only step 3 above need be done. This may be appropriate for low-bandwidth situations, and does not create any load on PLC's.
3. In low bandwidth situations, it is especially important to tune the PSI to reduce the amount of overhead bandwidth required. This can be done by adjusting some parameters in the file Citect32.exe.config (located in the Citect\bin directory for v7.00 and the Citect\Config directory for v7.10+).
   • Uncomment the applicationSettings section. Do this by changing the line:
     
             <!-- Modify any of the following settings to change default behaviour
     
     to be
     
             <!-- Modify any of the following settings to change default behaviour-->
     
     And remove the --> at the end of the line:
     
             </Citect.Platform.Net.Session.Tcpip.Settings>-->
   • The IOServer and the client periodically send 'heartbeat' messages to each other, in order to ensure the connection is still alive. The period of these messages is controlled by the PingTime parameter. The default value is 1000 (i.e. 1s), meaning it will take up to 1s to recognise that an IOServer has gone offline. Each message corresponds to 82 bytes on the wire, which is insignificant on an ethernet network but may add up if running redundant multiprocess servers separated by a low bandwidth link, because each of the server processes (RAT) + client have their own connection to the IOServer on the other end. Thus the default heartbeat traffic for this setup would be 4 (connections) x 82 (bytes) x 8 (bits/byte) = 2.624kbps - a substantial proportion of a 33.3kbps or even 56kbps connection.
     
     In this case, increase the value of Pingtime until an appropriate compromise between background traffic and response times is found.
   • When checking for the existence of a tag, CitectSCADA will wait a period of time for a response before retrying. This period of time is controlled by the parameter ResolveRetryBackoff, and is according to the following formula:
     
        Time = ResolveRetryBackoff x RetryAttempt ^ 2
     
     RetryAttempt will increase until it is equal to 3 then stay at 3, so the maximum time between attempts to re-resolve tags wil be 9 x ResolveRetryBackoff.
     
     This is important for low-bandwidth situations, since on a page change (assuming that neither option 1 or 2 above has been implemented) or at startup (if they have been implemented) there is a burst of such requests, and it may take some time to get all the requests to the IOServer and the response back. If this time exceeds the ResolveRetryBackoff, all of the TagExistsRequests will be resent. To overcome this, monitor bandwidth utilisation on page change (or at startup, as appropriate) and you should be able to detect a spike of traffic. Measure the length of time for this spike, and increase the ResolveRetryBackoff until it is greater than this.
     
     The trade off for this change is that it will take up to 9 x ResolveRetryBackoff to detect that a new IOServer has started up.