bncs_nb_dds_bridge

BNCS NetBIOS to DDS bridge

This module is for test/evaluation

Overview

This is to bridge "V2" BNCS messaging (csi 1.16 and later, v2csi, v3csi, v4csi and csi32) to the xDS/DDS messaging used by bncs_csi.

You would use one-per system (or more likely a redundant pair) to convert NetBIOS network messages to xDS/DDS network messages. You can then use clients and drivers connected either using CSI32 or bncs_csi and they'll interwork. It is ideal therefore as a migration tool between CSI32 and bncs_csi.

This bridge conveys only "normal" BNCS command & "revertive" traffic, it does not convey redundancy messages required to run the same driver either side of the bridge (one side or the other, but not a redundant pair connected using different CSIs). See "Messages Conveyed" below.

Compatibility

This module requires CSI32 1.4.23 or later as it uses CSI32 to receive and decode the network packets (to benefit from packet recovery etc).

Limitations

Redundancy/heartbeats work differently between these mechanisms so it's assumed you cannot run redundant drivers split either side of this bridge. The basic messaging between them is very similar, but the dynamics are wholly different. You can still run redundant drivers on one side or the other of the network of course, just not split across the two.

Command Line

/domain=0

Optional: Domain can be read from the ospl.xml file for the DDS version.

/device=123

Mandatory: Sets the BNCS device number (infodriver) used to control redundancy

Messages conveyed

CSI is very chilled about what messages it sends. If you have access to the raw API and send a

ZZ 'hello'

command - it'll launch that on the network regardless and it's up to the receiving CSIs whether they do anything with it.

bncs_csi is more discerning because it sends explicit messages, typed and checked, not just a unvalidated string.

Commands

Command | Use
IW | Info Write
IL | Info Lock
RC | Router Crosspoint
RL | Router Lock
GS | GPI switch
GL | GPI lock
RM | Router Modify
NS | Net send

Responses

Command | Use
IR | Info Revertive
RR | Router Revertive
GR | GPI Revertive
RD | Router Database (propagation of remote database updates)
NS | Net Send

Notable omissions

Command | Use
TS | time server

The bridge doesn't blindly proxy 'N' messages.

BNCS Device Redundancy

Message delivery between CSI32 and bncs_csi are different in that CSI32 relies on very slow update to 'N' messages, with each message being sent in its own packet. bncs_csi on the other hand sends as many 'N' message (equivalents) as it has drivers, all sent at once. Merely bridging all these messages between the two transports wouldn't work: csi32 would simply swamp the network with 'N' message packets.

So, it is not possible to simply proxy 'N' messages across the bridge. It is not practical to make redundancy work where drivers are split across two different transports.

Redundancy messages are however used for status monitoring - so it's still desirable to convey this status information across the link.

bncs_csi drivers as seen by CSI32 clients

With a driver on a bncs_csi workstation the bridge application dynamically creates a driver on the CSI32 side. This is done as soon as the bridge detects any redundancy messaging on the bncs_csi network.

This has two effects:

  • means normal status monitoring works (the information that gets reflected in csi32's internal device status infodrivers)
  • should prevent erroneous running of a driver on the csi32-network by generating appropriate 'N' messaging - e.g. a csi32 driver sends NI, the bridge will object with an NO.

Drivers registered as drivers on the gateway's CSI32, are slaved to the master device which is the status infodriver of the gateway.

csi32 drivers as seen by bncs_csi clients

As noted, csi32 'N' messages are on a very long cycle time, but there is a secondary mechanism used to convey status: heartbeats. The heartbeat contains redundancy status for every driver on a workstaion, and all contained within a single packet.

The bridge receives these heartbeats and remembers the driver status. The bridge also splits the heartbeats up and re-presents them as 'N' messages on the bncs_csi network.

So, this has the same effect for bncs_csi as for csi32: status monitoring works and a degree of protection from running drivers of the same device ID either side of the network.

However...

Cycle time for csi32 heartbeats and bncs_csi redundancy messaging is still quite long - typically 30 seconds. So it takes that time for the bridge to get the full picture of drivers on either side of the link. The bridge is able to offer a certain degree of protection regarding drivers erroneously running either side of a link, but it's imperfect.

Gateway Redundancy

Rather than invent a new redundancy mechanism, this driver uses normal infodriver redundancy to control the TxRx state of a pair of drivers. Redundancy is controlled by a device on the CSI32 side of the network.

Environment

This DDS version requires the following environment variables:

Variable | Value
OSPL_URI | file: //<your system root>\config\dds\ospl.xml Note: This should not have a space after the file: but unfortunately this doesn't format well in these docs.
ADLINK_LICENSE | <your system root>\config\dds\license.lic This value does not seem to require the file: prefix of the previous entry

These are set by workstation manager on the fly if this application is run from within that so you don't need these configured in your environment.

Note: If you do configure them in your environment you risk using the configuration/qos files from one system on a different system - so really don't set them unless you really have to.

Dependencies

The following files are required in windows\lib

File | Notes
netlegacy.dll | Wrapper for network access
cmsoap.dll | DDS
cmxml.dll | DDS
dcpssacpp.dll | DDS
ddsi2.dll | DDS
ddskernel.dll | DDS
spliced.dll | DDS
ddsrrstorage.dll | DDS
snetworking.dll | DDS
dds_security_core.dll | DDS
qt5core.dll | Qt
qt5gui.dll | Qt
qt5network.dll | Qt
qt5widgets.dll | Qt
Qt5XmlPatterns.dll | Qt
qwindows.dll | Qt (in subfolder platforms\windows)

Version History

Version | Date | By | Notes
1.0.0.x |  | DY | Development versions
1.0.1.0 | 25/11/20 | DY | Explicitly turns off CSI32 cache (this doesn't generate any network traffic, for this network traffic proxy app). Adds each device it sees xDS/DDS side as a driver on the CSI32 side so that normal status messaging works (for device infodriver, heartbeats, redundancy rejection). Infodriver is now compulsory (redundancy mastering)
1.0.2.0 | 27/11/20 | DY | Redundancy passes for status purposes - but devices still won't behave if run across links. Adds discovered device list to the UI. Adds redundancy message counters.
1.0.3.0 | 30/11/20 | DY | Tidies the UI - but the counters don't fully work (multiple inheritance issue relating to wanting to leave DDS alone)
Build: bncs_4.7.5 5800 a1b48197a Atos|Syntel © 2021