Struct SnapTunNgServer 

pub struct SnapTunNgServer<T> { /* private fields */ }

The SnapTunNgServer manages one Tunn per remote socket address.

The main structural difference between WireGuard (R) and snaptun-ng is that there is a one-to-one relation between a remote socket address (of the initiator) and a tunnel. The SnapTunNgServer manages that relation.

Scaling

The main methods SnapTunNgServer::handle_incoming_packet, SnapTunNgServer::handle_outgoing_packet, and SnapTunNgServer::update_timers all require an exclusive reference to the internal state. The reason is that processing both, incoming and outgoing packets requires access to the session state.

One simple way to achieve load distribution across different cores/threads is to shard over multiple SnapTunNgServer-instances based on a hash of the remote socket address.

Future improvements

• Separate incoming and outgoing code paths and optimistically lock the session state.

How to use

The SnapTunNgServer is i/o-free; i.e. it only manages state. The following is a pseudo-code like description of the simplest i/o-layer integration:

let mut server = SnapTunNgServer::new(/*...*/);
let mut send_to_network = VecDequeue::new();
let mut current_sockaddr = ;
loop {
  switch {
    (network_packet, sockaddr) = network_socket => {
      server.handle_incoming_packet(/*...*/);
      /* dispatch packets to tunnel if necessary */
    }
    tunnel_packet = tunnel_socket => {
      server.handle_outgoing_packet(/*...*/);
    }
    timer = tick(250ms) => {
      server.update_timers();
    }
  }
  // dispatch packets to network
  for p in send_to_network {
    network_socket.send(sockaddr, p);
  }
}

Implementations

impl<T: SnapTunAuthorization> SnapTunNgServer<T>

pub fn new( static_private: StaticSecret, rate_limiter: Arc<RateLimiter>, authz: Arc<T>, ) -> Self

Creates a new SnapTunNgServer instance.

pub fn handle_incoming_packet( &mut self, packet: Packet, from: SocketAddr, send_to_network: &mut VecDeque<WgKind>, ) -> TunnResult

Handle incoming packet for a tunnel assocated with remote socket address from.

This method never returns TunnResult::WriteToNetwork. Instead, it codifies the expected protocol behavior which is that, upon receiving a packet from the remote, the queue of outgoing packets is completely drained.

If the rate limiter signals that the server is under load, at most one packet is added to the queue.

pub fn handle_outgoing_packet( &mut self, packet: Packet, to: SocketAddr, ) -> Option<WgKind>

Handles an outgoing packet sent through the tunnel identified by the remote socket address to.

pub fn update_timers(&mut self) -> Vec<WgKind>

Update timers of all tunnels. Generate corresponding keepalive or session handshake initializations.

As a result of this call, all expired tunnels are removed. Note that this is not the same as unauthorized tunnels.