Both hardware data diodes and software emulation can provide very reliable connections for either live or historical data, using TCP when possible, or UDP if necessary.
However, since a data diode strictly enforces one-way communication, it is impossible to guarantee zero data loss under all conditions. There is simply no way to pass acknowledgements for real-time or historical data transmissions through a software or hardware data diode. If the connection fails, some data will be lost until the connection gets restored.
When sending data through a hardware data diode, the sender must periodically refresh the connection to deal with the possibility that the receiver has failed and recovered. During the time between the failure and the refresh period, all data will be lost. This can be mitigated by using no authentication on the tunnel, which allows data flow without waiting for the connection to be formally refreshed by the sender.
When historical data is lost, the user can manually back-date the start-of-transmission point in the store-and-forward buffer to begin re-transmitting from that time forward. This will cover the missed data, and will also duplicate some data.
With these limitations in mind, the following tables display the reliability you can expect from various data diode scenarios, and what we recommend as the best choice of protocol for each.
| Diode type | Protocol | Data Reliability | SSL Possible? | Comments |
|---|---|---|---|---|
| No diode | TCP | Very high | Yes | Best choice for normal real-time data transmission - data loss during connection failures. |
| No diode | UDP | Very High | No | Not recommended - TCP is more reliable. |
| Software emulation | TCP | Very High | Yes | Best choice for a software data diode - data loss during connection failures. |
| Software emulation | UDP | High | No | Not recommended - TCP is more reliable with less bandwidth usage. |
| Hardware data diode | TCP | High | No | Best choice for a hardware data diode if the diode supports it. Data will be lost during connection outages. It could take some time before communication is re-established after a failure. |
| Hardware data diode | UDP | High | No | The common choice for a hardware data diode - Data will be lost during connection outages. It could take some time before communication is re-established after a failure. |
| Diode type | Protocol | Use ACKs? | Data Reliability | SSL Possible? | Comments |
|---|---|---|---|---|---|
| No diode | TCP | Yes | 100% | Yes | Best choice for normal historical data transmission. |
| No diode | UDP | Yes | Very High | No | Not recommended - TCP is more reliable. |
| No diode | TCP | No | High | Yes | Not recommended - data loss of one message in flight during a connection failure. |
| No diode | UDP | No | High | No | Not recommended - data loss during network failures. Use TCP with acks instead. |
| Software emulation | TCP | No | High | Yes | Best choice for a software data diode. data loss during connection outages |
| Software emulation | UDP | No | High | No | Not recommended - TCP is more reliable. |
| Hardware data diode | TCP | No | High | No | Best choice for a hardware data diode if the diode supports it. Data will be lost during connection outages. It could take some time before communication is re-established after a failure. |
| Hardware data diode | UDP | No | High | No | The common choice for a hardware data diode - Data will be lost during connection outages. It could take some time before communication is re-established after a failure. |