slinkClientComponent

slink Client

Description

slinkClient connects to a slinkServer to present remote BNCS devices to a local network.

It connects via TCP/IP with optional SSL encryption.

The slink system follows the same general principles as FABIAN control system link.

slink has slightly different philosphy to FABIAN in that there is one slinkClient for each remote site. This is easier to understand, allows easier maintenance.

Redundancy Mastering

CSI32 introduced redundancy mastering (in CSI32 version 1.2.59) to allow for a single device to control the TxRx state of all it's siblings. slink relies on this to maintain consistency of all its drivers and to provide the redundancy mechanism for the link itself. Unlike FABIAN slink does not use, or require 'F' messages.

Configuration

There can be more than one slinkServer.exe applications for any one system - so there must be more than one configuration file.

There is a default file:

slinkClient_default.ini

but you can supply a command line parameter which is a profile name. So a command line of:

slinkClient myRemoteSystem

results in config being taken from:

slinkClient_myRemoteSystem.ini

Configuration files are located in the "system config" location appropriate for your system type alongside BNCS database files.

Option | Entry
[slink] Address=team.bncs.tv | This can be a dotted network address but for SSL to work should be the DNS name of the server which must match the SSL certificate
Port=2222 | TCP port number
SSL=1 | non-zero indicates the connection should be SSL
SocksAddress= SocksPort=0 SocksUser= SocksPassword= | This application may optionally use a SOCKS proxy so the connection may tunnel out. Set address and port and optional user credentials here
device_1=123 device_2=124,1 device_3= | BNCS device list. These are the BNCS devices that this link will create on the local network and will pass messages to/from the remote network
userName=A password=B controlPassword=C | Login credentials for the remote slinkServer

Debug/Diagnostics

It is a design decision that the application debugging is events only. If you want traffic level debugging then all of this is available using an external debugger.

The reasons for this are:

  • you actively have to run an external debugger if you want that level of detail (you can't just leave it enabled so ruining the performance of this application)
  • external debugger may have far better filtering/highlighting than is usually available on applications such as these
Copyright Atos 2012