RFC 3927 Link-Local IPv4 Negotiation

When two computers connect directly with an Ethernet cable without a DHCP server, they negotiate addresses in the IPv4 Link-Local range 169.254.1.0 through 169.254.254.255 with subnet mask 255.255.0.0 as defined in RFC 3927.

• Windows: Native Automatic Private IP Addressing (APIPA) assigns an IP address within 2–6 seconds.
• Linux: NetworkManager historically does not enable link-local negotiation automatically on unmanaged ports. EtherTransfer includes an active state machine in EthernetLinkMonitor.cs that automatically executes nmcli device modify <iface> ipv4.method link-local when a physical carrier is detected, and restores prior settings on exit.

UDP Peer Discovery Protocol (Port 50000)

Decentralized peer discovery is managed by DiscoveryService.cs using UDP broadcasts on port 50000:

{
  "Type": "HELLO",
  "Id": "EtherTransferApp-V1",
  "SessionId": "c4b8e21a-7b3f-4e89-9a12-8f6a91d2345e",
  "ComputerName": "Workstation-Desktop",
  "TcpPort": 55000,
  "OS": "Windows",
  "SequenceNumber": 42
}

Discovery Dynamics & Lifecycle

• Startup Burst: On launch, the client transmits discovery packets at staggered intervals: 250ms, 500ms, and 1000ms.
• Steady-State Heartbeat: Transmits a HELLO packet every 2000ms.
• Stale Peer Eviction: Peers silent for 45 seconds or whose IP address disappears from active Ethernet subnets are purged from memory.
• Graceful Teardown: Upon application closure, a burst of 3 BYE packets is broadcast to immediately unregister from peer lists.

UUID Session Identity Model

Devices are tracked by a dynamic UUID SessionId generated at startup, rather than a physical IP address.

Rationale: During link-local negotiation, an operating system may assign a temporary IP and renegotiate seconds later. By indexing peers by SessionId, IP shifts update the existing peer record in-place without generating duplicate "ghost devices" in the user interface.

Physical Link Monitor State Machine

The network layer runs a deterministic state machine defined in EthernetLinkMonitor.cs:

Subnet Interface Isolation

To prevent file transfer traffic from accidentally routing across slower Wi-Fi networks, NetworkHelper.cs inspects network interfaces and enforces active subnet matching:

public static bool IsIpInActiveSubnets(string ipAddress)
{
    var activeSubnets = GetActiveEthernetSubnets();
    return activeSubnets.Any(subnet => subnet.Contains(IPAddress.Parse(ipAddress)));
}

TCP Streaming Architecture (Port 55000)

Transfer sessions operate over a dedicated TCP stream with socket keep-alives and tuned 2 MB socket buffers. The transfer handshake and execution sequence:

Sender                                                                Receiver
                                                                        
   1. TCP Handshake (Port 55000) & Socket Tuning (2 MB Buffers)
   2. TRANSFER_REQUEST [TotalFiles, TotalSize, RootElements] 
                                                                         [Prompt User Authorization]
   3. TRANSFER_RESPONSE [Accepted: true/false, Reason] 
                                                                        
      === Single Large Files ===                                        
   4. FILE_BEGIN [FileItemMetadata: RelativePath, RootName, Size, Timestamps]
   5. Pipelined 32 MB Channel Stream (2 MB Chunks) ──> [Pre-allocated Extents, Direct I/O & Metadata Persistence]
                                                                        
      === Folder & Multi-File Containers ===                            
   6. FOLDER_BEGIN [FolderTarMetadata: RootName, TotalFiles, TotalSize, Timestamps]
   7. Raw Binary Framed Stream:
      [4B PathLen][UTF-8 Path][8B FileSize][8B CreatedMs][8B ModifiedMs][Payload] ──> [Parallel Disk Worker Pool (4-16 Threads)]
   8. Folder End Marker [4-Byte 0 EOF]
                                                                        
      === End of transmission ===                                       
   9. TRANSFER_END  [Finalize Result, Apply Directory Timestamps & Verify Rollback State]
                                                                        

Binary Stream Framing & Zero TAR/ZIP Overhead

Instead of heavy archive formats like TAR or ZIP which introduce 512-byte block padding and lockstep stalls, TransferSender.cs and TransferReceiver.cs use compact, zero-allocation length-prefixed binary framing:

[ 4-Byte Path Length (LE Int32) ] [ N-Byte UTF-8 Relative Path ] [ 8-Byte File Size (LE Int64) ] [ 8-Byte CreationTime (LE Int64) ] [ 8-Byte LastWriteTime (LE Int64) ] [ L-Byte Raw File Payload ] ... [ 4-Byte 0 EOF Marker ]

