This document outlines the core problem NATGhost aims to solve and explains the architectural decisions behind BurstKernel (now evolving into NKernel), specifically why bypassing the standard operating system network stack was absolutely necessary.
In modern peer-to-peer (P2P) networking, establishing a direct connection between two peers located behind Symmetric NATs is notoriously difficult. Unlike Cone NATs, Symmetric NATs assign a new, unpredictable external port for every new destination IP and port combination. Standard STUN/ICE protocols fundamentally fail in this scenario, traditionally forcing a fallback to TURN (relaying traffic through a central server), which incurs high latency and bandwidth costs.
To achieve direct P2P connectivity without a relay, a technique called Port Prediction and Hole Punching must be employed. This involves guessing the external port the NAT will assign and sending bursts of UDP packets to "punch a hole" through the firewall.
Our mathematical models and Monte Carlo simulations revealed a harsh reality: To achieve a successful connection in a Double-Symmetric NAT scenario (Scenario C), both peers must "guess" and hit the correct port combinations simultaneously.
When both peers open 6,600 sockets (sending 6,600 packets to different guessed ports), the probability of a successful connection (a double coincidence) is only 52%. To achieve deterministic, repeatable success (closer to 99%), both sides must blast over 10,000+ packets/sockets.
Herein lies the critical engineering bottleneck: Corporate Symmetric NATs and stateful firewalls are aggressive. When a UDP packet leaves the network, the firewall only keeps that "hole" (state mapping) open for a very brief window—often just a few seconds.
If an application tries to open 10,000 UDP sockets and send 10,000 packets using standard Operating System (Linux/Windows) system calls (socket(), bind(), sendto()):
- Syscall Overhead: Transitioning from user-space to kernel-space 10,000 times takes too much CPU time.
- Interrupts & Context Switches: The OS scheduler and network stack interrupts add unpredictable latency.
- Resource Exhaustion: Opening 10,000 file descriptors (sockets) exhausts system resources and slows down the OS network stack.
By the time the application finishes opening and sending the 10,000th packet, the NAT mapping for the first few thousand packets will have already timed out and closed. The firewall's stateful nature makes standard OS socket APIs unusable for high-speed deterministic hole punching.
To solve this, we realized we had to completely bypass the operating system. We didn't need real "sockets"; we just needed the NAT firewall to think we were opening thousands of sockets.
This led to the creation of BurstKernel (which is now evolving into NKernel):
- Pure Kernel Space: No user-space to kernel-space context switching. No syscall costs.
- Socketless Replicaton: It directly crafts raw Ethernet/IPv4/UDP packets in memory and writes them straight to the Intel E1000 Network Card's DMA rings (TX Ring).
- Zero Interrupts: By using a "run-to-completion" polling model instead of hardware interrupts, the CPU blasts packets at the absolute physical limit of the Gigabit link.
By replicating the behavior of opening 10,000 sockets natively in a bare-metal VM without actually creating OS-level socket structures, the system can inject the required burst of packets in a fraction of a second. This easily beats the NAT's timeout window, turning a 52% probabilistic gamble into a deterministic, highly successful NAT traversal technique.