A key benefit provided by Sox tunneling is the ability to establish a Workbench client session with one or more devices that are hidden from public access. This is done by allowing the requesting Workbench platform (client) to communicate (or “tunnel”) through an intermediate station (JACE or a Supervisor) with networked Sedona Framework devices. The station acts as a proxy server to those targeted devices.
An example use of this feature would be where IP connected Sedona Framework devices are networked under JACEs in a building. You may want to have the ability to "tunnel" the Sox connection so that when you are outside the facility you can access the devices for programming changes without having to expose the IP address of each Sedona Framework device. If you network many devices "under" a JACE, your IT department may not allow exposure of dozens or more control devices to the Internet.
If a Sedona Framework device is networked to the JACE via the secondary IP/LAN port on the JACE, the ability to tunnel Sedona
(Sox) may be the only solution to make a Workbench client connection.
Sedona Framework stations and devices serve in the following roles to comprise the typical points of reference in a tunneling scenario:
Client
This is the initiating party (for example, Workbench) that sends a communication request using “Sox tunneling” syntax to open a connection with the proxy server.
Proxy
This is the tunneling proxy server station, running on a JACE or Supervisor, that recognizes the Sox tunnel syntax and routes the message on to the tunneled host.
Device
This is the target device (or node) that is typically on a protected network that is not directly accessible to the client.
Copyright © 2000-2014 Tridium Inc. All rights reserved.