• Header Overhead: Reduced from 1,024 bytes per file down to only 28–40 bytes (including full 64-bit UTC timestamp metadata).
• Padding Waste: 0 bytes (exact byte sizes, zero 512-byte sector rounding).
• Metadata Preservation: Preserves original CreationTimeUtc and LastWriteTimeUtc across both files and directories, ensuring photos, build files, and documents retain their exact historical dates without resetting to the transfer timestamp.
• Small-File Coalescing: Files ≤ 64 KB are packed with their headers and written to the socket in a single WriteAsync call.

Pipelined Double-Buffering & Parallel Disk Ingestion

EtherTransfer decouples disk I/O from network transmission on both ends of the wire:

• Sender Pipeline (PipelinedTransferStream.cs): A 32 MB bounded producer-consumer channel (16 × 2 MB chunks) pre-fetches data from disk, insulating the network socket from NTFS flushes and background antivirus scans.
• Receiver Disk Worker Pool: The network receiver ingests files at full 115 MB/s wire speed into memory, dispatching file writes to a pool of 4 to 16 concurrent asynchronous disk workers. This eliminates the 1.5ms NTFS file handle creation tax on folders with thousands of small files.
• Direct Kernel I/O: Standalone streams use bufferSize: 1 (unbuffered direct write) with FileOptions.SequentialScan and pre-allocated NTFS extents.

Security Sandboxing & Path Traversal Protection

All incoming paths are strictly validated through PathSanitizer.cs:

• Directory Traversal Guard: Strips ../ and verifies the resolved path remains within the user's chosen destination sandbox.
• Windows Reserved Name Protection: Sanitizes reserved names like CON, PRN, AUX, NUL, and COM1–COM9.
• Directory Caching: Destination directories are cached in-memory so Directory.CreateDirectory is executed only once per unique folder.

Reliability, Speed Tracking & Cancellation Rollback

Direct point-to-point links do not always trigger an OS socket abort when a cable is severed. EtherTransfer guarantees reliability:

• Watchdog Timeouts: Strict 3–5 second watchdog per payload chunk and socket keep-alives.
• Stabilized Speed Meter: Uses a 500 ms sampling window with Exponential Moving Average (α = 0.20) to filter out TCP ACK burst jitter and display accurate sustained wire speed.
• Atomic Rollback: Incomplete elements are automatically deleted upon transfer cancellation or cable disconnect. Fully completed root elements in multi-item sessions are safely preserved.

Comprehensive Ethernet Throughput Matrix

Technical Bottlenecks Analysis

1. Why Single-Stream Plain TCP Caps at ~850 MB/s on 10 GbE

On standard 1500-byte MTU, transferring at 10 Gbps generates approximately 800,000 packets per second. A single TCP connection processes socket interrupts and ACKs on a single CPU core, creating an interrupt handling bottleneck before the network hardware is saturated.

Additionally, synchronous I/O loops (read disk → write socket) introduce alternating idle states where the network waits on storage and storage waits on socket buffer flushes.

Multi-Stream Saturation & Session Resumption (10 GbE)

EtherTransfer's high-speed engine delivers sustained wire-speed transfers (110–115 MB/s on 1 GbE, 270–285 MB/s on 2.5 GbE, and 450–850 MB/s on 10 GbE) powered by its 32 MB System.Threading.Channels pipeline and parallel disk ingestion. To achieve full 10 GbE line-rate saturation (1,150+ MB/s) and session recovery:

• Multi-Socket Connection Pooling (4–8 Sockets): Distribute payload packet processing across multiple CPU cores to eliminate single-core interrupt bottlenecks on standard 1500 MTU links.
• Byte-Offset Checkpoint Journaling: Persist progress metadata so interrupted transfers can resume seamlessly without re-transmitting completed files.
• Streaming SIMD SHA-256 Validation: Hardware-accelerated cryptographic integrity validation calculated on-the-fly during transmission.

Storage Hardware Prerequisites

• 1 GbE (115 MB/s): Standard SATA SSD or 7200 RPM mechanical HDD.
• 2.5 GbE (285 MB/s): Quality SATA III SSD (Samsung 870 EVO, Crucial MX500) or NVMe SSD.
• 5 GbE (570 MB/s): PCIe Gen 3 NVMe SSD (SATA SSDs cap at ~550 MB/s).
• 10 GbE (1,150 MB/s): PCIe Gen 3 ×4 or Gen 4 NVMe SSD with sustained sequential write performance outside of SLC write cache.

Security Model & Consent Gate

Sandboxing & Path Sanitization (PathSanitizer.cs)

