csi32

CSI32 Application Documentation

Please note: This is not a complete guide as to what BNCS is or what CSI does - but a reference for the CSI32 application.

Click on the lines below. Help is available for:

Item | Notes
Networking | What CSI does to talk to the network
Dependencies | Application Dependencies
Dialog | A guide to the dialog - what do all those counters mean?
Configuration | Those things you can set, shouldn't fiddle with, or were once able to but not now!
Logging | Those things that are logged...and where it's logged to
Internal Status Infodrivers | Internal status infodrivers (similar to "BNCSStat" or "V3Status") introduced in version 1.1.10
Packet Recovery | Information on the packet recovery features of CSI32 introduced in version 1.1.2
Interfacing | ...or rather no information on Interfacing (but at least the reason why)
Redundancy | Guide to redundancy messages
NetStatus | Guide to Network Status messages
Credits | Who's who
Version History | Full history of the application and its ancestors
Build: master 5408 9fbf68a25 Atos|Syntel © 2020


configuration

CSI Documentation

CSI32 Configuration

Introduction

Configuration is held in a conventional Windows "ini" file. The location and name of this file is different depending on the type of system in which CSI32 is deployed - this is a hang-over from the different versions of CSI from which CSI32 is derived.

The table that follows describes what the configuration file is called and where it is located - this list is in order of priority. i.e. if the V4 environment variables are present then this path will be used in preference to the V3 or V2 path.

System | File | Path
V4 | bncs_system.ini | %CC_ROOT%\%CC_SYSTEM%\config\system
V3 | csi.ini | ConfigPath specified in "c:\bncs_config.ini"
V2 | csi.ini | Windows directory (usually c:\windows for Windows XP or c:\winnt for Windows 2000)

Disabled Menus

From CSI32 v1.2.13 menus & keyboard shortcuts are disabled unless you have explicitly enabled them. See the dialog documentation.

Optimum csi.ini/bncs_system.ini file

The trouble is....with so many settings it's hard to define what's the "best config". Here's the (author's version of the) best settings: bncs_system.ini

Changing Configuration

CSI32 has a menu item (Config->EditConfig) to open the default editor for the "csi.ini" or "bncs_system.ini" file. Which file is opened is dependent upon the system type detected.

Configuration changes almost always require a restart of CSI32, though some parameters are available as menu items which may be changed on the fly without a restart and which also modify the appropriate configuration file.

Configuration Parameters Defined

Section / Entry / Default | Description
[Window] |
Xpos=0 | The last saved X position of the maximised CSI main dialog box. This is saved every time the dialog box is moved.
Ypos=0 | The last saved Y position of the maximised CSI main dialog box. This is saved every time the dialog box is moved.
[Network] |
Workstation=0 | The workstation number for this machine for V2/V3 systems. V4 based system have workstation number as an environment variable
DefaultAdapter=0 | Netbios adapter number
Channel=0 | Sets CSI to use the indicated channel. This can be used to isolate BNCS systems running on the same network. Channel numbers 0 to 99 are valid.
NetworkEnable=1 | 0 = CSI will run but not attach to the network. A loop back adapter is force on. 1 = CSI will attach to the network as usual. This is the default value.
CSIEnable=1 | Prevents CSI from operating. This is a security function manipulated by the Network Manager application
SessionEnable=1 | If set to 1 sessions are enabled. if set to 0 they are disabled. This item can be toggled from the CSI menu bar.
ClientEnable=1 | If set to 1 CSI will allocate network buffers for receiving revertive information and permit clients to connect to it. if set to 0 network control blocks are freed and clients are denied access This item can be toggled from the CSI menu bar.
DriverEnable=0 | If set to 1 CSI will allocate network buffers for receiving command information and permit drivers to connect to it. if set to 0 network control blocks are freed and drivers are denied access This item can be toggled from the CSI menu bar.
ClientBuffers=20 | The number of network control blocks to be assigned for revertive messages.
DriverBuffers=4 | The number of network control blocks to be assigned for command messages to drivers.
SessionBuffers=8 | The number of network control blocks to be set aside for session purposes
PktRecoveryBuffers=4 | The number of network control blocks to be set aside for packet recovery
 | Note: ClientBuffers + DriverBuffers + SessionBuffers + PktRecoveryBuffers should not exceed 30. The total is checked at startup and will flag an error if more than 30. This is a rudamentary check and can be fooled/bypassed if you enable features (e.g. sessions) from the menu items
