Skip to content

Architecture

Jump to bottom
Matthew Aguirre edited this page Feb 9, 2018 · 3 revisions

EMANE/VBS3/CNR Integration

This provides a user-space wrapper for transmitting data from CNR to CNR via EMANE.

Windows Side Architecture

CNR pushes PDU datagrams to a multicast channel which can be read, tunneled, and re-broadcast.

Listening to CNR

  • CNR-side client listens to CNR via multicast on loopback device (lo; 127.0.0.1).
  • When the CNR-side client receives a PDU, it sends it to the bridge server.

'Playing' to CNR

  • The CNR-side client listens for incoming packets from the bridge server
  • Incoming packets are on the same multicast channel for CNR
  • CNR will interpret these packets as appropriate and play any sound that has been transmitted.

EMANE Side Architecture

This is nearly identical in architecture as the CNR-Side. The difference is instead of listening on a multicast channel for packets, each node must be communicated to using unicast.

On initialization, each application calls Rebroadcaster.INSTANCE.resetSocket(Rebroadcaster.CastingEnum.Uni, clients.length > 0 ? clients[0] : null);

This will setup a ServerSocket instance for the client to listen to other ENAME clients on.

Listening for Data from the bridge

  • Packets received from the bridge server will be forwarded to the Rebroadcaster.INSTANCE object which will perform a round-robin approach of 'broadcasting' the packet to all EMANE nodes.

Relaying Data back to the bridge

  • The ServerSocket in the Rebroadcaster instance will receive the data sent internally within EMANE and then forward the data back out through the bridge to the corresponding CNR client.

The Bridge Server

The bridge server will receive the packet on an out-facing network interface.

  • On each node in the XCN, an EMANE-side client connects to the bridge server.
  • Each CNR-Side client connects to the bridge server.
  • This should be a one-to-one, so that for each CNR-Side, there is a corresponding EMANE-side node which it connects to as its own node.
  • Each CNR-Side will transmit its data from CNR to the bridge server.
  • The bridge server will then transmit the data to this CNR's paired EMANE-side client
  • The bridge server also acts in reverse and will transmit data received from the EMANE-side client to the corresponding CNR-side client. This is where the CNR-side client will re-broadcast in multicast for CNR to 'hear'.

Threads

The nature of handling IO to/from many fronts with minimal delay requires the use of many different threads for monitoring and handling the flow of data.

Bridge Server

  • 3x for each pair (cnr + emane)
  • +1 main thread which controls them.

CNR Client

  • 1 thread to read from CNR (multicast) which will also send data to the bridge
  • 1 main thread which reads data from the bridge server

Emane Client

  • 1x thread for each EMANE node to write to (unicast)
  • 1 thread to listen for unicast from other nodes
  • 1 main thread to listen to incoming from bridge server

Clone this wiki locally