Untrusted path strings from the network are strictly sanitized before any file handles are created:

• Directory Traversal: Strips ../ and ..\ sequences to keep files contained in the selected destination folder.
• Windows Reserved Names: Reserved device identifiers (CON, PRN, AUX, NUL, COM1-9, LPT1-9) are automatically prefixed with an underscore (e.g., _CON.txt).
• Control Characters: Null bytes (\0) and illegal filesystem characters are stripped.
• Collision Auto-Renaming: If a file or folder already exists at the destination, EtherTransfer automatically appends an incrementing counter (e.g., document (1).pdf, Photos (1)), guaranteeing that pre-existing user data is never overwritten or merged.
• Metadata & Timestamp Preservation: Original creation and modification timestamps are applied asynchronously after file streams close, retaining exact file timeline integrity across Windows and Linux.

Firewall Configuration & Sockets

EtherTransfer requires access to two specific local network ports:

• UDP Port 50000: Inbound & Outbound discovery broadcasts.
• TCP Port 55000: Inbound streaming file transfer listener.

netsh advfirewall firewall add rule name="EtherTransfer" dir=in action=allow program="%ProgramFiles%\EtherTransfer\EtherTransfer.exe" enable=yes profile=private,public

# For UFW (Ubuntu / Debian)
sudo ufw allow 50000/udp && sudo ufw allow 55000/tcp

# For Firewalld (Fedora / RHEL / CentOS)
sudo firewall-cmd --permanent --add-port=50000/udp --add-port=55000/tcp
sudo firewall-cmd --reload

OS Modifications Audit & Transparency

We maintain complete transparency regarding changes made by installers:

• Windows Installer (EtherTransfer.iss): Installs binaries to C:\Program Files\EtherTransfer, adds start menu shortcuts, and registers the firewall whitelist rule. Uninstallation cleanly removes all binaries and deletes the firewall rule.
• Linux Installer (install_linux.sh): Installs to /opt/ethertransfer, registers /usr/share/applications/ethertransfer.desktop, symlinks to /usr/local/bin/ethertransfer, opens firewall ports, and installs network-manager if missing.
• Zero Telemetry Guarantee: EtherTransfer contains zero tracking services, telemetry agents, or background analytics hooks. Absolutely no data leaves your local machine.

Portable Mode & Settings Storage

Portable releases are self-contained single-file executables with the .NET runtime bundled directly inside.

• Settings Storage (Windows): %AppData%\EtherTransfer\settings.json
• Settings Storage (Linux): ~/.config/EtherTransfer/settings.json

Custom device identities persist across sessions even if the portable executable is moved between directories or launched from a USB drive.

Solution Architecture (6 Projects)

The EtherTransfer solution is organized into 6 focused projects:

Building from Source

Prerequisites: .NET 10 SDK (version 10.0 or later) and Git.

# 1. Clone the repository
git clone https://github.com/divyviradiya2/ethertransfer.git
cd ethertransfer

# 2. Build the solution
dotnet build

# 3. Launch the desktop application
dotnet run --project EtherTransfer.UI

Running Automated Test Suites

EtherTransfer includes comprehensive unit and integration tests covering path sanitization, protocol framing, device discovery, and cancellation tokens:

# Run all test fixtures
dotnet test

# Run specific path sanitization security tests
dotnet test --filter "FullyQualifiedName~PathSanitizerTests"

Publishing Single-File Executables & Installers

# Windows x64 (Self-contained, Single-File)
dotnet publish EtherTransfer.UI -c Release -r win-x64 --self-contained true -p:PublishSingleFile=true -o publish/win-x64

# Windows x86 (32-bit Compatibility)
dotnet publish EtherTransfer.UI -c Release -r win-x86 --self-contained true -p:PublishSingleFile=true -o publish/win-x86

# Linux x64 (Self-contained, Single-File)
dotnet publish EtherTransfer.UI -c Release -r linux-x64 --self-contained true -p:PublishSingleFile=true -o publish/linux-x64

To compile the Windows installer with Inno Setup:

# Compile 64-bit installer
iscc EtherTransfer.iss

# Compile 32-bit installer
iscc EtherTransfer_x86.iss

Code Guidelines & Standards

• Asynchronous Discipline: Always propagate CancellationTokens through all network and file I/O operations.
• No Swallowed Exceptions: Do not use empty catch blocks; log or bubble errors with structured context.
• Memory Efficiency: Rent buffers from ArrayPool<byte>.Shared rather than repeatedly allocating byte arrays in loops.
• UI Responsiveness: Never block the UI thread with synchronous disk or socket calls; dispatch updates via Dispatcher.UIThread.Post().

Troubleshooting Matrix