bncslink32

V3BNCSLink

Introduction

This application allows a normal BNCS panel application to connect over a TCP connection (typically Intranet) to a FABIAN server.

It will also work to a slinkServer, but not with SSL.

This is a rewrite of the 16 bit application bncslink.exe that enabled a single BNCS client application (e.g. ApplCore) to connect to a FABIAN server. This new version is not a port but re-implementation - and in reworking it, multiple panels may be run.

It was originally designed to run with V3 ApplCore but works with other BNCS clients too.

Compatibility

This application has very similar functionality to the 16 bit application that precedes it, although this application was written from scratch there may be some minor differences to the original bncslink application.

Core Features

Whilst this application supports a normal BNCS client it is not CSI and so there may be some differences.

V3BNCSLink DOES support multiple clients unlike the V2 version.

A point to note is that registrations have to be aggregated into a single FABIAN registration so if you were to register one panel with slot 1, a second panel with slot 4096 the resulting registration to FABIAN would be the whole range 1-4096. Any revertives between 2-4095 would be sent across the link and ignored.

This application supports the following ApplCore commands:

Group | Commands
Infodriver | IW
Infodriver | IP
Infodriver | IL
GPI | GS
GPI | GP
GPI | GL
Router | RC
Router | RP
Router | RL
Database | RN
Database | RI
Database | DS
Cache | DG
Cache | DI

Note: this is not a complete list of all the commands that V3ApplCore supports but those that it would expect to go to CSI to provide services for.

Database Files

To keep the installation simple, the BNCS database files can be located in the working directory of the V3BNCLink application - or the path specified in the ini file. The databases are loaded on demand into memory (unlike the V2 version of this application which kept a compiled database file on disk).

Database files are kept up to date with those at the FABIAN server by normal database change notification but also are synchronised automatically at start up - this adds overhead on starting an application as the names are pulled from the FABIAN server.

It is recommended that only those database files that are required for your application are kept in the application directory so that only those actually used are kept synchronised with the server.

V1 database files are not supported - all databases must be DEV_nnn files, however this does not mean that you can't communicate with V1 devices. To use a V1 device create an appropriately dimensioned DEV_nnn.INI file and let the database synch'ing mechanism take care of updating the names in it.

A revertive registration is required to get CSI/FABIAN to pass on database change notifications, so to ensure that database files are always kept up to date regardless of the state of client registrations V3BNCSLink will by default keep index 4094 registered (deliberately not 4095/4096 because these are by loose convention used for message ping/pong). You may therefore see FABIAN server debug messages with registrations for slot 4094 at startup and if clients de-register with a device.

[Database]
Load=1
DatabaseFile_0=DEV_552.DB0
DatabaseFile_1=DEV_552.DB1
DatabaseFile_2=DEV_552.DB2
DatabaseFile_3=DEV_552.DB3
DatabaseFile_4=DEV_552.DB4
DatabaseFile_5=DEV_552.DB5
DatabaseFile_6=DEV_552.DB6
DatabaseFile_7=DEV_552.DB7
DatabaseFile_8=DEV_552.DB8
DatabaseFile_9=DEV_552.DB9
DatabaseSize_0=1152
DatabaseSize_1=1152
DatabaseSize_8=4096

The Load entry can be used to get bncslink to ignore the file when synch'ing databases (default is 1 - on)

Note the additional size parameter for database 8 - this is required for the synch mechanism to know how big this database is. You can include this for any of the databases (not normally required for 2 and above), and if not present will default to 4096

File structure

This application is designed as a lightweight install. All that is required to make it work is a single directory containing every file that is needed.

Unusually this means that the database files, that normally reside in the Windows directory are in the same directory as the application (or as specified in the configuration).

Custom controls should also be located in the application directory, as well as all of V3ApplCore dependencies, and the dependencies of this application (see below).

Custom Controls

For V3ApplCore custom controls have to be in the Windows directory - this is different to the V2 version of this application where the custom controls can reside solely in the application directory.

To keep the installation mechanism simple (i.e. simply copy one directory to the destination machine) this application automatically makes a copy of BNCS_CC.DLL and BNCS_CCxx.DLL from the application directory into Windows if one doesn't already exist in the Windows directory.

