Skip to main content
Back to engineering notes

Engineering note

Message direction and connection role

Application data direction, connection role and transport constraints.

Networking / Modelling

Independent configuration axes

Application data direction and connection establishment are independent. The original model coupled incoming data to TCP clients and outgoing data to TCP servers. I separated those choices to support both pushed streams and connections to remote feeds without changing message-processing responsibilities.

Connection role and application direction

TCP connection roles viewed from one application
Application direction Client / connector Server / listener
Incoming / input Connect to a peer, then receive its stream. Accept a peer connection, then receive its stream.
Outgoing / output Connect to a peer, then send processed messages. Accept a peer connection, then send processed messages.

This matrix describes the documented TCP arrangements for the supported XML and protobuf protocols. TLS follows the effective client or server role, including the identity that role presents. A rejected peer handshake must not take down the listener for subsequent peers.

UDP input listens for datagrams and output sends them. UDP has no TCP connection-establishment handshake and does not use the TLS configuration. The EOF-delimited XML protocol is restricted to TCP.

Diode interface terminology

Input and output refer to the application processing boundary. Diode ingress and egress use the diode's perspective: application output sends to diode ingress, while application input receives from diode egress.

Across one diode

  1. Application output Prepare and send the approved payload.
  2. Diode ingress The sending interface of the physical diode.
  3. One-way transfer The hardware boundary controls the transfer direction.
  4. Diode egress The receiving interface of the physical diode.
  5. Application input Receive, validate and transform the delivered payload.
Boundary-relative terminology. Import and export describe the intended cross-domain path; ingress and egress identify the diode interfaces. Incoming and outgoing in the application model describe data direction, not a universal high-side or low-side assignment.

Transport-specific framing

Both TCP roles reuse the applicable framer. Continuous XML, length-prefixed protobuf and EOF-delimited XML retain distinct completion rules. EOF completion applies to the EOF-delimited protocol.

Effective-role resolution preserves protocol and transport defaults for saved configurations that omit an explicit role.

Loop prevention

The implemented endpoint guard checks the numeric destination before connecting and compares it with local listeners. Wildcard bindings need comparison against the host's interface addresses; checking the configured hostname alone would miss aliases resolving to the same machine. UDP pins the approved destination.

Application routing separately prevents diode-to-diode forwarding and gives active export paths precedence over local outputs. Remote relays, NAT paths and other instances fall outside the local guard's scope.

Separate tests cover inverted TCP roles and datagram delivery, reflecting the restrictions of each transport.

Related case study: networking and message processing.

Examples are generalised or synthetic and omit operational details and identifying information.

← All engineering notes