
NetLinx Security within the Web Server
101
NI-3101-SIG Signature Series NetLinx Integrated Controller
What is Dynamic Device Discovery?
The Dynamic Device Detector (DDD) monitors the system for newly connected devices. New devices
can be detected via either an external discovery protocol manager (
built into firmware
build 320 or higher
), Multicast reception of a Dynamic Device Beacon, or via the receipt of a beacon
response on an application specified list of serial devices. This DDD process begins by detecting new
devices within a NetLinx/Duet system, binding those devices to application instances, and then starting a
Duet module to control those new devices.
Dynamic Device Discovery was created to take advantage of Java's Dynamic Class Loading and the
Duet Standard NetLinx API (SNAPI). Java loads classes as they are needed. Therefore it is feasible to
load a Duet control/protocol module on the fly as each new device is discovered. SNAPI provides a
fixed interface for communicating with a certain type of device. The "glue code" refers to the developer
defined NetLinx program that runs on a Master and controls a system.
Take for example a VCR. The majority of control features are common to all VCRs (play, stop, pause,
etc.). SNAPI provides the "glue code" developer the ability to write common code that will control any
type of VCR having an associated Duet module. The underlying Duet module could be swapped in and
out based on the actual physical device with no changes needed to the higher level "glue code".
Dynamic Device Discovery Concepts
Feature
Description
Application Device:
• A Duet Device (41000-42000) that is used as a control interface
to a physical device. This is also referred to as the
Duet virtual
device
.
• All control requests are made to the application device rather
than to the physical device.
Binding:
• In concrete programming, the application device is forever
associated with the NetLinx physical device. In DDD, this
association is dynamic.
• The act of associating an application device with a physical
device is called “binding".
Device Discovery:
• In DDD, physical devices are detected in the system at
run-time.
• There are two different methods of detection: via Dynamic
Device Discovery Protocol (DDDP) or via user definition within
the Master’s Web interface (page 108).
SDK Class:
• Each application device in the DDD world is associated with a
particular device type as defined by SNAPI.
• When using a VCR or a Receiver as an example, each of these
device types would correspond with a Java Interface within the
Duet Device Software Development Kit (SDK).
• When writing programs for DDD, the developer specifies the
device type of a particular application device by using one of
these SDK Class names.
Polling:
• Dynamic physical devices can be detected by DDDP through
both Serial and IP interfaces.
• While IP connections are then able to utilize the network’s
higher layers of multicast to broadcast their existence, Serial
devices speak a fixed protocol that is incompatible with DDDP.
• Serial devices are passive and will only broadcast their
existence if polled to do so. The program developer must
specify which NetLinx interfaces/ports (i.e. serial ports) should
be polled for devices.