Connect an isolated site outward

Scenario 2: connect an isolated site outward

Use this when inbound access to the site is blocked but the computer beside the device can make an outbound connection to a central server.

1. Configure endpoint A as the on-site serial port.
2. Configure endpoint B as a TCP Client with the central server host and port.
3. Create an A ⇄ B bridge with Transparent protocol and Forward immediately framing.
4. Enable automatic reconnect, then verify that the TCP Client reconnects after disconnecting and restoring the network.
5. Watch queue depth and dropped-byte counters in the bridge manager to check whether offline traffic exceeds the buffer.

The serial device may keep transmitting while the network is down. TCP can push pressure back by stopping reads, but a serial source without flow control cannot reliably be slowed. When the buffer fills, data must be dropped or the bridge stopped. For production commands that must not be lost, prefer Stop the bridge and tell me. For live telemetry, Drop the oldest data is often more useful.

Common checks after creating a bridge

• Both endpoint panes are open and show bridge badges. The manager should report Active rather than Degraded or Suspended.
• The direction matches the topology. A one-way bridge does not return responses automatically.
• Dropped counters should remain zero. A non-zero value means the sink is too slow, the buffer is too small or the source cannot be throttled. Fix the cause before merely increasing the buffer.
• Keep One client at a time for TCP servers by default. If several request/response clients must share the device, use Take turns together with idle-gap, delimiter or fixed-length framing. All clients share the port can interleave requests on the serial wire.
• Save the endpoints and bridge together in a .spu project for repeated use, and re-check the physical port assignments after loading it.