To use sockets, a number of parameters must be set in the citect.ini file. These parameters are as follows.

[Lan]Tcpip=1 to enable, 0 to disable (default). The effect of setting this parameter is similar to adding another LanA number to the set Citect can use to communicate. On the client, it will initially try to establish connections using NetBIOS, and failing that will try sockets.

[Lan]NetBIOS=0 to disable, 1 to enable (default). The effect of resetting this parameter is to disable the NetBIOS interface in Citect, forcing the machine to use sockets, providing the previously mentioned [Lan]Tcpip parameter is set. Typically this parameter is left enabled on servers to allow clients using NetBIOS to connect if required. However it should be reset on clients to force them to use sockets, as aforementioned.

As mentioned above, Citect normally uses names for NetBIOS connectivity, with the operating system left to handle the issue of name resolution in the case of TCP/IP. The same could be done for sockets, but setting up a Domain Name Server was judged to be too steep a requirement for many small Citect systems, and an alternative was provided by way of a new [DNS] section in the citect.ini file. There are a number of ways of using the [DNS] section. These are explained below.

[DNS]Primary=<ip address>. This special case is for when the Citect servers are consolidated on one machine. That is, the I/O, Alarm, Trend and Report server are all on the same machine and therefore at the same address. Always insert the IP address (or name) of "this" RAT-IO server.

[DNS]Standby=<ip address>. This is the companion to the Primary parameter, providing for redundancy on simple systems. Always insert the IP address (or name) of the "other" RAT-IO server.

[DNS]<server name>=<ip address>. This is the general case providing for explicit resolution of a specific Citect name. For example, [DNS]CitectAlarm=192.168.0.12 is valid, providing the name/address combination is correct! The IOServer name used here must match that defined in the project, and the Citect server names should be constructed using [Client]Primary= and the Alarm, Trend and Report suffixes.

Alternatively, you can substitute a fully qualified domain name for the ip address, and then rely on the operating system facilities for resolution of such names. This may require establishment of a DNS server or hosts file. Since the connection is ultimately determined using the raw address, the names which the client use do not need to match the names registered on the server.

The use of Windows sockets affords programmers with certain functionality not available in NetBIOS. Specifically, it allows tuning of traffic management (see Q2533) which should mean that sockets offer better Citect performance on low bandwidth networks, if not across the board. Since not many systems widely use this method of connection, not a lot of hard performance information is available at this stage.

Regarding sockets, Citect's help mentions that "this version of TCP/IP has performance limitations and it must not be used for local LAN support. TCP/IP support should only be used when you are running your system over the Internet." These statements are no longer the case and are to be changed shortly. The are no known performance limitations (speed wise anyway - see below) and use over a LAN is encouraged.

Even though the use of sockets with Citect is now supported, that is not to say there are no drawbacks as compared to using NetBIOS. To begin with, the socket transmission model in Citect is not yet very sophisticated and is liable to block the main process (causing a client Citect hang) if the server stops responding. This has not been observed in every case but is currently acknowlegded as possible. Typical scenarios involve a hang or crash on the server causing some kind of dialog box to appear (like DrWatson or a Software Protection Failure). All connected clients hang until the Windows TCP/IP layer times out or the offending dialog box is closed on the server. This problem does not affect NetBIOS networking due to it's more mature buffering. It is possible that tweaks to timeout/retry registry entries in WinNT/2000 TCP/IP may moderate this effect. Work is continuing in this area to improve socket performance. Also, currently there is no way to give preference to a local IP address in the case of multihomed machines. So if the client has two network cards installed, it is not possible to give priority to one over the other when performing a send.