Support DLLs

V3BNCSLink requires Visual Studio 2013 runtimes (a Microsoft download) and the following support DLLs:

DLL | Description
qt-mt323.dll | Qt Runtime
bncsif32.dll | Inter-process communications (this is a new dependency from version 1.1.0.0)

ApplCore additionally requires the following DLLs:

DLL | Description
bncs_cc.dll | Base 32 bit custom controls
bncs_ccnn.dll | Additional 32 bit custom controls e.g. bncs_cc09.dll
bwcc32.dll | Borland Custom Controls

Configuration

There is a single configuration file for V3BNCSLink which resides in the working directory of the application.

Example:

[Login]
UserName=a
Password=b
ControlPass=c

[Panel]
Path=c:\v3\clients\v3acmd.EXE
DeviceWriteEnable=1,2,3,124,5

[Environment]
SetV4Environment=1
CC_ROOT=w:
CC_SYSTEM=v45_lite
CC_WORKSTATION=222

[Server]
Address=192.168.1.176
Port=23
AltAddress=127.0.0.1
AltPort=23

Description:

Section/Entry | Notes
[Login] | The FABIAN server credentials
UserName | All three of these parameters must be valid on the FABIAN server for this application to continue
Password |
ControlPass |
[Environment] | Optional section to set the environment of the panel run in the panel section
SetV4Environment=1 | Whether to try and set the environment - any non-zero value will enable this feature
CC_ROOT=w: | Same as CC_ROOT defined for V4 system
CC_SYSTEM=v45_lite | Same as CC_SYSTEM defined for V4 system
CC_WORKSTATION=222 | Same as CC_WORKSTATION defined for V4 system
[Panel] | Settings for the panel to run
Path | Either relative (to the working directory of this application) or absolute path to the V3ApplCore application to run when V3BNCSLink has successfully connected to the FABIAN server. Note for users of multiple panels: When this application is closed, V3BNCSLink will also close.
DeviceWriteEnable | Used to stop a client attempting to write to a FABIAN server devices for which it is not enabled. A value of: ALL passes every command to the FABIAN server (which has it's own security) otherwise this is a comma delimited list of devices to allow. A disabled device can still be polled, but the "Write" commands are blocked (e.g. IW, RC, GS, IL, RL, GL) and a line written to the V3BNCSLink status window.
[Server] | Where to connect to
Address | The IP address or name of the main FABIAN server to connect to
Port | IP port number associated with "Address"
AltAddress | An alternative IP address or name to connect to if the connection to the main FABIAN server is not available
AltPort | IP port number associated with "AltAddress"
[Cache] | Revertive cache - for bncslink this is entirely within memory not stored to disk
CacheEnable=1 | Similar setting to that used in CSI with similar effect

Installation

Is a matter of simply copying a single directory to the destination machine. I can however thoroughly recommend the use of InnoSetup to generate proper windows installer to help with generation of shortcuts etc. (http://www.jrsoftware.org/isinfo.php)

Connection

The connection to "the BNCS network" for a bncslink connected client is of course different to CSI's. The TCP connection back to the FABIAN server should be persistent - i.e. should just stay up and not randomly drop. However, either network issue or FABIAN server restarting would break that connection.

It's entirely possible that bncslink should try and reconnect the session (various drivers etc. already do this), however this is not usual for BNCS clients. Inherently they do not know what to do in such circumstances. They may have only been disconnected for a moment...or for a week....they have no real means of knowing what information has been missed.

The only course of action available at the moment is to restart the client - by simply closing and restarting. It may be worth at some point in the future automating this (close all the panels and relaunch from the beginning) - but disruption to the client applications is inevitable.

Developers Notes

This application is object oriented, many of the classes come from the stalled CSI rewrite project.

The basic structure of the application is shown below:

The messaging window knows nothing about the function of the fabianClient (and vice versa) only that it provides a certain interface (e.g. fabianClient has "infoWrite" as an available method, and the corresponding reply is "infoRevertive" which is implemented by the messaging window.

The connection between the modules uses Qt signals and slots though this could have been done using an abstract interface class. As it turns out the Qt method enables multiple connections to a single event (signal) that feature is used by the main V3BNCSLink application class to keep track of the database update functions.

Version

Version | Date | Author | Notes
1.0.0.x |  |  | initial beta versions
1.0.0.4 |  |  | fixes problem in multiple registration. Adds routermodify command
1.0.0.5 |  |  | adds CSI type bitwise registrations
1.0.0.6 |  |  | tidying. Takes version info from resources for about dialog. Moves bncs_ccxx.dlls if they are later locally making backup of old one in Windows. Sticks fix in that causes incoming parser to give up when receving RUT which has bonus NULL on the end (certainly in FBSERVER 1.11.06). Deletes client registrations if there is no TRUE response to send messsages
1.0.0.7 |  |  | Uses the common libraries and headers.
1.0.0.8 |  |  | adds gethostbyname function for addresses that do not contain periods. It was found that QSocket doesn't resolve local computer names. Note that fully qualified domain names are still sent direct to the QSocket call.
1.0.0.9 |  |  | Changes movefile to point at location in bncs_config file, also adds small amount of debugging if files don't exist
1.0.0.10 |  |  | ensures that there is a valid workstation number in csi.ini
1.0.0.11 |  |  | fixes flag used for registration add
1.0.0.12 |  |  | fixes database change notifications
1.0.0.13 |  |  | Integrates help
1.0.0.14 |  |  | always registers slot 4094 for any device for which we have a database, and any we've deregistered with to ensure database updates get through. Also updates database loading code to be consistent with CSI32. More vigorous checks of indexes on registration params
1.0.0.15 |  |  | Fix to CSI32 database loading code...oops. Didn't like single character database names. Also, adds database path to debug window so you can see where it's reading this stuff from
1.0.0.16 |  |  | fix to minIndex to not return zero as default
1.0.0.17 |  |  | rerelease just to include map file
1.0.0.18 |  |  | GREAT TWONK YATES - after much care to produce registration class it was using a 1-based array offset value rather than zero based resulting in an out of range array offset
1.0.0.19 |  |  | GREAT TWONK YATES (AGAIN) selective registration ended up in a never ending loop
1.1.0.0 | 18/11/2013 | DY | adds new section in the ini file to set the v4 environment for the incoming panel. Adds NEW DEPENDENCY of bncsif32.dll so that all messaging types can be accomodated. Changes from 4 digit to 3 digit version numbering and increments the minor revision (second digit) to indicate that there's significant change (the new requirement for bncsif32.dll). Adds revertive cache the same as tried in CSI using the "memory database" caching functions. This was the last major feature missing compared with CSI
1.1.1.0 | 21/11/2013 | DY | minor fixes to caching functions to make work properly
1.1.2.0 | 21/11/2013 | DY | fixes revertive types = IR and GR and RR are not the same format....
1.1.3.0 | 25/11/2013 | DY | fix to database name function which in the excitement I'd optimised to not work any more
1.1.4.0 | 25/11/2013 | DY | adds conditional synching of database entries. Adds ability to sync databases 2-9 in addition to 0 and 1
1.1.5.0 | 28/11/2013 | DY | now ensures that cache "I don't have it" value is the same as CSI's for cache and database calls - however they use different but very similar return values: cache uses "- - -" and database "---". This is of course crazy....and historical...and maddening.... Minor change too to the database functions to ensure a valid return value even if there's nothing cached - it was possible that the buffer wasn't being set to anything at all, not even null, if the entry didn't exist
1.1.6.0 | 05/12/2013 | DY | fix to uninitialised path variable in database functions
2.0.0.0 | 08/11/2018 | DY | Renamed V3BNCSLink (from v3bncslink). Built with VS2013. Docs to Markdown. Supports number of databases command. Uses current database/databaseMgr libraries
2.0.1.0 | 17/02/2020 | DY | Updates icon to current
2.0.2.0 | 07/12/2020 | DY | Database function signature changes (all now unsigned)
Build: bncs_4.7.5 5800 a1b48197a Atos|Syntel © 2021