Data Diode Protocols: How One-Way Transfer Handles TCP, OPC, Syslog and Files

01Key takeaways

1. 01

   Most useful protocols are bidirectional, so the engineering challenge is carrying them across a boundary that never replies.

2. 02

   Proxies on each side emulate the missing half of the conversation locally, so the diode itself stays strictly one-way.

3. 03

   TCP is terminated and converted to a one-way stream; reliability comes from forward error correction and buffering, not acknowledgements.

4. 04

   Syslog, file transfer and OPC each have established one-way patterns with integrity checks to make loss detectable.

5. 05

   Evaluating a product means asking which protocols are supported natively and how failure and integrity are handled.

02Why bidirectional protocols are the hard part

A protocol is a conversation with rules. TCP opens with a handshake and confirms every segment. File transfers confirm receipt. Even "send and forget" protocols often assume some feedback. A data diode removes the ability to reply across the boundary, so every one of those assumptions has to be handled somewhere else.

The solution is consistent across products: terminate the protocol locally on each side of the diode and bridge only a one-way stream between them. The source never learns there is no return path because a local proxy answers on its behalf.

The diode stays one-way; the proxies on each side absorb the protocol's expectation of a reply.

03TCP without acknowledgements

TCP cannot cross a diode as-is, because it depends on acknowledgements travelling back. Instead, a proxy on the send side accepts a normal TCP connection from the source and acknowledges locally, then converts the payload into a one-way stream.

On the receive side, a second proxy reconstructs a TCP connection toward the destination. Neither proxy passes acknowledgements across the boundary; they each complete the conversation on their own side. Reliability of the one-way hop is handled separately.

04UDP and syslog streams

Connectionless protocols such as UDP-based syslog map more naturally onto one-way transfer because they do not expect a reply in the first place. They are a common first use case for diodes.

Even so, the design must add what the protocol lacks: sequencing and integrity so the receiver can detect dropped or corrupted records, and buffering so a brief outage does not silently lose events. One-way friendliness does not remove the need to make loss visible.

05File transfer and integrity

Moving files one way is a staple of unidirectional transfer. The send side reads a file and streams it across; the receive side reconstructs it. Because there is no confirmation back, integrity has to be built into the stream.

• Checksums or hashes so the receiver can verify each file arrived intact.
• Sequencing so missing files or segments are detectable rather than silent.
• Buffering and retransmission within the one-way stream to survive transient errors.
• Quarantine or validation of received files before they are used downstream.

06OPC and historian replication

Industrial data flows such as OPC and historian replication are session-oriented and expect ongoing two-way state. One-way products handle them with protocol-specific adapters that maintain the session locally on each side and replicate the data values across the boundary.

This is why historian replication over a diode works: the source historian talks to a local proxy as if it were a normal peer, the values cross one way, and a destination proxy feeds a replica. The protocol's two-way nature is satisfied on each side, not across the gap.

07Forward error correction and buffering

Because the receiver cannot ask for a retransmission, one-way systems use forward error correction: they send enough redundancy that the receiver can reconstruct data despite some loss, without any reverse request.

Buffering complements this: data is held on the send side so a destination outage does not drop events, and the stream catches up when the destination returns. For environments that prefer an offline-by-default boundary, an AIRGAPNET controlled connectivity approach can schedule the transfer window instead of maintaining a permanent one-way link.

08Protocol evaluation checklist

• Which protocols are supported natively versus through awkward workarounds?
• How is TCP terminated and converted, and where does reliability come from?
• How are integrity and sequencing handled so loss is detectable, not silent?
• How much buffering exists, and what happens when the destination is down?
• For OPC or historian flows, is there a proper adapter or a generic file shim?
• Can the team prove what crossed the boundary and verify it arrived intact?

09Closing thought

One-way transfer is easy to describe and subtle to engineer. The diode is the simple part; carrying TCP, files, syslog and OPC across a boundary that can never reply is where products genuinely differ.

Judge a one-way system by how it handles the protocols you actually run and how it makes loss visible. The boundary is only useful if the data crossing it is complete, verifiable and trustworthy.

FAQFrequently asked questions

SRCSources of record