SecBuffEnable=1 | REDUNDANT - CSI32 hasn't got (and doesn't need) secondary buffering.
TerBuffEnable=1 | REDUNDANT - CSI32 hasn't got (and doesn't need) secondary buffering.
LoopbackEnable=0 | If set to 1 it allows CSI to see revertives form its local machine if that machine has been detached from the network and as a consequence windows has disabled the network adapter.
HWMBufferFlush=1 | REDUNDANT - CSI32 hasn't got (and doesn't need) secondary buffering.
HWMCacheFlush=1 | REDUNDANT - CSI32 hasn't got (and doesn't need) secondary buffering.
DeafToSelf=0 | Allows CSI32 to be used as a gateway. It translates between different network protocols where you don't want to set up loops with this CSI re-transmitting its own messages
HangUpDelay=1500 | Session hang up delay timer (mS)
V1Compatibility=0 | If set to 0 it prevents CSI from sending V1 compatible message packets out by default. This cuts down the loading on the network if V1 messages are not used. V1 messages are not picked up on CapLog so you may not be aware of them being generated and hence loading your network. V1 packets will always be received and decoded if they are present on the network.
TempFilePath=C:\csi_temp | Setting not required from CSI32 1.2.76. The Windows temp path is used _except_ for temporary session files (reinstated in CSI 1.4.21). *Note* This value needs to be consistent between all machines on a system.
KeyFilePath= | Setting not required from CSI32 1.2.76
SendPacketSerialNumbers=0 | Whether to send "revertive" packet serial numbers.
SendCommandSerialNumbers=0 | Whether to send command packet serial numbers
ClearCacheOnNetClose=0 | Whether to clear the revertive cache on a driver closing (and sending NC message).
ClearCacheOnPacketError=0 | Whether to clear the cache if we detect that we've missed packets from a particular workstation and cannot rely on cached data for devices that workstation hosts.
DistributeBBC_NETTXRXSTATUS=1 | Whether to distribute the internal message BBC_NETTXRXSTATUS to all clients on reception of a network 'N' message. If you don't use this (ApplCore line 32400 handling) then turn it off. Distributing 'N' message notifications to all clients even if none are interested is inefficient. Even with this distribution disabled by this setting you can still selectively register using BBC_NETTXRXSTATUS_REG
DistributeBBC_NETMSGUPDATE=0 | Whether to distribute the internal message BBC_NETMSGUPDATE to all clients on reception of a network 'N' message. Distributing 'N' message notifications to all clients even if none are interested is inefficient. Since ApplCore doesn't use this the default is zero. Even with this distribution disabled by this setting you can still selectively register using BBC_NETMSGUPDATE_REG
HeartbeatEnable=0 | Whether to send heartbeat messages - heartbeats contain workstation information (uptime) and driver information (txrx state).
HeartbeatTimeout=60 | How often in seconds to send heartbeat messages. Heartbeats are sent both to clients and to drivers and this value is the total period to send to either. Messages sent to clients/drivers are interleaved so for a machine with clients and drivers enabled the effective period is half this value.
StatusChannelEnable=1 | Whether to send status channel messages - these are 6 packets/minute usually picked up by the BNCSSTAT application. If you don't use BNCSSTAT or are using heartbeat monitoring instead then you can disable status channel
DevIniMustExistForV2=0 | This controls whether the existence of a DEV_xxx.INI file controls the sending of commands. There's historical gotcha in that a missing DEV_.xxx.INI file for device xxx controls whether commands are sent in individual packets, or buffered and sent in as few packets as possible. The default for this setting is not backwards compatible but is optimised for best performance.
[Cache] |
CacheEnable=1 | If set to 1 then caching is enabled. If set to 0 it is disabled
CacheSize=8192 | This is the largest amount of RAM in KB that CSI will allow to be allocated for a cache. A value of 8192 permits all devices to be cached. A value of 1024 (the old default for this setting) only allows only 100 of the 999 devices possible to be cached.
CacheLife=10 | This is the life in minutes that the cache for a driver Id within CSI will remain valid without a "revertive" message being received for that Id. A value of zero sets cache life to be infinite (i.e. never expire).
CacheFilePath=C:\ | The InfoDriver cache is stored on the hard disk to conserve RAM. This parameter sets the path to the files
PeerPollRefresh= | This feature has been removed for reasons of efficiency, and this config key will be deleted from the config when csi32 is run
UseMemoryCache=1 | Whether infodriver cache is written to disk (UseMemoryCache=0) as it always was or stores infodriver revertives only in memory (UseMemoryCache=1)
[LogFile] | The facility was removed in version 1.16.07 when CapLog was introduced
LogFileEnable=0 | If set to '1' the logging function will be enabled the next time CSI is started
LogFile=C:\CSI_LOG.TXT | The path and filename to the log file
MaxLogFileSize=5 | This the maximum size in MB for the log file. If writing to the log file would cause the file size to be exceeded it will be closed and no further writes will take place
[TimeServer] |
TimeServerEnable=0 | If set to '1' the time server function will be enabled the next time CSI is started.
TimeServerPeriod=60 | This is the period in minutes between messages sent from the server to clients.
[Diagnostics] |
DiagMode=0 | If set to 1 then the CSI didialog boxields are enabled and will update once per second. If set to 0 the fields will be grayed out and will not update. This item can be toggled from the CSI menu bar.
DiagModeExtend=0 | If set to 1 then a lilist boxppears below the normal dialog box showing files waiting to be transferred to remote workstations. This item can be toggled from the CSI menu bar.
DebugMode=0 | If set to 1 then extra debugging information is sent to the console. This item can be toggled from the CSI menu bar.
[Misc] |
ClosedownDelay=0 | This delay (in seconds) will allow CSI time to close down cleanly. The CSI window will disappear immediately but CSI will still be active for the period set.
WatchDogComPort=0 | This tells CSI which port the BNCS WatchDog is attached to. The WatchDog is a piece of hardware made by BNCS that talks to CSI periodically, if CSI doesn't respond the WatchDog restarts the PC.
DisableWatchDogOnExit=0 | If set to 1 it prevents the Watchdog restarting the PC if CSI is closed down properly (Available from CSI version 1.20.09)
TxRxRetryPeriod=60 | This is CSI's background polling delay in seconds for devices on its machine. After the delay period set (default 60) CSI polls a device and if it responds CSI issues a NA message with the device number and the workstation number eg NA 800 041, device 800 is present on Workstation 41. Note that CSI cycles through its devices one per TxRXRetryPeriod. So for 10 devices and a period of '60' it will take 10 minutes to announce all devices. This is designed to keep network traffic down to a minimum. If a driver is shut down properly then it will be announced immediately.
MaxClients=1024 | The maximum number of clients used to restrict the number of ApplCore panels running to protect system resources
CompileHighOrderDBs=0 | Whether to read and create temporary cache files for the "upper" databases db2 to db9. This has no effect if UseMemoryDatabaseOnly is enabled
[SelectiveCache] |
Index_XXX=1 | Allows you to selectively turn the cache on (1) or off (0) for a given device number where XXX is the device number (between 1 and 999).
[PacketRecovery] |
TxRecoveryWindow=100 | How many messages this workstation should remember for possible retransmission
MaxRecoveryMessageHoldoff(ms)=2000 | Timer that runs to send packet recovery requests.
SimulateUnreliability=0 | The trouble with development networks is that they are too reliable for testing - this flag (and the following parameters) set CSI32 to be unreliable to prove packet recovery works (or not)
UnreliabilityTxRate=10 | How many packets to send without error
UnreliabilityTxCount=2 | The number of consecutive errors
UnreliabilityRxRate=11 | The number of packets to receive without error
UnreliabilityRxCount=2 | The number of consecutive receive errors
Enable=0 | Whether the packet recovery feature is enabled
MaxRecoveryRequests=5 | How many times to send packet recovery requests before giving up
RecoveryRequestRepeatRate(ms)=2000 | Minimum time between retrying packet recovery requests the initial request is sent within MaxRecoveryMessageHoldoff(mS)
MaxRecoveryPacketsPerTick=2 | Maximum number of recovery packets to send each timer tick (100mS)
[Status] |
DeviceInfodriverId=124 | Internal infodriver which delivers device status information to CSI clients. See information on Status Infodrivers
WorkstationInfodriverId=123 | Internal Infodriver which delivers workstation status information to CSI clients.
StartupDelay(secs)=61 | How long after CSI startup the internal infodrivers will display "starting". This value must be non-zero and should be the same as the longest HeartbeatTimeout setting (see above) on the system - typically 60 seconds (+1 ensures that there's no chance of coincident startup delay/heartbeat timer showing false status).
[Database] |
UseMemoryDatabaseOnly(no_V1_support)=0 | Whether to use alternative database functions that load database files into memory on the fly and do not require to either create, load, or use CDF files. There is no support for little used V1 database names With memory databases enabled "Router Index" (name to numerical index) is available on all levels With memory databases enabled you can have up to 65536 (0 to 65535) database levels
[WindowsMessaging] |
HWND_BROADCAST_NETSTATUSMSG=1 | Whether to broadcast BBC_NETSTATUSMSG messages when the network fails/returns. Turn this off unless you use it
HWND_BROADCAST_CSICLOSEWARNING=1 | Whether to broadcast BBC_CSICLOSEWARNING messages as CSI is closing. Turn this off unless you use it
HWND_BROADCAST_APPREADY=1 | Whether broadcast BBC_APPREADY messages when CSI has started. V3Launch requires this enabled - V4.x does not


Credits

Simon Dowson

The original versions of CSI, V2CSI, V2.5CSI, V3CSI and V4CSI.

David Yates

CSI32 - a merged V3CSI and V4CSI with other enhancements (such as this help).

This documentation was taken from the original material on the website by Simon, with additional material and corrections.


csi_client

CSI Client Interfacing

Description

Interfacing a client application to BNCS is achieved via CSI.EXE. Earlier versions of CSI could only support down to 24 clients but V3CSI/V4CSI/CSI32 can support up to 1024 clients. A client is an application that makes use of CSI for network device control and database services. ApplCore, General Switcher Host, NTP Host and Fabian are examples of existing clients. The basic interface methods have not changed since version 1.00.

The 'Client', 'User' or 'Front End' Interface is designed for creating either an alternative to an ApplCore panel or a complex application that requires BNCS services, i.e. control, communication or database services.

Note : Whenever your application receives a message from CSI it should return TRUE to indicate that it have processed the message. If CSI does not get a TRUE result then it will deregister you application

Using the CSI Client Interface

You should first send a BBC_GETHWNDCSI message to obtain the window handle to CSI. CSI will immediately return a BBC_HWNDCSI message with its handle. You then send a BBC_REGAPPLCORE message to register your client with CSI. CSI will check that there is room for you in its table and initialise the table elements to zero.

You can now register for revertives from all drivers and process those messages as you wish.

When your client application closes it should deregister with CSI.

Messages

BBC_REGAPPLCORE: WM_USER+1010

BBC_REGCLIENT: WM_USER+1010

BBC_REGCLIENT32: WM_USER+1030

Application to CSI
These messages are equivalent - the 32 suffix indicates a 32-bit client. The name first constant stems from the time when ApplCore was the only type of client. This message is a request by a client to register or de-register with CSI. It is necessary to register with CSI because, unlike an external driver hooking into an InfoDriver, CSI can support up to 32 seperate clients and it needs to know which one is which.

On receipt of this message CSI sets up a table ready to accept device registrations. <wParam> should contain your window handle. <lParam> should contain 1 if you wish register with CSI and 0 if you wish to Deregister. You application should deregister prior to closing down so that CSI does not try to send messages to a client that is no longer there.

BBC_TXRTRNETMSG : WM_USER+1100

Application to CSI
This is a message from a client asking CSI to transmit a router command over the network.

<wParam> holds the router driver ID you want the message sent to. If the MSB of <wParam> is 0 then the command is held in CSI's command buffer pending the next regular transmit event. If the MSB of <wParam> is 1 then the command is transmitted immediatly along with any already buffered commands. <lParam> is a long pointer to a string containing crosspoint command.

This string is in almost the same format as you would find in an ApplCore panel stringtable except that a mask field must be added followed by the workstation number. A typical string would look like this : RC 37 18 65 ',---' 36. This means route source 18 to destination 65 on router 37. This is not a message to a virtual router driver or packager so the mask is a dummy (',---'). The final parameter is 36 which is the workstation number originating the command. This allows the router to disregard the command if the workstation originating it is not a valid user.

This command can be used for router crosspoint, router lock, router poll etc.

BBC_TXGPINETMSG : WM_USER+1110

Application to CSI
This is a message from a client asking CSI to transmit a GPI command over the network.

<wParam> holds the GPI driver ID you want the message sent to. If the MSB of <wParam> is 0 then the command is held in CSI's command buffer pending the next regular transmit event. If the MSB of <wParam> is 1 then the command is transmitted immediatly along with any already buffered commands.
<lParam> is a long pointer to a string containing the GPI command data.

This string is in almost the same format as you would find in an ApplCore panel stringtable the workstation number must be added. A typical string would look like this : GS 101 14 1 36. This means workstation 36 is asking to switch output 14 on.

BBC_TXINFONETMSG : WM_USER+1120

Application to CSI
This is a message from a client asking CSI to transmit a an InfoDriver command over the network.

<wParam> holds the InfoDriver ID you want the message sent to. If the MSB of <wParam> is 0 then the command is held in CSI's command buffer pending the next regular transmit event. If the MSB of <wParam> is 1 then the command is transmitted immediately along with any already buffered commands.
<lParam> is a long pointer to a string containing the command+data string.

This string is in almost the same format as you would find in an ApplCore panel stringtable the workstation number must be added. A typical string would look like this : IW 101 'Hello' 12 36. This means workstation 36 is asking to put the string 'Hello' into slot 12.

BBC_GETMAXDATABASES: WM_BNCS+91

Application to CSI
Returns the maximum number of databases that CSI can load. Neither lParam or wParam are used.

Value is 10 for legacy file-cached databases
Value is 65536 with memory-only databases enabled

BBC_GETDBASENAME : WM_USER+1140

Application to CSI
This is a message from a client asking CSI for a database name.

<wParam> should be zero.
<lParam> should be a long pointer to a structure as follows :-

union dbname
{
    struct
    {
        WORD wRouter;
        WORD wSwitch;
        WORD wIndex;
    } key;
    char value[ 256 ];
};

wRouter is the router ID. wSwitch is 0 for a source and 1 for a destination. wIndex is the index number. Immediatley after the SendMessage() <lParam> will be a long pointer to the string containing the database name. If any of the parameters are invalid then the string returned will be '---'. The block of memory containing the structure should be large enough to contain the database string returned. i.e. at least 16 bytes. CSI's memory databases (from version 1.1.15) require a return buffer length of 255 for all 10 databases.

BBC_GETDBASENAME_32 : WM_BNCS+701

Application to CSI

32-bit version of BBC_GETDBASENAME. For full compatibility, you should use BBC_GETDBASENAME up to the limits of that message (65535 devices/databases/dests). You can however use this call to retrieve longer names than BBC_GETDBASENAME.

<wParam> should be zero.
<lParam> should be a long pointer to a structure as follows :-

// defined in bncsdef.h
typedef struct
{
    unsigned int uRouter;
    unsigned int uSwitch;
    unsigned int uIndex;
    unsigned int uLen;      // length of the buffer that follows
    const char* name;
} BBC_GETDBASENAME_32_STRUCT, *PBBC_GETDBASENAME_32_STRUCT;

Note: This structure is different to the one used for BBC_GETDBASENAME in the following respects:

  • it's not a union between input parameters and output name
  • the buffer length is supplied in the call so that long names may be passed

BBC_GETDBASEINDEX : WM_USER+1141

Application to CSI
This is a message from a client asking CSI for a database index. <wParam> holds the router number. Setting the MSB to 0 indicates a source index is being requested, a 1 means a destination. <lParam> is a long pointer to a string containing the name to be looked up. The value returned by SendMessage is the index number, or zero if the name could not be found.

BBC_GETDBASEINDEXEXT: WM_USER+1142

Application to CSI
This is a message from a client asking CSI for a database index for the upper databases (2-9). <wParam> is not used. <lParam> contains a pointer to the following structure:

struct Data
{
    WORD wRouter;
    WORD wDatabase;
    WORD wCaseFlag;
    WORD wModeFlag;
    char szStr[ 256 ];
}

if wCaseFlag is non-zero then a case insensitive search is performed.

if wModeFlag is non-zero then any part of the string that matches will return the index.

szStr buffer contains the name

The function returns the index or -1 if the entry was not found

BBC_GETDBASEINDEXEXT_32: WM_BNCS+705

Application to CSI

32-bit version of BBC_GETDBASEINDEXEXT. For full compatibility, you should use BBC_GETDBASEINDEXEXT up to the limits of that message (65535 devices/databases).

<wParam> is not used. <lParam> contains a pointer to the following structure:

// defined in bncsdef.h
typedef struct
{
    unsigned int uDevice;
    unsigned int uDatabase;
    unsigned int uCaseFlag;
    unsigned int uModeFlag;
    unsigned int uLen;
    char *szName;
} BBC_GETDBASEINDEXEXT_32_STRUCT, *PBBC_GETDBASEINDEXEXT_32_STRUCT;

if wCaseFlag is non-zero then a case insensitive search is performed.

if wModeFlag is non-zero then any part of the string that matches will return the index.

szName buffer contains the name

The function returns the index or -1 if the entry was not found

BBC_CLEARDATABASECACHE : WM_USER+1143

Application to CSI
If using memory databases this is a request to flush all or specific databases. <wParam> contains the device number to flush or zero for all. <lParam> is not used.

BBC_DATABASECHANGE : WM_USER+1150

CSI to application
This is a message from CSI to a client to say that an entry in the database has changed. <wParam> holds the router ID. The HIWORD of <lParam> is 0 for a source and 1 for a destination. The LOWORD of <lParam> is the index number. The copy of the database that CSI holds in memory has already been updated by this stage and so you can use this information immediately to retrieve the new source or destination name.

BBC_DATABASECHANGE_32 : WM_BNCS+702

CSI to application
This is a message from CSI to a client to say that an entry in the database has changed. This message supports 32 bit indicies. This message is sent only for values outside the range supported by BBC_DATABASECHANGE (any values >65535)

<wParam> is not used. <lParam> is a pointer to the following structure:

// this is defined in bncsdef.h
typedef struct
{
    unsigned int uDevice;
    unsigned int uIndex;
    unsigned int uDatabase;
} BBC_DATABASECHANGE_32_STRUCT, *PBBC_DATABASECHANGE_32_STRUCT;

BBC_RXRTRNETMSG : WM_USER+1200

CSI to application
This is revertive router message via CSI to client applications.

<wParam> is zero. but from CSI32 1.2.60 <wParam> contains the target workstation number. Practically this means either zero for change of state, or the originator's workstation's number. For poll responses satisfied out of the cache this means this workstation.
<lParam> is a long pointer to a string of the form : -

RR Router% Destination% SourceIndex% SourceName$

eg:

RR 37 53 22 'Studio B'

This message says that destination 53 on router 37 is now source 22 which is 'Studio B'. You should return 'TRUE' to indicate that you have succesfully processed this message otherwise CSI will delete your registrations.

BBC_RXGPINETMSG : WM_USER+1210

CSI to application
This is revertive GPI message via CSI to client applications.

<wParam> is zero. but from CSI32 1.2.60 <wParam> contains the target workstation number. Practically this means either zero for change of state, or the originator's workstation's number. For poll responses satisfied out of the cache this means this workstation.
<lParam> is a long pointer to a string of the form : -

GR GPI_ID% Index% State% State$

eg.

GR 153 67 1 '1'

This message says that index 67 on GPI driver 153 is now a 1. The reason that the same state information appears twice is because in ApplCore panels the first state goes into S% and the second state goes in S$. You should return 'TRUE' to indicate that you have succesfully processed this message otherwise CSI will delete your registrations.

BBC_RXINFONETMSG : WM_USER+1220

CSI to application
This is a revertive InfoDriver message via CSI to client applications.

<wParam> is zero. but from CSI32 1.2.60 <wParam> contains the target workstation number. Practically this means either zero for change of state, or the originator's workstation's number. For poll responses satisfied out of the cache this means this workstation.
<lParam> is a long pointer to a string of the form : -

IR InfoDriver% Index% Slot% Slot$

eg:

IR 121 15 15 'Haydock Park'

This message says that slot 15 on InfoDriver 121 is now a 'Haydock Park'. For this message the index number is always the same as the slot number. You should return 'TRUE' to indicate that you have succesfully processed this message otherwise CSI will delete your registrations.

BBC_REGDEVICE : WM_USER+1250

Application to CSI
This is a message from a client to CSI wishing to register for revertives from a network driver.

This message supports driver id up to 32767

<wParam> should be the handle of your client application.
<lParam> should be a long pointer to a structure as follows :-

// defined in bncsdef.h
typedef struct
{
    WORD wDevice;
    WORD wMin;
    WORD wMax;
} BBC_REGDEVICE_STRUCT, *PBBC_REGDEVICE_STRUCT;

wDevice is the driver you are interested in and wMin and wMax is the index range for which you want revertive messages, as described above, to be sent to your client. Successive registrations will overwrite previous ones.

Note : CSI 1.16.00, ApplCore 1.19.00 & ApplCore 2.00.06 have the ability to do selective registrations. When the data structure above is used as described above successive registrations will continue to overwrite previous ones. If the MSB of wDevice is set then the new registration will be added to any existing registrations. In this way discrete registrations can be built up without having to register a large min/max range.

BBC_REGDEVICE_32 : WM_BNCS+703

Application to CSI
This is a message from a client to CSI wishing to register for revertives from a network driver.

32-bit version of BBC_REGDEVICE. For full compatibility, you should use BBC_REGDEVICE up to the limits of that message (65535 devices/dests).

<wParam> should be the handle of your client application.
<lParam> should be a long pointer to a structure as follows :-

// defined in bncsdef.h
typedef struct
{
    unsigned int uDevice;
    unsigned int uMin;
    unsigned int uMax;
    unsigned int uFlags;
} BBC_REGDEVICE_32_STRUCT, *PBBC_REGDEVICE_32_STRUCT;

uDevice is the driver you are interested in and uMin and uMax is the index range for which you want revertive messages, as described above, to be sent to your client. Successive registrations will overwrite previous ones.

(uFlags & 0x01) is true if the registration is to be added.

BBC_UNREGDEVICE : WM_USER+1251

Application to CSI
This is a message from a client to CSI wishing to deregister with a network driver.

<wParam> should be the handle of your client application.
If <lParam> is 0 then CSI will delete all registrations fior your client. If <lParam> is a valid device number then the full range of registrations for that device will be deleted.

BBC_UNREGDEVICERANGE: WM_USER+1252

BBC_UNREGDEVICERANGE_32: WM_BNCS+704

Application to CSI
This is a similar message BBC_UNREGDEVICE and is from a client to CSI wishing to deregister with a network driver.

For full compatibility, you should use BBC_UNREGDEVICERANGE up to the limits of that message (65535 devices/dests).

<wParam> should be the handle of your client application.
If <lParam> is 0 then CSI will delete all registrations fior your client. If <lParam> is not 0 it should be a long pointer to a structure as follows (choose the appropriately named structure for the message you're using):-

// defined in bncsdef.h

// for message: BBC_UNREGDEVICERANGE
typedef struct
{
    WORD wDevice;
    WORD wMin;
    WORD wMax;
} BBC_UNREGDEVICERANGE_STRUCT, *PBBC_UNREGDEVICERANGE_STRUCT;

// for message: BBC_UNREGDEVICERANGE_32
typedef struct
{
    unsigned int uDevice;
    unsigned int uMin;
    unsigned int uMax;
} BBC_UNREGDEVICERANGE_32_STRUCT, *PBBC_UNREGDEVICERANGE_32_STRUCT;

Only registrations between the min/max range will be deleted.

BBC_DEVCONNECT : WM_USER+1170

Application to CSI
Message from client to CSI requesting session connection with remote device driver. Not yet implemented.

BBC_DEVDISCONNECT : WM_USER+1171

Application to CSI
Message from client to CSI requesting to drop connection with remote device driver. Not yet implemented.

BBC_DEVWRITE : WM_USER+1172

Application to CSI
Message from client to CSI requesting to write on the session to remote device driver. Not yet implemented.

BBC_DEVREAD : WM_USER+1173

Application to CSI
Message from client to CSI requesting to read on the session with remote device driver. Not yet implemented.

BBC_CACHESWITCH : WM_USER+1012

Application to CSI
Message from client to CSI to switch its cache on or off.

If <wParam> is 0 the cache will be turned off. If <wParam> is 1 then the cache will be turned on.
<lParam> should be 0.

BBC_CACHETEST : WM_USER+1013

Application to CSI
Message from client to CSI asking if the cache is valid between a range of indices for a device.

<wParam> should be set to the device number.
The LOWORD of <lParam> should be set to the minimum of the desired range and the HIWORD set to the maximum. The return value will be a 1 is the cache between the minimum and maximum indices is valid, otherwise it will be zero.

BBC_CACHETEST_32 : WM_USER+1013

Application to CSI
Message from client to CSI asking if the cache is valid between a range of indices for a device.

For full compatibility you should use BBC_CACHETEST up to the limits of that message ()

<wParam> is unused.
<lParam> should be a pointer to a structure of the format:

// defined in bncsdef.h
typedef struct
{
    unsigned int uDevice;
    unsigned int uStart;
    unsigned int uEnd;
} BBC_CACHETEST_32_STRUCT, *PBBC_CACHETEST_32_STRUCT;

The return value will be a 1 is the cache between the minimum and maximum indices is valid for the given device, otherwise it will be zero.

BBC_CACHEFLUSH : WM_USER+1014

Application to CSI
Message from client to CSI asking it to flush the cache.

<wParam> should be set to the device number of the cache you want to flush.
<lParam> should be zero.

BBC_QUERYCACHEMODE : WM_USER+1016

Application to CSI
Message from a client to CSI asking if cache is on or off.

<wParam> and <lParam> should be zero.

The SendMessage() will return 1 if the cache is turned on and 0 if it is turned off.

BBC_GETCACHEDDATA : WM_USER+1145

Application to CSI
Message from client to CSI requesting the cached contents of a given index. <wParam> should be 0. <lParam> should be a long pointer to a string containing the request of the form : -

DG <Dev%> <Index%>

The contents of the index will be a string pointed to by the long pointer. You should copy this data immediately as the pointer will not stay valid indefinitely.

The return value of the string if the cache is not valid is "- - -". Note: that this is similar but not the same as the unknown database entry return (this entry has spaces).

BBC_GETCACHEDINDEX : WM_USER+1146

Application to CSI
Message from client to CSI requesting a search for a string within a given index range.

<wParam> should be 0.
<lParam> should be a long pointer to a string containing the request of the form : -

DI <Dev%> <Min%> <Max%> <Var$>

where is the string to be searched for. The SendMessage() will return the index number is the string is found, otherwise it will return 0.

BBC_NETTXRXSTATUS: WM_USER+1139

CSI to application
Message from CSI to every client informing of current driver status as generated from the 'N' series messages.

<wParam> contains the driver number.
The LOWORD of <lParam> contains the state, and the HIWORD of <lParam> contains the workstation originating the message. State is one of the following values: IFMODE_RXONLYBROKEN (5), IFMODE_NONE (0), IFMODE_TXRX (2) or IFMODE_RXONLY ((1).

Note: 'N' message monitoring can have a very long cycle time and is superseded by CSI32 heartbeat messaging.

BBC_NETTXRXSTATUS_REG: WM_BNCS+73

Application to CSI
Optional registration for unicast delivery of BBC_NETTXRXSTATUS messages. From CSI32 version 1.2.5 whether BBC_NETTXRXSTATUS is broadcast to all clients is controlled by ini file flag:

[Network]
DistributeBBC_NETTXRXSTATUS=0

if you want only specific applications to get BBC_NETTXRXSTATUS notifications then use this registration and disable every-client registration with the above setting.

<wParam> contains the window handle of the application to receive notifications.
<lParam> is not used.
Return value is not used.

Note: 'N' message monitoring can have a very long cycle time and is superseded by CSI32 heartbeat messaging.

BBC_NETTXRXSTATUS_UNREG: WM_BNCS+74

Application to CSI
Deregister client previously registered with BBC_NETTXRXSTATUS_REG.

<wParam> contains the window handle of the application. <lParam> is not used. Return value is not used.

Note: 'N' message monitoring can have a very long cycle time and is superseded by CSI32 heartbeat messaging.

BBC_GETCLIENTREGEXTENT: WM_BNCS+80

Application to CSI
Message to CSI requesting extent of registrations for the given device. This is the overall extent of the registrations aggregated from all the client registrations that CSI holds. <wParam> has the device number. <lParam> is not used. LOWORD of the return value contains the minimum index registered, HIWORD of the return value contains the maximum index registered. No 32 bit IPC is used or necessary for this call. This message was implemented in CSI32 v1.0.24.xx

BBC_SENDQUEUEDCOMMANDS: WM_BNCS+85

Application to CSI
Force immediate send of queued commands (rather than waiting or setting flag on last command)

<wParam>, <lParam> and return value are not used.

BBC_CONFIGCHANGE_REG: (WM_BNCS+89)

Application to CSI
Register this already registered CSI client to receive raw config change messages.

This message was introduced in CSI 1.2.41

BBC_CONFIGCHANGE_UNREG: (WM_BNCS+90)

Application to CSI
De-register this client for raw config change messages. <wParam> contains the HWND of the window to de-register

This message was introduced in CSI 1.2.41

BBC_CONFIGCHANGE_NOTIFY: (WM_BNCS+87)

CSI to application
Notification from CSI that a config change message has been received. <lParam> a pointer to the string that contains the message, <wParam> is the length of the data. Max size for this message is 509 bytes (max packet size minus three bytes header)

This message was introduced in CSI 1.2.41

BBC_CONFIGCHANGE_REQUEST: (WM_BNCS+88)

Application to CSI
Asking CSI to send a config change message. <lParam> a pointer to the string that contains the message, <wParam> is the length of the data. Max size for this message is 509 bytes (max packet size minus three bytes header)

This message was introduced in CSI 1.2.41


csi_driver

CSI Driver Interfacing

Overview

A driver is an application that drives a piece of equipment or provides a service of some kind.

A driver application can register as many device driver ID's as it likes. There can be a maximum of 999 device drivers in any one BNCS cluster. A singe instance of CSI could theoretically host 999 single driver applications on a single machine, memory and other resources permitting. Alternatively CSI could host host a single application that registered all 999 ID's. This isn't a remotely likely scenario, but does stress the flexibility of having multiple device drivers in a single driver application.

Using CSI Device Driver Interface

The first thing a driver application should do is check for the presence of CSI by sending a BBC_GETHWNDCSI message as described in General Interfacing. If you do not immediately receive a BBC_HWNDCSI message then CSI is not present and the driver should announce that it cannot continue and closedown. If CSI is present then the driver will now be in posession of CSI's handle which is used for all future communication.

Registering a Device Id

The next step is for the driver to register one or more device ID's that it wishes to use. To register each Id the driver should send CSI a BBC_REGDEVICEID message. A succesful return means that the Id was not already registered by another driver running on the same workstation. CSI then sends out a message across the network asking if any other CSI in the system has the requested Id registered on their work stations. If the Id is in use elsewhere the driver will receive a BBC_DEVICEIDINUSE message. The driver should take this to mean that its request to register the Id has been refused.

Receiving Device Messages

When a client send a message to a device Id that the the driver has succesfully registered with CSI the driver will receive a BBC_CLIENTMSG. The message is in the form of long pointer to a string containing the message.

Sending Revertive Messages

Depending upon the type of message that the driver has received there are two types of revertive message that a driver may use to respond. If the driver is reponding to a message that has changed the state of device or altered stored information that all workstations should be informed about then the driver should send a BBC_DEVDRVREVMSG. If the driver is responding to a poll request then it should send as many BBC_DEVDRVPOLLMSG as is necessary to satisfy the request. CSI handles 'state change revertives' and 'poll revertives' differently.

State Change Revertives

These are sent as group messages to all CSIs in the cluster. Version 1.00 of BNCS used this mechanism for all messages and each message was sent in a seperate network packet. Version 2.00 improves on this by buffering as many messages as possible into a single packet. If your driver sends many 'change of state' revertives using BBC_DEVDRVREVMSG then CSI will bundle as many into a packet as it can providing the MSB of wParam is set to 0. For a GRD that's about 20+ in one packet whereas under V1.0 that would have been 20+ packets! If the MSB of wParam is set to 1 all messages will be sent immediatley in seperate packets. Where possible let CSI buffer them and send them out on a timer.

Poll Revertives

These are sent by the CSI on the workstation hosting the driver applicaction establishing a session with the CSI application on the workstation that originated the poll request. The session is a private channel between the two CSIs. Messages sent on this session are independent of the group message mechanism. When your driver receives a poll request it should send as many BBC_DEVDRVPOLLMSG messages as it needs to satisfy the request. CSI creates a spool file and queues the revertives there. The MSB of wParam must be 0 for all the messages except the last one. The final message should have the MSB of wParam set to 1. This is a signal to CSI to close the spool file, open a session with the workstation that requested the poll and send the spool file. At the receiving workstation the spool file is read in and stored until the session is closed. When the session closes the spool file is dismantled and revertives cached and sent on to the client.

Unregistering a Device Id

When a driver application wishes to closedown or perhaps just become temporarily unavailable to clients network it should send a BBC_UNREGDEVICEID message for each device Id.

Rejecting Duplicate Ids

Once your driver has succesfully registered a device Id with CSI, without receiving any objections from duplicate Id's elsewhere, then CSI must be able to object on your drivers behalf should another driver attempt to register the same Id. If CSI receives a request querying wether an Id is in use then CSI will send your driver a BBC_IDGETTXRXMODE message. If your driver is in TX/RX mode for this device Id then CSI will send an objection back to the network. If your driver is not in TX/RX mode then CSI will not object.

Closing down a Driver

When a driver application closes it need only send a BBC_DEVDRVCLOSE message to CSI. This will deregister all device Id's for the driver. There is no need to send individual BBC_UNREGDEVICEID messages.

Redundancy Commands/Messages

These are defined elsewhere along with how the redundancy mechanism works

Messages

BBC_REGDEVICEID : WM_USER+1160 (WM_COPYDATA)

BBC_REGDEVICEID32: WM_USER+1169 (BBC_COPYDATA)

BBC_REGDEVICEID32_32: WM_BNCS+707 (BBC_COPYDATA)

Application->CSI
This is a request from a device driver to register for the exclusive use of a unique driver Id number.

<wParam> should contain the handle of the drivers windows that you wish to receive all messages to be processed for the device Id.
<lParam> should contain the device Id that you wish to register.

For BBC_REGDEVICEID and BBC_REGDEVICEID32 lParam is limited to 15 bits (32767) because of historic use of the top bit. Driver id larger than this should use BBC_REGDEVICEID32_32

The return value from the SendMessage() call will be one of the following :-

0 = Success - CSI has accepted request.
1 = Request refused - ID supplied is invalid.
2 = Request refused - Device ID is already running on this workstation.
3 = Request refused - CSI has not been enabled in Driver Mode.

The caller may subsequently receive a BBC_DEVICEIDINUSE message if the Id is in use elsewhere on the network.

BBC_UNREGDEVICEID : WM_USER+1161

Application->CSI
Message from Device Driver to CSI unregistering a device.

<wParam> should contain the handle that the driver used to register the Id
<lParam> should contain the device Id that you wish to unregister.

The return value from the SendMessage() call will be 1if the id was succesfully unregistered. It will be 0 if the Id was not registered in the first place or was registered by another driver.

BBC_DEVDRVCLOSE : WM_USER+1162

Application->CSI
Message from Device Driver to CSI saying its closing down.

<wParam> should contain the window handle of the driver that is closing down

CSI will delete all registrations for devices owned by the window handle of the caller.

BBC_DEVDRVREVMSG : WM_USER+1163

Application->CSI
Revertive message from Device Driver to CSI carrying update revertive.

<wParam> should contain the workstation number of the client that made state change request
<lParam> should be a loing pointer to the message to be sent.

The message should be a string of the form

RR <DevId> <Dest> <Source>
GR <DevId> <I/ONum> <0/1>
IR <DevId <Slot> <Data$>

For InfoDriver revertivesif the parameter contains spaces it sholuld enclosed in single quotes eg. IR 123 44 'Hello World'

BBC_DEVDRVPOLLMSG : WM_USER+1164

Application->CSI
Revertive message from Device Driver to CSI carrying result of a poll request.

<wParam> should contain the workstation number of the client that made the poll request. If the driver is sending a number of poll revertives it should set the MSB of wParam on the last message to indicate that the poll is complete.
<lParam> should be a long pointer to the message to be sent.

The message should be a string of the form:

RR <DevId> <Dest> <Source>
GR <DevId> <I/ONum> <0/1>
IR <DevId <Slot> <Data$>

For InfoDriver revertives if the parameter contains spaces it sholuld enclosed in single quotes eg.

IR 123 44 'Hello World'

BBC_CLIENTMSG : WM_USER+1165

CSI->application
A message from CSI to a driver delivering a message from a client.

<wParam> contains the workstation number
<lParam> is a long pointer to a string containing the message.

BBC_DEVICEIDINUSE : WM_USER+1166

CSI->application
Message from CSI to a driver saying that a device ID is already in use on another workstation somewhere within the BNCS cluster on the network.

<wParam> contains the workstation on which this device driver is already running
<lParam> contains the device ID.

BBC_SESSIONREQUEST : WM_USER+1180

Client message via CSI to a driver requesting a session dialogue. Not yet implemented

BBC_SESSIONCLOSE : WM_USER+1181

Driver message to CSI requesting closure a session. Details to follow. Not yet implemented

BBC_DATABASEPOLL:WM_USER+1153

Message from CSI to driver indicating that the driver should generate a revertive dump of its entire table of data.

<wParam> contains the device Id for which the dump is required so that drivers that respond to multiple ID's can filter the request.
Later versions have <lParam> as the value of the "tally dump" RM command parameter - this has a value of 1 if a dump of all tallies is required, or 2 if only a dump of tallies for destinations that have the source selected for the source name that is changing.

BBC_SENDQUEUEDREVERTIVES: WM_BNCS+86

Application->CSI
Force immediate send of queued commands (rather than waiting or setting flag on last command)

<wParam>, <lParam> and return value are not used.

BBC_SETREDUNDANCYMASTER: WM_BNCS+92

Application->CSI
From CSI32 1.2.59. Some drivers present themselves as multiple BNCS devices - this is an API to allow an app to set only one of a group of devices to negotiate and set redundancy state. This reduces cycle time and ensures within CSI that TxRx state is consistent with a group of devices - when the master changes state, all those set with that as the master change state too. You need to supply the handle of the driver you wish to set the redundancy state for.

masterDevice = HIWORD( lParam );
slaveDevice = LOWORD( lParam );
HWND hDriver = (HWND) wParam

Return value is the master device if successful or -1 on failure

BBC_SETREDUNDANCYMASTER_32: WM_BNCS+708

Application->CSI

32 bit version of BBC_SETREDUNDANCYMASTER. For full compatibility, you should use BBC_SETREDUNDANCYMASTER up to the limits of that message (65535 devices).

<wParam> is the window of the driver, <lParam> is a pointer to the following structure:

// defined in bncsdef.h
typedef struct
{
    unsigned int uMasterDevice;
    unsigned int uSlaveDevice;
} BBC_SETREDUNDANCYMASTER_32_STRUCT, *PBBC_SETREDUNDANCYMASTER_32_STRUCT;

Return value is the master device if successful or -1 on failure


csi_general

CSI - General Interfacing Notes

Description

There are messages common to both the Client and Driver Interface. These are used to retrieve the handle to CSI for use in all further messages and for CSI to announce that it is closing down.

The constants are defined (for C/C++) in bbc_mxc.h

BBC_GETHWNDCSI : WM_USER+1007

Application to CSI
This is a local broadcast from your client asking CSI for its main window handle. <wParam> should contain your own client applications window handle or the handle of a window containing the message queue that CSI should use to communicate with your client from now on. <lParam> is ignored. CSI, if present, will synchronously return its handle in a BBC_HWNDCSI message before this message returns. This message can be used just for detecting the presence of CSI without taking up space in CSIs client table. The return value is not used.

Note: this value is sent using 32 bit IPC (both WM_COPYDATA and BBC_COPYDATA mechanisms)

BBC_GETHWNDCSI32 : WM_BNCS+1

Application to CSI
Same function/parameters as BBC_GETHWNDCSI but different message constand. This value is sent directly not via 32 bit IPC.

It is not recommended to use this - HWND_BROADCAST has to pass via every top level window and if any of them sit on it then BNCS applications can stall.

BBC_HWNDCSI : WM_USER+1008

CSI to application
This is a message from CSI to your client returning its main window handle in <wParam>. <lParam> is zero. The return value is not used.

BBC_GETCSIVERSION : WM_USER+1011

Application to CSI
Message from a client to CSI requesting a version number which is the return value. For CSI32 the values returned depends on the detected environment. For V3 (no environment variables) the return value is 0x03000000, for V4 it's 0x04000000.

This messages is slightly misnamed - system version not CSI version.

BBC_GETDEVPROPERTIES : WM_USER+1017

Application to CSI
Message from to CSI asking for device properties. <wParam> should hold the Id of the device being queried. <lParam> should be a long pointer to a string which will contain the information when the SendMessage() returns.

The information is a space delimited list of the form :

<Device Number> <Version> <Device Type> <Number of Sources> <Number of Dests> <database level list>

For V2 devices, device type is unknown so will return zero

BBC_CSICLOSING : WM_USER+1151

CSI to application
Signal from CSI to clients and drivers that it is closing down. Client and driver applications should deem whatever they consider appropriate, but it is recommended that they tidy up closedown themselves. <wParam>, <lParam> and the return value are not used.

BBC_CSICLOSEWARNING : WM_USER+1152

CSI to application
Broadcast message from CSI to all top level windows within the workstation that it intends to closedown shortly. <wParam> holds the remaining time, in seconds, before CSI actually closes. <lParam> is zero. The time delay is specified in the [Misc] section of the CSI.INI file in the ClosedownDelay parameter. This value can be between 0 and 30 seconds. If the value is zero then no warning message is sent. (Added in V1.16.04)

BBC_NETSTATUSMSG: WM_USER+1094

CSI to application
Broadcast message from CSI to all top level windows informing that the network has failed or been restored. <lParam> is not used. <wParam> is NETWORK_FAIL (0) or NETWORK_OK (1). This message may be disabled by CSI configuration.

BBC_INIFILECHANGE: WM_USER+1138

CSI to application
Message from CSI to every client and driver informing of an ini file change initiated by a NetModify command. <wParam> is zeo. <lParam> is a pointer to a sting containing the ini file change. The message is a space delimited string of the form:

<filename> <section> <entry> <value> <workstation>

BBC_QUERYCLIENTREG: WM_BNCS+15

No information available - awaiting reverse engineering

BBC_RUT: WM_BNCS+17

No information available - awaiting reverse engineering

BBC_GETWORKSTATIONNUM: WM_USER+1095

Return value from the SendMessage is the workstation number. <wParam> and <lParam> are not used.

BBC_PKTSERNUMERR_REG: WM_BNCS+70

Application to CSI
Register for notification of packet serial numbers. <wParam> should contain the window handle you want notifications sent to. <lParam> and return are not used.This feature was introduced in CSI32 version 1.0.23.xx

BBC_PKTSERNUMERR_UNREG: WM_BNCS+71

Application to CSI
Deregister for notification of packet serial numbers. <wParam> should contain the window handle you want deregister. <lParam> and return are not used. This feature was introduced in CSI32 version 1.0.23.xx

BBC_PKTSERNUMERR: WM_BNCS+72

CSI to application
Notification that there has been a serial number error. <wParam> contains the workstation number, <lParam> contains the device number hosted on that workstation which may now be in error. It is not possible to determine whether the missed packet contained a message for this device. This feature was introduced in CSI32 version 1.0.23.xx.

BBC_NETMSGUPDATE: WM_BNCS+18

CSI to application
Delivery of 'N' series messages to every connected client. Distribution of this message is controlled by ini file setting and optional registration (see BBC_NETMSGUPDATE_REG ).

<lParam> contains a pointer to a string containing the 'N' message verbatim. <wParam> is not used. The return value is not used.

Note: 'N' message monitoring can have a very long cycle time and is superseded by CSI32 heartbeat messaging.

BBC_NETMSGUPDATE_REG : WM_BNCS+75

Application to CSI
Optional registration for unicast delivery of BBC_NETMSGUPDATE messages. From CSI32 version 1.2.5 whether BBC_NETMSGUPDATEis broadcast to all clients is controlled by ini file flag:

[Network]
DistributeBBC_NETMSGUPDATE=0

if you want only specific applications to get BBC_NETMSGUPDATE notifications then use this registration and disable every-client registration with the above setting.

<wParam> contains the window handle of the application to receive notifications. <lParam> is not used, the return value is not used.

Note: 'N' message monitoring can have a very long cycle time and is superseded by CSI32 heartbeat messaging.

BBC_NETMSGUPDATE_UNREG : WM_BNCS+76

Application to CSI
Deregister client previously registered with BBC_NETMSGUPDATE_REG.

<wParam> contains the window handle of the application. <lParam> is not used, the return value is not used.

Note: 'N' message monitoring can have a very long cycle time and is superseded by CSI32 heartbeat messaging.

BBC_GETMAXDESTS: WM_BNCS+81

Application to CSI
Get the maximum number of destinations that CSI can control. This command was introduced in CSI32 1.1.21.

The return value contains the number of destinations - typically for BNCS 4096. <wParam> and <lParam> are not used.

BBC_GETMAXSOURCES: WM_BNCS+82

Application to CSI
Get the maximum number of sources that CSI can control. This command was introduced in CSI32 1.1.21.

The return value contains the number of sources - typically for BNCS 4096. <wParam> and <lParam> are not used.

BBC_GETMAXSOURCENAMES: WM_BNCS+83

Application to CSI
Get the maximum number of source names that CSI supports. This command was introduced in CSI32 1.1.21.

The return value contains the number of source names BNCS will support. If this setting is true (1):

[Database]
UseMemoryDatabaseOnly(no_V1_support)=1

the maximum number is 65535, otherwise it's 4096. <wParam> and <lParam> are not used.

BBC_GETMAXDESTNAMES: WM_BNCS+84

Application to CSI
Get the maximum number of dest names that CSI supports. This command was introduced in CSI32 1.1.21.

The return value contains the number of destinations - typically for BNCS 4096. <wParam> and <lParam> are not used.

BBC_GETMAXDEVICES: WM_BNCS+93

Application to CSI
Get the maximum number of devices that CSI can control. This command was introduced in CSI32 1.2.68


dependencies

CSI32 Dependencies

CSI32 has the following direct dependencies:

File | Notes
csi32fix.exe | Microsoft compiler-built applications cannot receive certain ranges of internal messages. csi32fix.exe is a simple Borland application simply passes on the messages it knows CSI32 can’t hear. It doesn’t intercept, pass on or otherwise interfere with application to CSI messaging. This application should exist in the same directory as CSI32.EXE
bwcc32.dll | Part of usual V3 distribution CSI32.EXE needs for its dialog. This needs to be “in the path” or the system directory pointed at by the V3 "bncs_config.ini"
csi32.chm | Integrated help file. This needs to be in the same directory as csi32.exe.

Note: bbcnb32.dll dependency was removed in CSI32 v1.3.0

Packet serial numbers are invisible to most existing BNCS modules, but to filter and display properly the following is required:

File | Notes
V3caplog.exe | V3.7.1 or later understands and displays the packet serial numbers.

The following are not direct dependencies of CSI32 but are a consequence of using it.

File | Notes
inf32fix.exe | Required by V4INFDRV.EXE. This application fundamentally does the same as csi32fix.exe but for infodrivers. This functionality was previously part of V4CSI and was not migrated to csi32.
info32fix.dll | Supporting DLL for inf32fix.exe.


dialog

CSI32 Dialog

Menu

For security, application menus are not displayed unless:

  • CC_SECURE environment variable set to 0 (at the point CSI32 is run)
  • CC_SECURE=0 appears in [Config] section of c:\bncs_config.ini

This also disables all keyboard shortcuts/accelerators including F1 help.

The CC_SECURE environment variable always takes precidence over the setting in c:\bncs_config.ini

Main Dialog

The main dialog is split into different sections - each one is shown and described below.

Sessions

Item | Notes
Sessions | This is the number of currently active sessions whether for device control or file transfer
Mx | This is the number of messages transmitted from this workstation across a session
Tx | This is the number of packets transmitted from this workstation across a session
Rx | This is the number of packets received by this workstation across a session
Ix | This is the total number of sessions that have ever occurred involving the workstation since CSI was started
NCBs | The number of Network Control Blocks assigned to the Sessions

Drivers

Item | Notes
Drivers | The number of drivers hooked into CSI - this number may not be exactly the same as the number of devices hosted
Mx | The number of "revertive" messages transmitted - messages may be combined into the same packet
Tx | The number of packets transmitted - packets may contain multiple messages
Rx | The number of packets received - packets may contain multiple command messages
Dx | The number of command messages relevant for this workstation i.e. where this workstation is hosting the device
Devices | The number of devices hosted by this CSI. This might not be the same value as Drivers since one driver might host multiple devices
NCBs | The number of Network Control Blocks assigned to Drivers

Clients

Item | Notes
Clients | The number of clients currently connected to CSI
Mx | The number of messages transmitted by this workstation. Messages may be combined into multiple packets
Tx | The number of command packets transmitted by this workstation. Packets may contain more than one message
Rx | The number of "revertive" packets received by this workstation.
Sx | The number of relevant "revertive" messages received by this workstation. i.e. messages received that were passed on to interested clients
Cx | The number of poll requests that have been satisfied out of the cache.
NCBs | The number of Network Control Blocks assigned to Clients

Receive Buffers

Item | Notes
InUse | The number of messages received from the network, and currently buffered and awaiting decoding. This is of infinite size.
HWM | The maximum value (high water mark) the "RxBuffs: In Use" value has ever got to.

Revertive Cache

Item | Notes
Disk | The amount of disk memory (KB) used for caching "infodriver" revertives. Each infodriver uses approximately 1 MB. This field is disabled if UseMemoryCache is enabled.
RAM | The amount of RAM used (kB) - each device uses 8KB.
Eff. | This shows the efficiency of the cache. It is calculated from the number of polls or queries received by client applications that can be satisfied by the cache, divided by the total number of poll or query commands.

Transmit Buffers

Item | Notes
TxBuffers: In Use | The number of transmit buffers that have sent data and now pending deletion
HWM | The maximum count (high water mark) that the TxBuffs:In Use has ever got to
Errors | The number of errors detected when trying to transmit data

Revertive Serial Number Errors

Item | Notes
Serial NumErrs | The number of errors where revertive packets have been received with out of order serial numbers

Packet Recovery Statistics

Item | Notes
Unr. Errs | The number of errors which could not be recovered by the packet recovery process.
RcvdPkts | The number of packets which have been recovered.
Superseded Msg | The number of individual revertives from recovered packets which were found to have been superseded by later data
HeartbeatsRx | The total number of heartbeat messages that have been received.

Client / Driver List Dialog

This dialog shows a complete list of the clients and drivers that CSI is hosting. The number of entries in each list corresponds directly to the Clients and Drivers counts described for the main dialog.

The main purpose of this dialog is to determine the IPC mechanism in use. The example below shows a mix of different clients and drivers, their window class name and the module that owns that window.

These lists are maintained dynamically - when clients/driver connect/disconnect these lists will update automatically.

Occasionally CSI will retain a registration for a client/driver that has crashed. In this case the window class name and module name cannot be determined and the entry will show as "Invalid Window". Such information is NOT updated automatically, but only when the dialog is opened. CSI has it's own mechanism for detecting loss of client/driver. If CSI detects a client/driver has gone then it will automatically be removed from this list.


interfacing

CSI32 Interfacing

Driver and client interfacing information and APIs are not defined here for two reasons:

  • This information is usually only available to developers who have done driver training
  • There are considerably better ways of interfacing than using the raw messaging. These "other ways" (ccClient, extclient, ccInfodriver, extinfo in C++, BNCSLib in .Net etc.) are already documented elsewhere


logging

CSI32 Logging

CSI32 maintains various logs of its activities.

These can be found in:

System Type | Log Path
V1 / V2 / V3 | c:\bncslogs\csi32
V4 | %CC_ROOT%\%CC_SYSETM%\logs\csi32

Events Logged

Logs are either appended to a single CSI32 log or create dated daily logs.

The filename of the daily log is simply the date in year/month/day order so that logs sort properly. For example:

20090309.log

It's anticipated that the things logged to csi32.log will never get to an unmanageable size - even if you start/stop CSI several times a day the resulting logs are not likely to ever grow to an unacceptable size even during the whole lifetime of the workstation.

The following events are logged by CSI32:

Event | Where Logged | Notes
Startup | csi32.log | Logs that CSI was startup with the version number
Closedown | csi32.log | Logs that CSI was shutdown - also logs the statistics usually visible on the UI
Crash | csi32.log | Logs the crash address and other information so that errors can be traced
Peer Poll Error | Daily log |
Serial number error | Daily log |
Cache cleared | Daily log | Following a packet serial number error may appear this log which indicates which devices may have been affected
Send Error | csi32.log | Rarely seen log that greater than 9999 messages have been sent without the application having an opportunity to delete the network resources


netStatus

Net Status Messaging

Description

NetStatus, also known as ES (because of the ApplCore commmand) or "Device Messaging" is a means of sending/receiving messages from BNCS devices on specific workstations.

Historically, implementation has been sparse and it has been a quirky mechanism because it breaks a principle of BNCS that you don't need to know where devices are hosted.

It's purpose was originally to allow a means of communication with device drivers regardless of their redundancy (txrx) state. Typically the only command that any driver seem to support was querying and setting of redundancy state.

It is however much more useful in determining things like comms status - perhaps on devices that have more than a single device/port. It's especially useful of course because comms failure may result in the driver going rxonly which means of course that you can't present the value a normal "in-band" infodriver slot.

I came to the conclusion that it could be made more generic, useful and more efficient with a few simple changes.

CSI32 version 1.2.83 made the following changes to the mechanism:

  • messages no longer sent as individual packets, but aggregated into normal revertive traffic
  • NS messages can be sent to no specific target - both the commands and responses
  • NS messages can now be sent spontaneously on change of state, rather than strictly command->reply

NS Format

NS commands and responses are the same and are of the format (as appears in CapLog):

NS <device> <deviceWorkstation> '<message>' <clientWorkstation> <handle> <reference>
Field | Notes
device | The BNCS device
deviceWorkstation | The workstation hosting the device
message | Typically param=value string - max 200 characters
clientWorkstation | The sender or target for the NS message
handle | A value the client understands, included verbatum by drivers responding
reference | A value the client understands, included verbatum by drivers responding

I've marked message size as "max 200 chars" in reality the whole message has to fit into a 256 byte block, so it's this size minus the device/workstation/handle/ref elements, so 200 is a safe maximum.

NS Commands

Commands can either be directed or undirected - i.e. to a specific driver instance on the given workstation, or to all drivers running that device.

Directed command

NS 111 222 'txrx=?' 444 12345 67890

which may solicit this response:

NS 111 222 'txrx=1' 444 12345 67890

client workstation is set and handle/reference values are retained

Undirected command

Note this is the same as the directed command, but the deviceWorkstation is not set

NS 111 0 'txrx=?' 444 12345 67890

which may solicit more than one response:

NS 111 222 'txrx=1' 444 12345 67890
NS 111 333 'txrx=2' 444 12345 67890

client workstation is set and handle/reference values are retained, and you get one response for each workstation hosting the device

Spontaneous NS

NS 111 222 'txrx=1' 0 0 0

This message, from device 111 on deviceWorkstation 222 is sent to no specific target and will be distributed to any client with a normal revertive registration for that device

Change-of-state NS messages are sent in the same way that you would a normal "revertive", and these are no more expensive than normal revertive traffic.

Message Format

The message string is a free-form value, but the following section aims to be a guide for its consistent use.

Infodriver / GRD

Infodriver/grd supports only the following command/response

Message | Notes
txrx=? | client to driver requesting txrx state
txrx=<value> | driver to client responding with txrx state where 0=unknown/invalid, 1=rxonly, 2=txrx

Example messages

The format of these messages should be familiar to any user of BNCS 4.x where param=value strings are used extensively within the UI

Message | Notes
? or ?=? | Tell me everything you know
txrx=? | client to driver requesting txrx state
txrx=<value> | driver to client responding with txrx state where value is blank, rxonly, txrx
_version=? | Module version
_module=? | Module name/path

Messages should be strictly parameter=value pairs so that the key/value pairs may be cached.

With the exception of "?=?", responses should have the same key as the request.

Extending messages

A device such as a traditional GRD has multiple comm ports and so has multiple comms statuses.

A message such as this could be used to specify which port:

com.1=ok
com.2=fail

This mechanism could be further extended to show finer grain status on which drivers may set their redundancy. Consider the following messages sent from two different drivers:

comms=7/8
comms=6/8

This would indicate that the first driver has 7 out of 8 comm ports working and so one broken connection, and the second driver two broken connections. The redundancy mechanism (negotiated entirely within the driver implementation, not CSI) should favour the first driver.

This is beyond the scope of NS messaging to define exact behaviour, but use of NS messages enables such negotiation.

Inter-site

Huxley

These messages are normal command/revertive traffic and so will be carried over Huxley like any other traffic

FABIAN / slink

There is no support for NS messaging to/from a remote network.

NS messaging however is used entirely appropriately within slink to indicate connection state for the device. That's slink connection state, not the connection state of the original device.

Transfering the messages themselves over the link is easy enough, but it gets really messy with "client handles/references" since these are not valid when re-transmitted by a different client (ie.FABIAN/slink). There is no session, transaction or unique ID to be able to readily associate a request with a reply to re-direct back to the original client.


networking

BNCS Network

Introduction

BNCS uses NetBIOS - a legacy Microsoft network API (chosen at a time a TCP network was a chargable extra on Windows 3.1).

Note I say "network API" and not "network protocol" since it isn't - NetBIOS is a means of machines communicating and specifies the service that they will support rather than how they should do it.

BNCS currently runs on NetBIOS/IP (aka NBT) as well as the legacy NetBIOS/NetBEUI - it can also run on NetBIOS/IPX though it's not thought that any systems do.

BNCS messaging is pretty simple - most control messages are passed as broadcast (in the network sense) messages so that they are received by every machine on the network. Whilst network professionals frown on such techniques it's actually very efficient at point to multipoint message delivery. BNCS has been used for systems with hundreds of workstations - there are the same overheads delivering messages to 1000 workstations or just 1.

Use of broadcast networking also simplifies the configuration of a system in that the sending node doesn't need to know the configuration of the network or require any broker or directory to use services of the network (e.g. any of the many BNCS drivers).

Whilst broadcast messaging (in the network sense) is an "unreliable" messaging technique (as defined for a network protocol) it's actually proved extremely reliable on the stand-alone networks on which BNCS has been deployed.

Latterly BNCS has added a proprietary packet recovery mechanism to address the issue of network broadcasts as an "unreliable protocol".

NetBIOS services

NetBIOS provides various services -

  • naming (both individual machines and groups)
  • directed messages
  • broadcast messages
  • sessions
  • NetBIOS names

BNCS uses the following NetBIOS names. Some of the names are different depending upon whether there is a channel number used for that system.

Note:

  • V1 has no notion of channel numbers
  • STATUS_CHANNEL does not have a channel number because it works across multiple channels
  • WORKSTATION does not have a channel number either - though it's inconvenient since it restricts what workstations can be run on a network otherwise segmented by BNCS channel number. This is rarely a problem on production systems but is a limitation on development networks.
  • The "name with channel no." version of the name is used for channel numbers > 0
Name / Name with channel no. | Type | Version | Use
CSI CSIn | Group | V1 & V2 | Messages from drivers to clients n is the channel number (no leading zeros)
DEVICE_CONTROL DEVICE_CONTROLn | Group | V2 | Messages from clients to drivers n is the channel number (no leading zeros)
STATUS_CHANNEL | Group | V2 | Messages about workstation status
WORKSTATIONxx | Unique | V1 & V2 | Where xx is the workstation number (1 leading zero). The means by which unique workstation IDs are enforced as well as a named end-point of session (v2)
BNCSRECOVERY BNCSRECOVERYn | Group | Extn. | Messages relating to packet recovery n is the channel number (no leading zeros) Packet recovery is an extension to V2 networking - works between packet-recovery-enabled workstations, and doesn't upset the operation of legacy workstations.
ID_xxx | Unique | V1 | Message from client to Information driver xxx
GPID_xxx | Unique | V1 | Message from client to GPI driver xxx
GRD_xxx | Unique | V1 | Message from client to router driver xxx

For NetBIOS/IP (NBT) you can monitor what names you have registered by using the following command line command:

nbtstat -n

Note this command will also list a few "system" names such as the workstation name and workgroup not just the BNCS names.

Differences between V1 BNCS network messages and V2

We have to be careful here with the version numbers. "V1" BNCS network messages refer to clients/drivers before 1997 - "V2" BNCS network messages refers to pretty much everything since (whether a system is defined as a headline V2, V3, V4, V4.5, V4.6, V4.7 BNCS system - the underlying network messaging is still "V2").

V1 drivers register individually with the network - if you want to send a message to that driver then you send it to that named resource on the network. In V2 a message for a driver is just sent to "a driver" and it's the receiving end determines whether it's interested in the message.

V1 drivers are strictly one packet per driver - "revertive" messages are packed efficiently (more slots per packet). Command messages are sent point-to-point, "revertives" are broadcast.

V2 allows packing of different drivers into one packet per workstation. Messages are less efficiently packed but in practice being able to pack multiple devices into a single packet outweighs the disadvantages. Messages are broadcast - each driver must receive the message and determine if it contains relevant infomation.

LANA Number

As noted at the beginning NetBIOS is an API not a protocol. That API may be presented as all the different protocols on multiple network adaptors. Which one should BNCS use? NetBIOS/IP on the wired Ethernet or NetBIOS/NetBEUI on the wireless adaptor? NetBIOS enumerates these different combinations and gives them a number - the LANA number.

You can use the Microsoft utility lanacfg.exe to list all the possible combinations of protocol and adaptor or there is a BNCS utility setlana.exe that wraps it up and allows setting the LANA number from the UI in it's "usual" locations.

Client to driver messages

This includes command messages (IW, RC, GS, IP, RP etc. etc.) and revertive messages. These are sent as broadcast datagrams commands sent to NetBIOS name DEVICE_CONTROL. Revertives are sent to NetBIOS name CSI. It's these names that allow the NetBIOS layer to filter incoming messages and only pass to interested parties.


packetFormats

Packet Formats

Introduction

This document describes the packet formats used in CSI.

Packets are in network byte order - so (for Windows) a DWORD is stored in memory in the opposite order in which it comes off the network.

These packet formats are not a user API and are here for reference only. They are subject to change without notification.

Heartbeat

Byte Offset | Type | Use
0 - 2 | String | Null terminated string "HB" (for heartbeat!)
3 | Byte | Heartbeat header size - currently 36 (was 32 before version 1.1.11)
4 | Byte | packet number (should be rarely anything other than 0) Top bit indicates if more packets follow - last packet will always have this at zero. e.g. 0x80 - first packet - more follow 0x81 - second packet - more follow 0x02 - third and last packet
5 - 6 | WORD (16 bits) | workstation number
7 | Byte | heartbeat interval in seconds
8 - 11 | DWORD (32 bits) | last revertive serial number
12 - 15 | DWORD | csi up time in seconds
16 - 19 | DWORD | current workstation time of day (in seconds since Jan 1st 1970)
20 - 23 | DWORD | earliest packet that can be recovered
24 - 27 | DWORD | packet checksum
28 - 31 | DWORD | unrecoverable error count
32 - 35 | DWORD | recovered packet count (from version 1.1.11)
36+ | WORD | device number & redundancy flags (see below). bit 15 is set if driver is in TXRX bit 14 is set if a driver is RxOnly but wishes to be TXRX bit 13 is the device close flag bit 12 is not used - reserved for NO function ("Network Objection" redundancy switching) bits 0-11 are the device number (0 - 4095 max) Bits reserved for device number mirror the number of bits reserved in the "Universal Revertive" packet structure

Bits 13/14/15 have the following states

Bit 15 | Bit 14 | Bit 13 | Notes
0 | 0 | 0 | Device RxOnly Broken Equivalent to NB message
0 | 1 | x | Device RxOnly Equivalent to NI message
1 | 0 | x | Device TxRx Equivalent to NA message
1 | 1 | x | Not valid state
0 | 0 | 1 | Device Closing Equivalent to NC message

After the header there is none or more WORDs which is a list of the drivers currently running on this workstation and their status.

From CSI 1.2.35 heartbeats allow for status of all 999 drivers (previously only 238). This requires that multiple heartbeat packets are sent (see flag in byte offset 4). For the full 999 devices 5 packets required (999/238 = 4.19)

Packet Recovery Request / Error Response

There are two packet types on the packet recovery "network channel".

  • One is a standard universal revertive (UR) packet.
  • The other is as defined below
Byte Offset | Type | Use
0 - 2 | String | Null terminated string: "PR" for Packet Recovery "PE" for Packet (recovery) Error
3 | Byte | header size - currently 16
4 - 5 | WORD | originating workstation number
6 - 9 | DWORD | packet checksum
n+0 | WORD | workstation
n+2 | DWORD | start packet ID to be recovered
n+6 | DWORD | end packet ID to be recovered

where n starts at the header size and can continue in 10 byte blocks to the end of the packet (max 49 requests)

The same packet format is used for packet recovery requests and packet recovery error responses.


packetRecovery

CSI32 Packet Recovery

Description

This feature is available in CSI32 version 1.1.2.xx or later.

Before CSI32 version 1.2.33 packet recovery used AF_NETBIOS socket type - support for which has been dropped on 64 bit operating systems. This meant that packet recovery did not work on those OSs. From 1.2.33 however packet recovery just uses the same packet recovery mechanism as the reset of CSI and so works the same.

BNCS uses unacknowledged broadcast datagrams for normal in-band message delivery. This is very efficient for point to multi-point data delivery, and usually doesn't suffer significant reliability problems.

For commands that initiate an action there is a return value, however where data is generated spontaneously by devices (e.g. status like "input fail") there has been no means of correcting if any values have been missed.

Tests have proven there is a very very low level of packet loss on a network but any packet loss at all may cause discrepancies between displayed data and reality.

CSI32 introduced packet serial numbers to detect errors and these have now been extended to recover lost packets.

Packet recovery is for "revertive" data only.

General Overview

CSI32 borrows concepts from the PGM (Pragmatic General Multicast) protocol. The gist of which is that whilst packets are being received in order, without anything missing "listeners" sit silently happily consuming the data. On missing data however listeners generate NAK (Not AcKnowledge) messages back to the sender to say "pardon?"

A network storm of "pardon?" messages is prevented by a variable hold-off preventing all listeners asking at once, and by listeners receiving each others messages so one knows it doesn't have to ask if someone else already has. On a large network where a packet is lost at source this may still result in several near simultaneous requests for the same thing.

PGM itself is not used because BNCS continued use of NetBIOS, but there are other factors too such as delays in recovering packets.

BNCS must remain a responsive control system - to recover packets in strict order they were sent introduces delays - perhaps considerable delays (10s of seconds). Such delays are not appropriate for most BNCS systems so a mechanism has been written to allow for immediate delivery of current data but delayed recovered data is checked for relevance.

For example - imagine a parameter regularly toggling states with no other traffic on the network. If a packet is missed the process to recover it begins. Whilst this happens the data continues to change. When the packet is recovered it's no good just passing this direct to the client - what it contains will in this case have been superseded. So a check is made to see if a later packet than the one recovered contained information for the same parameter and this recovered data is discarded.

Heartbeats

As noted above listeners happily consume data silently until they detect a discontinuity in the sequence of packets. This is all very well whilst data is being regularly generated from the driver. It wouldn't be known to a listener if the last 100 packets have been lost until the 101st arrives and that discontinuity is detected.

Heartbeats are a guaranteed regular "pulse" that contains information on the last packet sent.

Heartbeats have the other benefit that they can be used to determine the health of the system from any workstation that has been running for greater than the maximum heartbeat period.

Unrecoverable Errors

Errors are flagged from CSI when there are unrecoverable errors. With the packet recovery feature off every serial number discontinuity is flagged as an error.

With the packet recovery feature on only those errors that truly cannot be recovered after the specified timeouts and retries are flagged as an error.

The notification however is the same in both cases - it's just when it's generated that is different.

Testing

The trouble with modern networks is that actually they are staggeringly reliable - certainly measured values in excess of 99.997%. This makes it difficult to test the packet recovery mechanism very easily so CSI32 has unreliability settings to deliberately lose messages outgoing and incoming.

In development & testing packet loss of 40% was used along with induced unreliability into the recovery path too.

Packet Formats

Packet formats are described here:

Configuration

Configuration options are described in the PacketRecovery section here:


Redundancy

Description

It is desirable to have main and reserve drivers on a BNCS network so that in the event of a PC or driver failure the reserve driver could automatically take over the function of the main driver.

This is achieved by having active drivers in transmit receive (TXRX) and non-active drivers in receive only (RXONLY). The non-active drivers still receive and can process and store messages from the network but are unable to transmit data back to the network.

This document is a description of the inter-application messages used to control the TXRX and RXONLY status of BNCS drivers. This is not complete driver / infodriver interfacing documentation.

This documentation refers to CSI version 1.18.02 or later and Infodriver V2.02.02 or later.

It is the CSIs on the network that handles driver redundancy, passing messages between each other and to the driver applications, to negotiate the TXRX state of each of the drivers. This messaging also ensures that there can be no more than one instance of a particular device number.

Redundancy gained an extra feature "Redundancy Master" from CSI32 version 1.2.59

Normal Driver Operation

Consider a single Infodriver on a network.

Network Inquiry Message

When this driver starts up it sends a network inquiry message. This appears on CapLog and is of the format:

NI <device number> <workstation>

e.g.

NI 123 009

This example is an inquiry for workstation 9 to have device 123 in TXRX mode on the network.

Network Objection Message

If there is another driver of this device number running an objection message of the format:

NO <device no> <w/s requesting new instance> <w/s with existing active instance>

e.g.

NO 123 011 009

This example is an objection from workstation 9's to workstation 11's request to register device 123 as TXRX.

Network Attention Message

For active drivers CSI regularly sends out message to the network informing all other devices on the network that this device is active. This message can be seen on CapLog and is of the format:

NA <device number> <workstation>

e.g.

NA 123 009

This example shows that device 123 is active on workstation 9.

The NA message is identical to an NI message in terms of possible responses. Lets say we have device 123 active on workstation 9, and device 123 active on workstation 11 (this is an unusual situation but can happen if you start these drivers up without the PCs connected to the network). The first to send out a NA message will get an NO message from the other active driver. This will cause the driver that generated the NA message to go RXONLY.

Network Close Message

When a driver in TXRX mode shuts down it sends a closing message to the network. This is to tell other drivers of this device number that there is an opportunity to go TXRX. The closing message is of the format:

NC <device number> <workstation>

e.g.

NC 123 009

This example shows that active device 123 is being closed down on workstation 9. This gives other drivers in RXONLY an opportunity to try and go TXRX.

Network Broken Message

This slightly misnamed message is for indication only - no action results as a result of receiving it. It was meant to indicate a driver in RxOnly that does not want to request to go TxRx. The word "broken" used because it was initially used for a driver in RxOnly that was in no fit state to become TxRx (because of failed device comms for example). It shows the driver as alive but in trouble.

The message is of the format:

NB <device number> <workstation>

e.g.

NB 123 009

This example shows that RxOnly device 123 on workstation 9 is alive but does not wish to go TxRx.

Drivers which use multiple devices may use a single device to control TxRx - the other devices not wishing to control their own TxRx state may send "Net Broken" messages. This doesn't mean they're broken necessarily but that they don't want to independently request to go TxRx.

Redundancy Master

There are significant issues with redundancy messaging described above:

  • cycle time is dependent upon the number of devices running on a workstation. With default 'N' message send time of 60 seconds a driver hosting 100 devices would take over three hours to change then all over.
  • BNCS devices are independent, but some drivers use multiple devices for a single function - this leads to issues ensuring TxRx state tracks across all devices. Some drivers have explicit code to do this - it's an overhead that shouldn't be required.
  • there is a single 'N' message per packet - which leads to many packets on the network - this is particularly significant with drivers that host a very large number of devices (e.g. FABIAN) especially on closedown when individual NetClose "NC" messages are sent.

CSI 1.2.44 introduces the idea of "redundancy master". This is where a single device is nominated to be the master for a group and it alone controls the TxRx state of all its slave devices. The slave devices simply track the master and only the master device need talk to the network. For a FABIAN with 50 drivers this reduces the cycle time from 50 messages to just 1.

Configuration

This may be configured on-the-fly by extension of the existing APIs - and also available as static configuration in the usual CSI configuration file:

Redundancy master can be configured in csi.ini/bncs_system.ini:

[RedundancyMaster]
11=13-15
101=101,102,103,104

The above configuration specifies that:

  • device 11 is the master for itself and devices 13,14,15 (the dash indicates a range).
  • device 101 is the master for itself and devices 102, 103, and 104 (devices explicitly listed)

Notes

  • Redundancy master does not completely disable the normal 'N' message functionality - for the above example of devices 101-104 in a group, you should never see any 'N' messages for devices 102-104. If however a stand-alone device 104 were to be started on the network then the normal Network Objection "NO" message will still be sent by the redundancy master.
  • Slave devices get no choice whether they are TxRx or not - the return value to BBC_REQDEVGOTXRX is ignored.

External Driver Messaging

The following messages are used to control the TXRX status of a device.

These messages are defined in BBC_MXC.H

BBC_REQDEVGORXONLY

CSI to Driver
Request to go RXONLY.
This message is sent to a driver when a NI message is received from another driver PC.
The return value to this message specifies whether a NO message is sent to the network.
wParam not used (from CSI 4.01 Workstation requesting TXRX)
lParam Device Number
Returns FALSE - Refuse to go RXONLY by sending a NO message, TRUE - OK to go RXONLY don't send a response to the network

BBC_DEVICEIDINUSE

CSI to Driver
This device ID already in use on the network
This message is sent to a driver when an NO message is received objecting to the driver on this machine.
This is notification that this driver has been set to RXONLY.
wParam not used
lParam Device Number
Returns not used

BBC_REQDEVGOTXRX

CSI to Driver
Sent to the external just before going TXRX
wParam not used
lParam Device Number
Returns TRUE - OK to go TXRX, FALSE - Refuse to go TXRX

BBC_INQDEVGOTXRX

CSI to Driver
Inquire go TXRX. This message is sent before this workstation issues an NI message to the network. If this driver does not want to go TXRX it can choose not to send the NI message
wParam not used
lParam Device Number
Returns TRUE - Send NI to network, FALSE - Don't' send NI to network

BBC_IDGETTXRXMODE

Driver to CSI
Get the TXRX state of this infodriver.
This message is only used from Infodriver external to infodriver
wParam not used
lParam not used
Returns Value can be one of the following parameters:

  • IFMODE_NONE - Device not registered on this w/s
  • IFMODE_RXONLY - Device in RXONLY
  • IFMODE_TXRX - Device in TXRX

BBC_GETDEVTXRXMODE

Driver to CSI
Get the TXRX state of this driver
As per BBC_IDGETTXRXMODE above except that lParam contains the device number

BBC_SETDEVTXRXMODE

Driver to CSI
Set the TXRX state of this driver
wParam Mode:

  • IFMODE_RXONLY - Set mode to RXONLY by sending a NC message to network
  • IFMODE_TXRX - Try to set mode to TXRX by sending NI message to network
  • IFMODE_FORCETXRX - Force mode to TXRX by sending NO message to network
    Note: This message sets the mode direct (and sends an NA message) and does not issue a BBC_REQDEVGOTXRX

lParam Device Number
Returns Not used

BBC_SETREDUNDANCYMASTER

Driver to CSI
From CSI32 1.2.59. Some drivers present themselves as multiple BNCS devices - this is an API to allow an app to set only one of a group of devices to negotiate and set redundancy state. This reduces cycle time and ensures within CSI that TxRx state is consistent with a group of devices - when the master changes state, all those set with that as the master change state too. You need to supply the handle of the driver you wish to set the redundancy state for.

Note For correct operation do not forget to set the master device to itself

HIWORD( lParam ) - masterDevice
LOWORD( lParam ) - slaveDevice
wParam HWND hDriver
Returns master device if successful or -1 on failure

Using these interface messages

It depends upon how the device is connected to the driver as to how to use the redundancy switching.

One common feature that is important, no matter how an external device is connected into the system, is whether the driver has communications with that device.

If a driver has good comms with the device then this driver is available as a reserve - if the device does not have comms there is no point in offering this driver as a reserve.

Therefore most of the TXRX / RXONLY switching decisions are made on a comms. fail flag.

Sample code

This assumes that there is a comms fail flag called fCommsFailSystem. This is TRUE in the comms fail state. The Comms. fail state is determined by each implimentation but is assumed to be something like a number of consecutive missed messages.

This is the code required in the Windows procedure:

case BBC_REQDEVGORXONLY:
    // don't go RXONLY if we have active comms (dual ported solutions may wish to just concede TxRx state)
    return fCommsFailSystem;

case BBC_REQDEVGOTXRX:
    // this is our notification of going TXRX (if we approve it) show it on the dlg
    if( !fCommsFailSystem )
        SetDlgItemText( hDlg, ID_TXRXMODE, "TXRX");

    // only go TXRX if we have active comms
    return !fCommsFailSystem;

case BBC_INQDEVGOTXRX:
    // don't ask to go TXRX if we can't offer a reserve
    return !fCommsFailSystem;

case BBC_DEVICEIDINUSE:
    // this device is in use - we're read only - show on dlg
    SetDlgItemText( hDlg, ID_TXRXMODE, "RXONLY");
    return 0;

The following fragment shows how to get the initial state of the redundancy (this is for Infodriver external - GRD the same, direct CSI messaging similar):

switch( SendMessage( m_hInfo, BBC_IDGETTXRXMODE, 0, 0 ))
{
    case IFMODE_TXRX:
        SetDlgItemText( hDlg, ID_TXRXMODE, "TXRX");
        break;

    case IFMODE_RXONLY:
        SetDlgItemText( hDlg, ID_TXRXMODE, "RXONLY");
        break;

    default:
        SetDlgItemText( hDlg, ID_TXRXMODE, "Unknown");
        break;
}


statusInfodrivers

CSI32 Status Infodrivers

Introduction

CSI32 introduced the idea of "heartbeat" messages with packet recovery. Their primary purpose is to generate regular updates of current serial packet serial numbers so that packet loss may be detected. A regular message sent to the network may of course also be used to hold other status information.

Heartbeats contain information about the workstation status - such as up-time, as well as information about drivers hosted on that workstation including the redundancy status not available directly via any other single means.

Each heartbeat is received by every machine on the network - this means that every machine can quickly get an accurate idea of the status of all other workstations and drivers on the network.

BNCSStat (V3Status) uses a similar idea for network status, but then has the curiosity of representing this data back onto the network. Segmented networks, or VPNs make this approach undesirable.

Status Infodrivers

There are two "virtual" infodrivers that CSI uses to pass workstation and driver information back up to clients. These do not exist as true devices on the network, but are locally generated in each CSI32. This mechanism ensures that any version of BNCS client can readily use this new status information without having to implement a new API.

There are two settings in the CSI configuration file (csi.ini or bncs_system.ini):

[Status]
DeviceInfodriverId=124
WorkstationInfodriverId=123

These are the two device numbers of the virtual Infodrivers. These are read-only devices, may be polled and spontaneously generates change of state revertives if devices/workstations appear or disappear.

The data in these internal Infodrivers is only valid after a short period - usually a minute:

If you poll the workstation status during the startup period you'll get valid data (if it's arrived) or else the value "starting".

  • If you poll the device status device during the startup period you'll get the string "starting" followed by the available data. e.g. "starting,123T,456R"
  • To ensure that a client doesn't have to worry about repolling data after the startup period it is automatically repolled once the startup period is over.

A cache test for these two Infodrivers always returns valid except during the startup period.

Workstation Status Infodriver

There is one slot per workstation - where slot 1 is workstation 1, and slot 999 is workstation 999.

For an active workstation each slot contains a comma delimited list of:

  • up-time
  • current time
  • unrecoverable error count

Slots for inactive workstations are empty

For example:

0,02,05,51,2010,01,19,20,13,46,0,2,2010,01,01,17,20,44

Each entry is of the format:

<uptime days>,<hours>,<minutes>,<seconds>,<current year>,<month>,<day>,<hour>,<minute>,<second>,<unrecoverable error count>,<recovered packet count>,<csi start year>,<month>,<day>,<hour>,<minute>,<second>

So you can determine that this sample entry this workstation has been up for 2 hours 5 minutes and 51 seconds. It's current time is 20:13:46 on 19/1/2010 and hasn't got any unrecoverable errors and two recovered packets, CSI has been up since 17:20:44 on 01/01/2010

Unrecoverable error count mirrors that as shown on the CSI dialog - and is cleared when the CSI counters are cleared.

That same information in more easily digested form (maybe!):

Field offset | Info
0 | Days |
1 | Hours | Uptime
2 | minutes
3 | seconds
4 | year | Current workstation clock
5 | month
6 | day
7 | Hour
8 | Minute
9 | Second
10 | Unrecoverable Error Count |
11 | Recovered Packet Count |
12 | year | CSI start time
13 | month
14 | day
15 | hour
16 | minute
17 | second

Device Status Infodriver

There is one slot per device - so slot 1 is device 1 and slot 999 is device 999.

For each driver each slot contains a comma delimited list of the workstations hosting that driver with an indication of the driver state.

For example:

011T,022R,033B

Entries are zero padded to three characters for ease of decoding.

This indicates that this driver is TXRX on workstation 11, RxOnly on workstation 22 and RxOnly and broken on workstation 33 (not all drivers support this state). This would perhaps be an unusual entry on a real system since most drivers would only have 1 "main" in TXRX and 1 reserve RxOnly - this example just shows all three states.

The perhaps misnamed "RxOnly Broken" state was originally designed to indicate a running driver but one that did not want to go TxRx - perhaps because it lost comms with its device and was in no fit state. The "RxOnly Broken" state can also be used by multi-device drivers when TxRx state is controlled by a single master device and the slave devices should not attempt to negotiate their own TxRx state.


version

CSI32 History

Version | Date | Comments
1.00 | 16/12/93 | Development commenced. Added GPI driver commands
1.01 | 29/01/94 | Added InfoDriver commands. Now uses ApplCore INI file
1.02 | 31/01/94 | Added Booking System support
1.03 | 21/02/94 | Increased message queue size. Now closes down gracefully
1.04 10/03/94 Added database functions
Added 'Licence' and 'About' menu
Database bug fix
Added 'Network Attention' mechanism
1.05 | 11/04/94 | Added CSHost support
1.06 22/06/94 First speed optimisation
Clear added to menu bar
1.07 | 29/06/94 | Router revertives now take names from local database
1.08 01/07/94 Cache for router status
Timer for status updates
Net Restart command added
Database change notification facility added
Cache defaults to OFF
Message queue increased to maximum
Hooks for CSLink added to replace CSHost
1.09 | 03/01/95 | Minor bug fixes to Network Manager functions and router control device range
1.10 14/04/95 Speed enhancements to router datagrams
Reduced max clients to 32
Diagnostic switch added
1.11 25/06/95 Generic 'Device Control' datagrams replace
CSLink specific messaging.
1.12 25/08/95 Bug fix to cache mechanism
Reduced maximum clients to 24
1.13 | 22/01/96 | Recompiled to test BBC_NBIF.DLL instead of NETBIOS.DLL for Windows 95 compatibility
1.14 | 31/03/96 | Added more protection to cache routines. Tidied network messaging
1.15 11/01/97 Bug fix to router cache routines
Added CSRemote messaging
1.15.01 | 28/04/97 | Destination 0 no longer causes cache to GPF
1.15.02 | 06/05/97 | Bug to cache validity routines
1.15.03 | 20/05/97 | BBC_GETCSIHWND now send WS Id in lParam
1.15.04 | 16/10/97 | Bug fix to database routines
1.15.05 | 02/12/97 | Increased max registrations to 128
1.16.00 19/12/97 Added command buffering
Added Message counters to diagnostic window
Extended diags box now appears on startup
Session dir routines now use temp filepath
Client cmds ignored if client mode disabled
Drivers cmds ignored if driver mode disabled
'DEV_xxx.INI' generic type add
Auxilliary database handler added
Changed database rouines to work direct to CSI
Added information resource
CreateProfile() makes 'Name' entry in [Device]
Added 'Queue Clear' Session menu
Added 'Session Clear' options to Session menu
WS Id now sent in lParam of BBC_HWNDCSI msg
Added client cache enable/disable functions
Added Device_GetData() function
Added Device_Index() function
Added Cache_Flush() function
Cache files now deleted on closedown
Added system messaging
Added selective registration
Added packet mode revertive support
Added database change notify for V2 drivers
Rev. F For V1 drivers now sends commands singularly
Rev. G Added BBC_QUERYCACHEMODE handler
Rev. H Bug fixes to client registration routines
Rev. I Bug fixes to client unregistration routines
Rev. J Bug fix to GPI Revmessage
Changed default Client buffers to 20
Changed default Driver buffers to 4
Rev. K Bug fix to allow Tx to increment
Rev. L Bug fix to tertiary message decode
Rev. M Bug fix to prevent mem leak on client dereg
1.16.01 11/02/98 Bug fix to allow 16 character database names
Mex secondary buffers reduced to 256
Max clients raised to 48
Auto off added for tertiary buffering
Auto off added for secondary buffering
1.16.02 | 02/03/98 | Bug fix to check slotsize from V1 InfoDrivers
1.16.03 11/03/98 Bug fix to client Tx message box
Added CSMain_GetDeviceProperties()
1.16.04 | 17/03/98 | Added BBC_CSICLOSEWARNING handlers
1.16.05 | 27/03/98 | Bug fix to give default type 0 to V2 drivers
1.16.06 | 30/03/98 | Bug fix to prevent TerBuf_Decode() stalling
1.16.06A | 21/05/98 | CSNDI_SendToDriver() tmp string size now 513
1.16.06B | 21/05/98 | CSNDI_Revertive() acStr size now 513
1.16.06C 22/05/98 Packet size checking added to all functions
Stacksize increased to 4096
Log functions removed since CapLog does it
1.16.06D | 01/06/98 | D'base funcs enabled if client mode is off
1.16.06E | 01/07/98 | Bug fix to tertiary buffering protection
1.16.06F | 15/07/98 | Bug fix to CSReg_GetClientDevIdx()
1.16.07 12/08/98 consolidates bug fixes to 1.16.06
28/08/98 Now sends BBC_DATABASEPOLL message to drivers
1.16.07 | A19/10/98 | Sends system messages on client msg errors
1.16.07 | B28/10/98 | Bug fix to RI command with 16 character names
1.16.08 10/12/98 consolidates bug fixes to 1.16.07
12/12/98 Bug fix to protect CSDbase_SaveGRDEntry()
1.16.09 19/01/99 Bug fix to CSNDI_Revertive()
21/01/99 Added CSNDI_SendVerbatimMsg()
1.16.10 | 17/02/99 | Bug fix to CSDbase_GetDbaseName()
1.16.11 01/06/99 Now only objects if hosted driver is in TX/RX
03/06/99 Now handles RD commands for v2 drivers
1.17.00 22/10/99 32 bit message packers and crackers added
BBC_REGCLIENT substituted for BBC_REGAPPLCORE
Added 32 bit flag to device driver flags
1.17.01 | 18/11/99 | Router Modify now works after DP command
1.17.02 09/01/00 Added the 'network channel' options
14/01/00 Now allows source
1.17.03 | 08/02/00 | Now creates own temp dir for cache files
1.17.04 11/02/00 Now transmits CSI status messages
21/02/00 Added BBC_TXREVPACKET for raw packet Tx
22/02/00 Added CSNDI_RegAllDeviceIds()
25/02/00 Main message window result code now long
Reponse to BBC_GETCSIchanged
Commas now allowed in V2 databases 0 and 1
Implemented up-time counters
Max secondary buffers reduced to 200
Clients not sent hWnd if ClientMode disabled
06/03/00 Bug fix to CSCmd_NetObject()
Added boot time to status message
1.17.05 04/04/00 Modified 32bit message routines to V4
Max clients reduced to 44
1.17.06 09/05/00 Bug fix to 16 bit version of V4 msg cracker
15/05/00 Now transmits Tx packet counts in status msg
1.17.07 08/08/00 Began adding serial port watchdog functions
Bug fix to CSNetSes_Send()
14/08/00 Now updates RAM dbase with mapped DEV files
1.17.08 | 22/08/00 | Completed watchdog functions
1.17.09 | 30/08/00 | Added BBC_GETMAPPEDDEVID function
1.17.10 | 15/09/00 | Added BBC_REQDEVGORXONLY to CSCmd_NetInquire()
1.17.11 | 20/09/00 | D'grams with no header can be sent by clients
1.17.12 | 11/10/00 | Network objections sent and handled by acNDI
1.18.00 | 08/11/00 | Implements automatic driver Tx\Rx assertions
1.18.01 | 05/01/01 | Active drivers no longer sent GOTXRX message
1.18.02 | 09/01/01 | Modified TXRX to enable force changeovers
1.18.03 | 22/01/01 | Default Tx/Rx retry period now 60 seconds
1.18.04 | 25/01/01 | Bug fix to void CSCmd_RtrModify()
1.18.05 | 26/01/01 | Max Clients reduced to 32
1.18.06 | 04/05/01 | Small fix to CSNDI_RegDeviceId()
1.18.07 | 10/05/01 | BBC_GETDEVPROPERTIES now returns database list
1.18.08 | 13/08/01 | Libraries now freed after message loop quits
1.18.09 | 21/08/01 | Now broadcasts BBC_APPREADY message when ready
1.19.00 | 05/12/01 | Added local loop back for locally hosted Id's
1.19.01 | 11/12/01 | Five secondary buffers processed per 55ms
1.20.00 | 21/02/02 | Added standalone, no network option to INI
1.20.01 13/06/02 Reinstated BBC_CSICLOSEWARNING handlers
Removed debug data to reduce program size
1.20.02 13/08/02 CSMain_TxPostDirectMessage now uses PostMsg
BBC_DATABASEPOLL in CSCmd_RtrModify now posted
MIN_USERS added so the WS range can be used
1.20.03 | 04/09/02 | Added EnableLoopback to INI file. Default = 0
1.20.04 23/10/02 Bug fix to CSCache_GetData() for GPI srce 0
Bug fix to CSReg_UnregClient() flags now moved
1.20.05 | 23/10/02 | BBC_CLNETMSG now sent sent in loopback too
1.20.06 | 29/10/02 | Mod to CSNDI_SendRevPacket() for loopback mode
2.00.00 01/02/03 Supports both 32 bit messaging schemes
Requires bncs_license.key file
Uses bncs2nbif.dll for networking
2.00.00B01 | 26/02/03 | Added Cmd_NetModify for updating any INI files
2.00.00B02 | 29/02/03 | Removed redundant debug messages
2.00.00B03 | 01/03/03 | Created common source for V2 & V3 CSIs
2.00.00B04 | 05/03/03 | Reduced compiler warnign messages by casting
2.00.00B05 | 10/03/03 | Bug fix to CSNDI_SendToDriver()
2.00.00B06 | 11/03/03 | CBDATA_SIZE_POINTER now 513b on WM_COPYDATA
2.00.00B07 12/03/03 Bug fix device array to allow device 999
Key data decode returs error codes
2.00.00B08 | 18/03/03 | Bug fix to error reported by key decoder
2.00.00B09 | 20/03/03 | V3 responds via WM_COPYDATA to BBC_GETHWNDCSI
2.00.00B10 | 21/03/03 | Supports 32bit messaging for FBCSlink/CSServer
2.00.00B11 25/03/03 Added max drivers and devices from license
No longer tries to delete NCBs twice on close
Lock file implemented in 32 bit
Now adds status channel name to name table
2.00.00B12 | 27/03/03 | Bug fix to name number of the status channel
2.00.00B13 | 02/04/03 | Bug fix to driver number checking in license
2.00.00B14 | 14/04/03 | Now supports 32 messaging for CSClient
2.00.00B15 | 22/04/03 | Bug fix to driver range checking
2.00.00B16 | 30/04/03 | Minor bug fix to BBC_FBMSGSCHEME handler
x.00.01 | 09/05/03 | Fix to internally loopback buffered commands
x.00.02 | 14/05/03 | Added KeyFilepath to CSI.INI
x.00.03 16/05/03 Added DisableWatchdogOnExit to CSI.INI
APP_READY message now PostMessage()
NULL removed from CSCmd_TimeService()
x.00.04 | 22/05/03 | Bug fix to numeric parser BNCS32ReceiveMessage
x.00.05 | 28/05/03 | TxRx/RxOnly timer re-enabled
x.00.06 02/07/03 V2CSI no longer resets network layer
No longer sends ODM if already in Rx Only
x.00.07 | 24/07/03 | Now creates csi_temp dir before decoding key
x.00.08 | 17/09/03 | Fix to loopback string length in CSMain_TxCmd
x.00.09 07/20/03 Converted to .cpp files, V4 directives added
Added resgistration for name of client app
Max clients now 999
x.00.09 04/02/04 Removed some redundant debug information
Now set to minimise on start up
x.00.10 20/02/04 CSI Closing messages now work in V4
01/03/04 Added Tools->Reset Network option to menu
Now update clients with N series messages
02/03/04 Recompiled with Qt3.2.3
x.00.11 25/03/04 BBC_APPREADY now SendMessage()
V2V3 Window positioning restored
x.00.12 01/04/04 Re-enabled the time service for V4CSI
05/04/04 BBC_CC.DLL no longer loaded in V2CSI
x.00.13 | 06/06/04 | Replaced strtok() with bncs_strtok()
x.00.14 | 09/06/04 | Added b_strtok as part of project
x.00.15 | 16/06/04 | Now detects network failure and resets
x.01.00 20/01/05 CacheSize parameter in CSI.INI has min of 8192
Selective caching added
Cache menu toggle now flushes cache files
16/01/05 INI file allows buffer flush on exceeding HWM
17/01/05 INI file allows cache flush on exceeding HWM
23/01/05 static chars in CSDbase for returned strings
24/01/05 Bug fix to SecBuf_In() Terbuff toggling on HWM
TERBUFF_AUTO_OFF reduced to 150
25/01/05 V1 compatibility switch added to CSI.INI
3.01.01 28/02/05 Bug fix top improved NDI filtering
29/03/05 Bug fix to CSNetSup_NetSendDG()
3.01.02 30/03/05 Removed compiler warnings
01/04/05 Raised MAX_CLIENTS& MAX_REGISTRATIONS to 999
Rasied REGMEMORYALLOC to 524288
3.01.03 | 18/07/05 | Reinstated BBC_FBMSGSCHEME & BBC_CLMSGSCHEME
3.02.00 15/11/05 Added Device Status messaging
BBC_NETTXRXSTATUS added to CSCmd_NetInquire()
Fix to CSCmd_NetInquire() & CSCmd_NetObject()
After NO the 'reverting to Rx Only' is only
written to the network once
NetBroken message added to reflect device fail

CSCmd_NetClose() generates BBC_NETTXRXSTATUS
Bug fix to CSCache_GetFileHandle()
Supports BBC_DEVCOMMANDMSG & BBC_DEVSTATUSMSG
Added Net Status handler
Added MaxClient limit to CSI.INI
3.02.01 | 07/12/05 | MaxClient entry in CSI.INI forced to be 1024
3.02.02 | 14/12/05 | Destination zero now allowed in UR revertives
3.02.03 | 27/01/06 | CSMain_(S)GetDevTxRxMode() allows device 999
3.02.04 | 30/01/06 | Boot time vars set before first status call
3.03.00 03/03/06 Now uses GetConfigDirectory in bncs_gcd.cpp/h
NetReset functions added
Session timeout now 60 seconds
Bug fix to CSCache_GetFileHandle()
CSCache_DeleteOldFiles() now uses constants
06/03/06 CSCmd_NetModify() now uses 32 bit messaging
06/03/06 CSCmd_NetStatus() now uses 32 bit messaging
3.03.00 09/03/06 All BNCS_V4 #ifdefs removed
14/03/06 GetConfigDirectory() GetBNCSConfigDirectory()
22/03/06 Added GetBNCSSystemDirectory()
NULL term fix to Cbncs_strtok::Tokenise()
3.03.01 20/04/06 Device check added to CSDbase_GetDatabaseName
Device check added to CSDbase_GetDbaseName
3.03.02 24/04/06 Cache file path now in bncs_config.ini
25/04/06 Bug fix to point all profile entries on path
3.03.03 | 09/05/06 | Fix to out of range in CSDbase_GetDatabaseName
3.03.04 | 16/05/06 | Turned of debug from CSDbase_GetDatabaseName
3.03.05 30/05/06 strlen+1 fix to CSMain_RxPostDirectMessage()
Modification to CSMain_RxPostDirectMessage and
CSMain_TxPostDirectMessage to pack size and
switch in wParam for when network enable off
3.03.06 | 15/06/06 | If NetworkEnable=0 then LoopBack is enabled
3.03.07 14/07/06 Fix to V1 revertives in CSCmd_RtrRevertive()
and in TerBuf_DecRtr()
3.03.08 | 29/08/06 | All database names now come from cached files
3.03.09 | 29/09/06 | NA messages now handled if client mode is off
3.04.00 | 07/02/07 | Build from CVS after Simon's handover
3.04.01 | 07/02/07 | Fix to prevent re-entrant sendmessages to cause a crash
3.04.02 13/02/07 Fix to stop crashing on no name in v1 device database
Removed case sensativity over v1 device file names
3.04.03 | 07/08/07 | Steve Jensen
3.04.04 17/03/08 Correction for Sessions issues. Changed
MAX_SESSIONS set to 8, was set to 4.
Changes to CSNetSes_SessionClosed().
3.05.00 27/05/08 Rationalised session management down to one queued pipeline
Added session layer checks to remove aborted sessions to CSNetSes_TimeoutChk()
3.05.01 | 25/06/08 | HANGUP_DELAY 100
3.05.02 | 25/06/08 | HANGUP delay now INI file parameter
3.05.03 | 09/07/08 | BBC_DATABASEPOLL messages now sent with the value of the revertive switch flag in lParam
3.05.04 | 12/09/08 | Corrected InfoGet bug by rationalising sessions
3.05.05 | 25/11/08 | Corrected for a memory leak bug in sessions
3.05.06 02/12/08 Enhancements to data bases loading function
CSDbase_GetDBList()supporting Fabian ADP.
Notes from Simon: The function checks for the presence of the high order database sections dynamically, ie it does not require a restart if CSI to enable a change to be visible to theFabian Server. It works by searching the files pointed to by CSI and checking for the presences of a [Database_x] section. The mere presence of the section header is sufficient for CSI to report that the database exists.
3.05.07 | 13/02/09 | Adds peer poll refresh feature
Copy taken at this point and merged with V4
1.0.0.2 | 02/03/09 | first recorded csi32 version
1.0.0.3 | 03/03/09 | corrects V3 file paths, loads correct DLLs (doesn't need bncs_cc.dll)
1.0.0.4 | 05/03/09 | uses sizedBuffer which by default has additional null character (doesn't add to the returned buffer size but ensures that buffer is null terminated if used directly as a string)
1.0.0.6 | 06/03/09 | adds csi config file (csi.ini or bncs_system.ini)
1.0.0.7 | 08/03/09 | adds serial numbers to packets (set by SendSerialNumbers in ini file)
1.0.0.8 | 10/03/09 | hex version number now returns 0x03000000 or 0x04000000 depending upon the environment type
1.0.0.9 | 10/03/09 | Nasty one this....a bit of sign extension going on with the serial number checking meaning that every 256th packet was being interpretted as an error
1.0.0.10 12/03/09 Fixes minor problem in reception of serial numbers so that startup of either this ws or another won't flag as an error
Introduces array of "device hosted on ws...." This is set by reception of any revertive.
Can now flushe cache for all the devices hosted by the errored ws when a packet error is detected
1.0.0.11 | 12/03/09 | Puts menu items for "send packet serial numbers" and "clear cache on network error".
1.0.0.12 | 12/03/09 | Adds routine to close down inf32fix.exe
1.0.0.13 | 13/03/09 | Changes default for sendserialnumber and clearcacheonpacketerror to off
1.0.0.14 | 17/03/09 | Puts a send buf high water mark and current (number of undeleted buffers) if this hits 10,000 then I don't think they'll get deleted any more
1.0.0.15 | 17/03/09 | Against my better judgement.....added ClearCacheOnNetClose flag
1.0.0.16 19/03/09 Adds simple check of the number of network buffers that is configured (max of 32)
Adds NN (network number) commands to the output command string- this is command packet serial numbers fixes network reset
1.0.0.17 | 23/03/09 | implements last missing function from V3
1.0.18.xx 26/03/09 changes version numbering so last digit is the build number
fixes small bug in cache code (no real impact
1.0.19.xx | 30/03/09 | Remove static array for async processing of poll commands (when satisifed from the cache) and now uses a queue. In testing I could get this up to 200-odd (previous limit was 32)
1.0.20.xx | 31/03/09 | Adds checking of existing driver window handle before rejecting a new request
1.0.21.xx 31/03/09 adds dump of stats on exit to log file
adds running total of serial number errors (for logging purposes only)
1.0.22.xx | 31/03/09 | disables all the relevant controls on the dialog when dianostics are disabled
1.0.23.xx | 09/04/09 | adds registration for notification of packet serial number events
1.0.24.xx | 17/04/09 | adds ability to query CSI for the extent of an individual device registration
1.0.25.xx | 21/04/09 | Great twonk Yates.... Now logs serial number errors using HEX rather than decimal so that CapLog and CSI32 at least report the same numbers...
1.0.26.xx 23/06/09 corrects adds config->edit option
adds config->view option
1.0.28.xx | 16/07/09 | Adds help
1.0.29.xx | 20/07/09 | adds ability to generate packet errors from menu item
1.0.30.xx | 07/09/09 | correction to V1 infodriver revertive handling code to ensure it doesn't read past end-of-buffer
1.1.0.xx 29/09/09 changes non-time critical, numeric, returnless SendMessages to
PostMessage
adds heartbeats
adds packet recovery tx buffer
adds packet recovery network channel
adds packet recovery request messages
recovers lost packets
1.1.1.xx | 27/10/09 | adds packet revertive memories to deal with out of order packet recovery responses
1.1.2.xx | 30/10/09 | Version for release with packet recovery, packet ordering correction
1.1.3.xx | 30/10/09 | status infodrivers off heartbeat messages
1.1.4.xx 02/11/09 more tidying up, removal of historic code and rationalising header files some more.
Now should packet recovery properly with router and gpi types too (oops).
1.1.5 19/12/09 Release candidate for W1
corrects mS to ms for those that are troubled about these things
changes shellexecute from "edit" to "open" for the Edit Config.
changes to docs to include Heart beat enable and timeout
1.1.6 | 21/12/09 | does logging of unrecoverable errors in the right place
1.1.7 | 18/01/10 | adds workstation status monitoring
1.1.8 | 01/02/10 | adds device status monitoring
1.1.9 | 02/02/10 | changes workstation and device monitoring code to do cleanup in thread to ease burden on main thread and timer callback
1.1.10 | 05/02/10 | adds status channel enable flag (for when using heartbeats
1.1.11 22/02/10 silly fix to supseded memories not remembing values in the packet that triggered serial number err
adds relevant recovered packets to the heartbeat and status infodrivers
1.1.12 25/02/10 changes workstation number in internal device status infodriver slot tobe 3 digit zero padded (for ease of decoding in functionally challenged clients)
adds explicit logging of network fail/ok messages
now does not reset memory of incoming serial numbers on network fail
1.1.13 05/03/10 Adds separate distributeTxRxStatus flag instead of inferring this setting from the heartbeat enable
Adds protection around the pollQueue
1.1.14 16/03/10 Another CM triumph.....1.1.13 did not have consistent version numbering (still said 1.1.12 on the titlebar) so this version rebuilt
Sets heartbeat to timeout in 2 seconds when a new driver is registered
(sends both heartbeats so as to not upset the timeouts of usually
out-of-phase driver/client heartbeats)
1.1.15 22/03/10 Adds databaseMgr/database classes to use as optional alternative to
pre-loading/compiling database files
1.1.16 | 22/03/10 | Small fix to not compile to disk high order databases if the memory option is set
1.1.17 | 30/03/10 | Moves the point that database load ducks out when using memory databases this ensures the database size is set
1.1.18 | 24/05/10 | Removes spaces from the end of loaded (bncs)database entries
1.1.19 | 03/09/10 | Fix to reuse of variable in net inquire code
1.1.20 | 10/09/10 | Fix to fix to reuse of variable in net inquire code
1.1.21 15/09/10 Support for new "capability" questions: BBC_GETMAXDESTS, BBC_GETMAXSOURCES, BBC_GETMAXSOURCENAMES, BBC_GETMAXDESTNAMES
Little has changed except that memory databases allows for BBC_GETMAXSOURCENAMES and BBC_GETMAXDESTNAMES to be 4096 (memory names off) or 65535 (memory names on)
1.1.22 | 21/09/10 | Fix to CSNDI_UniPollRevertive where filename in automatic variable was reused between calls
1.1.23 | 14/10/10 | Adds unload button to overview screen to clear loaded databases (next database call will start load-on-demand again)
1.1.24 | 04/11/10 | Fix to CSMain_TxCmd to range check device number (crash)
1.1.25 | 09/11/10 | Change to database/databaseMgr classes (not relevant to csi32)
1.1.26 | 18/11/10 | Fix to 1.1.24
1.1.27 | 07/12/10 | range checking in cacheclear function of device number (and logging of out of range values)
1.1.28 | 20/01/11 | error in when to check for serial number errors
1.1.29 19/05/11 fix to last version so that packet recovery doesn't try to correct errors from "out or order" recovered packets upsetting the "current" serial number
also adds some more meaningful debug to the superseded memories
1.1.30 | 16/05/11 | fix so that dialog enables appropriately when packet recovery is enabled
1.1.31 20/05/11 small typo fix to log message so it says "recovered packet after n attempts" where n is the retry count + 1
network close message added to heartbeats
1.1.32 | 23/05/11 | fix to 1.1.31 for posted poll on internal workstation infodriver
1.1.33 11/07/11 fix for device profile so database size/type is set correctly for memoryOnlyDatabases
now allows DG on internal status infodrivers
has new "send queued commands/revertives now" interface constants
BBC_SENDQUEUEDCOMMANDS and BBC_SENDQUEUEDREVERTIVES
fix to CSCmd_RtrModify to not crop db0 and db1 when using memory databases
debug string output when trying to send messages > 256
1.2.0 | 19/07/11 | Multi-standard build
1.2.1 | 20/09/11 | Arse. NC equivalent in heartbeats was simply deleting the whole device hosts class rather than just removing the current host
1.2.2 | 22/09/11 | Fix to 1.2.1 to delete the information for the incoming ws number not our ws number
1.2.3 | 11/11 | Range check to registration function fix (not independently released)
1.2.4 | 03/11/11 | CSCache_Test now traps internal infodrivers
1.2.5 08/11/11 BBC_NETMSGUPDATE now optionally sent (ini file flag) rather than just batted out regardless to all clients
NOTE: default for this value is OFF (because ApplCore doesn't use it)
Adds case BBC_NETMSGUPDATE_REG / BBC_NETMSGUPDATE_UNREG / BBC_NETTXRXSTATUS_REG / BBC_NETTXRXSTATUS_UNREG to allow for
selective registration of these message rather than just blast-all
1.2.6 10/11/11 Tidies registration functions for above new constants and cleans registrations down properly when client closes or is otherwise lost
Adds "starting" response to internal infodrivers
1.2.7 | 03/01/12 | Pragmatic if not ideal fix to not delete driver registration automatically if SendMessage return value is zero. This can happen when IPC breaks down (as well as when a driver disappears). Instead this state is also trapped by IsWindow call to see if that handle is valid.
1.2.8 | 09/01/12 | Same as 1.2.7 but for CLIENTS
1.2.9 | 19/01/12 | Flush revertive buffer before sending NC to the network
1.2.10 | 03/02/12 | Now uses absolute reference for up time rather than counting (rather inaccurate) "1 second" ticks
1.2.11 | 16/02/12 | Ooops.....hours have 3600 seconds in them not 3660
1.2.12 27/02/12 Changes HWND_BROADCAST messages to SendMessageTimeout
Adds configuration options to send/not send HWND_BROADCAST messages at all
1.2.13 | 27/02/12 | Small slip with section name of new config options
1.2.14 | 28/02/12 | Ineffective tinkering (tidying original code) to try and fix slightly odd startup behaviour on Windows 7 where selecting icon during startup results in small runtime dialog.
1.2.15 | There is no version 1.2.15
1.2.16 | 20/03/12 | adds client/driver list diagnostic dialog
1.2.17 | 21/03/12 | Small fix to application name in the client/driver listing diagnostics window
1.2.18 | 21/03/12 | Changes orientation of client/driver listing window
1.2.19 | 25/03/12 | Simple hooks to allow early POC testing for external alarms module
1.2.20 | 04/05/12 | makes memory databases consistent with "old fashioned" databases
1.2.21 22/06/12 Memory database code couldn't cope with single digit names (fault introduced in 1.2.20 in whitespace-cleaning code)
Range checks the value returned by cache for router
1.2.22 | 22/06/12 | Memory database was incorrectly rejecting zero-length names and returning --- instead
1.2.23 26/06/12 When sending out heart beat to notify of driver closing the packet was malformed sending out the wrong packet serial number
Handles heartbeats driver-side
1.2.24 | 29/06/12 | Tiny fix to ensure buffer is big enough to return router revertives when the db0 name is >16 characters
1.2.25 | 09/07/12 | Fix to registration function that with all 999 registrations would overwrite over the end of memory
1.2.26 | 17/09/12 | Doh....silly cut and paste error with the value sent for NB by BBC_NETTXRXSTATUS
1.2.27 | 03/12/12 | Now updates the network with heartbeats to both client and driver side
1.2.28 | 04/12/12 | ...fixes to 1.2.27
1.2.29 | 21/02/13 | rebuilds for consistent version number 1.2.28 was also labelled 1.2.27
1.2.30 | 25/02/13 | Now closes grd fix as well as infofix on CSI closedown
1.2.31 | 26/02/13 | Recursively creates temp directory actively sets the infodriver cache value to null so that cache get can't return duff values
1.2.32 | 04/03/13 | checks return value of file functions in reading cache values
1.2.33 | 15/10/13 | reworks packet recovery to use NetBIOS not AF_NETBIOS socket so that it works on 64 bit OSs (this was eroneously built but not released with title bar version of 1.2.32)
1.2.34 | 12/11/13 | now has memory cache functions using same code as memory databases
1.2.35 | 12/11/13 | hard won change to ensure that heartbeats are sent out for all registered devices even when there are 999 of them. For a driver that registers all 999 devices this means the internal infodrivers for status show all 999 devices running on that workstation
1.2.36 14/11/13 Tiny tweak to not parse all of the heartbeat messages when there are multiple sent
Now only sends "Request to register device xxx from driver hWnd 0xHHHH" messages to the network when CSI has debug mode enabled
1.2.37 | 26/11/13 | Makes buffer for NetDisable big enough to hold the caption data
1.2.38 06/12/13 Updates database functions to be the same as those just optimised for bncslink
cache function now returns the correct value on not reading a cache entry (though it absolutely should manage to read it
1.2.39 | 07/01/13 | tiny fix to disable packet recovery NCBs when diagnostics are disabled
1.2.40 | 10/01/13 | fix to packet recovery code to trap out-of-range workstation numbers (this should not be a problem...but....)
1.2.41 | 14/03/14 | adds generic config change message for CSI clients
1.2.42 | 17/03/14 | fix to iterator for config change notification
1.2.43 | 24/04/14 | minor changes to existing source to allow for VS2010 build (new messaging mechanism!)
1.2.44 | 02/05/14 | Adds redundancy master feature
1.2.45 | 15/05/14 | fix to redundancy master feature to only flop devices in the same group to rxonly not every device
1.2.46 23/05/14 minor change so that BBC_DEVICEIDINUSE is not sent on reception of NO message if the device is already RxOnly
this only goes to reassert the current state
1.2.47 20/10/14 now writes CSI handle to shared-memory DLL so that you don't have to broadcast for it
adds BBC_NOTWPARAM (WM_BNCS+400) as sanity check that this window handle is CSI without relying on class name
1.2.48 | 30/10/14 | allows for BBC_CONFIGCHANGE clients that are not normal (revertive) clients by defaulting to BBC_COPYDATA IPC
1.2.49 | 09/03/15 | adds support for 65536 databases
1.2.50 | 09/03/15 | changes default filename for databases (not previously used before 1.2.49) to DEV_nnn.DByyyy (i.e. zero padded four character database name)
1.2.51 | 31/03/15 | No functional changes
1.2.52 | 01/05/15 | changes icon to new style
1.2.53 | 26/06/15 | adds new feature to client/driver diagnostics to measure time taken for IPC
1.2.54 | 02/07/15 | no code changes
1.2.55 04/07/15 adds BBC_NETTXRXSTATUS_BROADCAST_ENABLED to programatically get the state of DistributeBBC_NETTXRXSTATUS ini file setting
adds BBC_NETMSGUPDATE_BROADCAST_ENABLED to programatically get the state of distributeNetMsg ini file setting
1.2.56 | 06/07/15 | all standard profile/file functions should now resolve environment variables
1.2.57 | 17/12/15 | adds "deaf to self" setting so that CSI32 can be used as a gateway interface
1.2.58 | 04/02/16 | adds BBC_SETREDUNDANCYMASTER new API feature so that redundancy mastering can be set on the fly by drivers that understand it
1.2.59 05/02/16 fix to redundancy mastering when receiving a NC (net close)
scope fix to BBC_DATABASECHANGE notification in case someone comes along and changes something synchronously
removes message to network about master device change since this info can be picked up in heartbeats and kinda misses the point of generating lots of traffic when such status changes
1.2.60 | 06/02/16 | revertive messages now set target workstation in wParam (previously hard-coded tozero) so that you can tell if this was a poll response or change of state
1.2.61 12/04/16 When setting the TxRx state of a device don't bother the network with a change of state when the state hasn't actually changed.
This is important for requesting rxonly when already in rxonly state
1.2.62 | 14/04/16 | fix to 1.2.60
1.2.63 | 21/04/16 | Fix to 1.2.61 to re-assert txrx states when it's needed
1.2.64 21/07/16 if no V1/V2 flag database flag for any device is set then just do a quick check on incoming database change message to see if
the dev file exists so that you can add files to a running server without having then to restart it
1.2.65 15/12/16 Flag to force devices to V2 even without presence of a DEV_xxx.INI file so that commands are always sent buffered. There's a long-standing gotcha where commands are all sent in individual packets without the DEV_xxx.INI file.
Default for this value is the new "default=v2" rather than wholly backwards compatible
1.2.66 | 20/02/17 | Fix to CSNetSup_NetSendDG so that you can't send messages bigger than 512 bytes
27/02/2017 | Docs conversion to markdown
1.2.67 | 17/07/17 | Various small but important changes (buffer len, memory leak) following analysis using cppcheck (thank you Mr. Simon Armstrong)
1.2.68 | 21/01/18 | Adds BBC_GETMAXDEVICES call so that you can programatically work out how many devices this CSI supports (I suggest you default a null-return from this call to 999)
1.2.69 | 26/02/18 | Corrects version number anomaly (trouble with this vintage of app having it set in two places). Corrects build settings to use 32 time value for time-conversion calls rather than Windows new default of a 64 bit value for VS2013 builds.
1.2.70 | 18/04/18 | Now distributes BBC_NETTXRXSTATUS messages on incoming "NO" message if the dest workstation is you or zero. If it's you that generates the NO then you won't receive your own message as you won't be changing state
1.2.71 | 04/05/18 | Reworking of BBC_NETTXRXSTATUS messages on incoming "NO" message - if there is a dest workstation you'll get 2 notifications - one for the TxRx workstation, and one for the one being forced RxOnly.
1.2.72 | 11/05/18 | Anti-howlround measures for RM commands - used when sites are linked using FABIAN/slink
1.2.73 | 18/05/18 | Long-standing inexplicable hole in cache-get function - only returns the database name for the given router or GPI value not the numeric index. Now uses (previously unused) return value to give that value
1.2.74 | 07/06/18 | Temporarily (I hope) removes structured exception handling so that the likes of WinCrashReport can be used to grab a call-stack.
1.2.75 | 28/06/18 | Just a chance closedown code was lobbing itself a message from the network thread whilst deleting the objects that might try and be used in processing it. This version cleans up more tidyerer
1.2.76 | 10/09/18 | Path fix for VS2013 builds for key file path. Moves temp path (e.g. session files) to Windows temp directory
1.2.77 | 28/10/18 | Range checking for workstation & device status infodrivers was entirely believable, but using the wrong ranges - now corrected
1.2.78 | 30/10/18 | Because of a flaw in infodriver32 where it would assume the because it's asked to be TXRX then it is TxRx, CSI now ensures it returns DEVICEINUSE if this request comes in when there's a redundancy master
1.2.79 | 16/11/18 | Very long standing hole with BBC_HWNDCSI being sent with 32 bit IPC but with the data type erroneously set to the data size value
1.2.80 | 20/11/18 | Now uses version resources to build about-box rather than a very historic hard-coded string
1.2.81 | 22/11/18 | For no easily explained reason, NS commands (direct device messaging), both commands and responses, were sent as individual packets. Now they're sent packed, the same mechanism as commands/uni-msg. This limits the payload size to approx 220 charactes
1.2.82 | 23/11/18 | NS commands weren't properly filtered - would happily receive and forward any-old-thing. Now more discerning. Also forwards NS values where no destination is set for any client that has an existing registration for that device
1.2.83 | 26/11/18 | Misunderstanding of the range of internal HWM value meant the last (or only) client wasn't getting NS distribution with registration
1.2.84 | 17/01/19 | Logs failure of set time (from CSI network time signal)
1.3.0 | 18/01/19 | Lost in the mists of time is why CSI32 needed an external DLL rather than just incorporate the code directly (distant memory says this relates to 16 bit Windows). Various configuration management issues led me to just include the code as static lib rather than DLL. This release removes dependency on bbcnb32.dll.
1.3.1 | 24/01/19 | Wasn't creating data queue mutex (that was done originally in DLLMain)
1.3.2 | 13/03/19 | Removes redundant config keys HWMBufferFlush HWMCacheFlush BST-344
1.4.0 | 21/05/19 | Number of devices increased to 4094 (device 4095 used to denote serial number packets). Maximum registrations per client remains at 999 (a single client can no longer register for every available device).
1.4.1 | 29/05/19 | Adds gateway commands to allow use of CSI as network interface for DDS bridge
1.4.2 | 30/05/19 | Filters NN messages (command serial numbers) so they don't get as far as the driver
1.4.3 | 05/06/19 | wParam value of BBC_GATEWAYRECEIVE now contains both originating and target ws
1.4.4 | 07/06/19 | Fix to BBC_GATEWAYSEND
1.4.5 | 10/06/19 | Adds sending of BBC_CSICLOSING to gateway device
1.4.6 | 11/06/19 | "Special" gateway mode that disables CSI's external interfaces (by not passing on the CSI's handle), and closes the single-instance-mutex. Upshot is that you can run CSI32 and DDS CSI on the same machine at the same time: use CSI32 as the gateway, use DDS CSI for running devices/clients
1.4.7 | 11/06/19 | Gateway implementation of GR and RR
1.4.8 | 02/07/19 | BST-346 Removes last vestige peerpollrefresh feature. Minor docs update BST-344
1.4.9 | 05/09/19 | Router Database forwarding to gateway added
1.4.10 | 06/09/19 | Gateway hookin value changed so you can't hook into the wrong CSI (bad things happen)
1.4.11 | 28/10/19 | BST-656 Now removes all drivers linked by redundancy mastering if the driver crashes (with usual IPC breakdown check). This also generates the required NC message to trigger the redundancy to switch over.
1.4.12 | 19/02/20 | BST-669 Rudimentary implementation to remove menus if the CC_SECURE flag is set
1.4.13 | 24/02/20 | BST-669 Honing of feature in 1.4.12
1.4.14 | 27/02/20 | BST-669 Inconsistency of retrieving CC_SECURE value (as string or int) resolved to require explicitly CC_SECURE=0
1.4.15 | 30/07/20 | BST-854 Long-standing issue removing client registration from dead client then prevents delivery of the revertive to the next client in the array.
1.4.16 | 10/09/20 | BST-883 Word-soup unpicked for debug message rejecting BBC_SETREDUNDANCYMASTER. Also adds the params used with this call to aid debugging
1.4.17 | 23/09/20 | BST-638 Removes dual revertive from device status infodriver when a driver closes (was processing both client and driver-side NC messages)
1.4.18 | 25/09/20 | BST-891 Makes response to NetObjection the same whether redundancy mastering or not (basically just send the RxOnly message to the network in both cases)
1.4.19 | 28/09/20 | CORE-253 Will now not allow you to run "real" infodrivers when the same device ID is used internally for driver/workstation status
1.4.20 | 15/10/20 | Fix to range checking into workstationStatusList array
1.4.21 | 22/10/20 | Reinstates TempFilePath config setting for use with "sessions" as it transpires the path needs to be consistent between machines on a system (docs updated to refect this)