Smol is a lightweight async runtime for Rust that bundles several well-known subcrates (async-executor, async-io, async-net, async-fs, async-process, async-channel, async-lock, blocking, futures-lite) into a single convenient dependency. It provides a global executor initialized lazily with configurable thread count via the SMOL_THREADS environment variable, and exposes a simple API (smol::spawn, smol::block_on, smol::Async, smol::Timer, smol::Unblock, etc.) for writing async programs. The source code itself is thin—primarily re-exports from subcrates plus a spawn module that sets up the global executor. This makes smol an excellent entry point for Rust async development without the complexity of larger runtimes like tokio. The repository includes a rich set of examples covering TCP, TLS, HTTP, WebSocket, file I/O, process management, and platform-specific features like inotify and timerfd. The codebase is well-maintained, uses modern Rust practices (edition 2021, MSRV 1.85, no unsafe), and has active CI and dependabot configuration.
picosnitch is a Linux daemon for per-executable network bandwidth monitoring using eBPF (CO-RE) and fanotify. It tracks which executables make network connections, records bytes sent/received, timestamps, and metadata (SHA256 hashes, optional VirusTotal and GeoIP lookups). The system provides real-time and historical views via multiple interfaces: a curses TUI (both live top and historical browser), a web UI, and a UNIX socket live feed. The daemon uses a multiprocess architecture with privilege-separated subprocesses for monitoring, event processing, database writes, notifications, and external API queries. It supports local SQLite storage and optional remote SQL (MariaDB/MySQL/PostgreSQL) for tamper-evident logging. The repository also includes a comprehensive comparative benchmark suite (bench/) that tests picosnitch against nine other network monitors across 24 scenarios, with a reusable ToolAdapter framework for running controlled experiments.
Firezone is a zero-trust network access platform providing secure remote access through VPN-like tunnels. The production system consists of a cloud-based management portal (Elixir/Phoenix), data-plane components (Rust gateways and relays), and native clients for macOS/iOS, Android, Windows, and Linux. The portal manages multi-tenant accounts, identity (OIDC, SAML, email OTP, X.509), access policies, device posture, and logs. It exposes a REST API (PortalAPI) for CRUD operations and WebSocket channels for real-time client/gateway connectivity. The Rust core (connlib) handles ICE/STUN/TURN connectivity, WireGuard tunnels, and eBPF-accelerated packet routing. PostgreSQL is used for persistence with logical replication for change data capture, Oban for background job processing, and Redis for caching/presence. External dependencies include identity providers (Entra, Okta, Google Workspace), device management systems (Intune, Defender, SentinelOne, etc.), log sinks (Splunk, Datadog, Elastic, S3), and billing (Stripe). The architecture separates the web admin interface (PortalWeb), REST API (PortalAPI), and internal ops (PortalOps) into distinct endpoints. Data-plane components (gateway, relay) communicate via WebSockets with the API to receive policy updates. Clients connect to relays using ICE/STUN/TURN. The system uses Phoenix PubSub for real-time updates and Postgres logical replication to propagate changes to connected clients and gateways. Key entry points: PortalWeb.Endpoint (admin UI), PortalAPI.Endpoint (REST/WebSocket for clients and gateways), PortalOps.Endpoint (ops dashboard). Rust binaries: firezone-gateway, firezone-relay, firezone-headless-client, firezone-gui-client. Mobile apps: Firezone iOS/macOS (Swift), Firezone Android (Kotlin).
Fuel is a Kotlin Multiplatform HTTP networking library built on kotlinx.coroutines, providing suspend-style HTTP verbs (GET, POST, PUT, PATCH, DELETE, HEAD, arbitrary methods) plus Server-Sent Events streaming across JVM, Apple (iOS/macOS), and WasmJS targets. The core fuel module uses an expect/actual split: a common HttpLoader interface and FuelBuilder are backed by OkHttp on JVM, NSURLSession on Apple, and the browser fetch API on WasmJS. A global Fuel object supports plugging in a custom loader or loader factory, and extension functions on String (httpGet(), httpPost(), etc.) provide concise request entry points. A FuelRouting interface lets applications model typed API endpoints as sealed classes. Four optional serialization modules — fuel-jackson-jvm, fuel-moshi-jvm, fuel-kotlinx-serialization, and fuel-forge-jvm — each add a small extension on HttpResponse (toJackson, toMoshi, toJson, toForge) that decodes the body and returns a Result from the companion Result library. The core response model is deliberately minimal: a mutable HttpResponse holding a status code, a kotlinx.io Source body stream, and headers. JVM request handling is semantically correct about HTTP (e.g., consulting OkHttp's HttpMethod.permitsRequestBody before attaching a body). The project is published as 3.0.0-alpha04, uses Kotlin 2.3 / Gradle 9.3 / OkHttp 5 alpha, and is actively maintained with CI, Renovate, Dependabot, and ktlint. JVM has solid unit coverage using MockWebServer for all verbs, routing, custom OkHttp configurations, and each serialization adapter. Apple and Wasm targets are implemented but largely untested outside manual samples, and the Apple SSE implementation is a naive full-body line splitter rather than true incremental streaming. Overall this is a clean, modern, well-organized library with a couple of genuinely reusable pieces (notably the Android-derived UriCodec port) and some pre-1.0 rough edges. This is a pure application/library repository, not a data project.
NeoForge is the official successor to Minecraft Forge, providing a comprehensive modding framework and API for Minecraft. It extends vanilla Minecraft through a patching system (coremods/ASM) and a rich event-driven architecture, allowing mods to hook into gameplay, rendering, networking, registries, capabilities (data attachments), and resource transfer. The repository includes the mod loader itself (client and server), a Gradle-based build system (buildSrc) for producing the framework and installer, and an extensive test framework (testframework/) with both unit and in-game game tests. The codebase is well-structured with clear client/server source splits, extensive use of codecs and data-driven JSON, and a modern transactional resource API for energy, fluids, and items. It is actively maintained with large community adoption.
This repository is a complete multiplayer co-op game sample called 'Boss Room', built by Unity Technologies to demonstrate best practices for using Unity Netcode for GameObjects (NGO). It implements a server-authoritative action RPG where up to 8 players cooperate to defeat a boss in a dungeon. The architecture is modular and state-driven: a connection state machine (Offline, ClientConnecting, Hosting, etc.) manages network lifecycle, while game flow states (MainMenu, CharSelect, BossRoom, PostGame) control scene transitions and gameplay logic. The core gameplay revolves around a ScriptableObject-based action system where abilities (melee, projectiles, buffs, stealth, etc.) are defined as data assets and executed via server-side action players with client-side anticipation for latency masking. The project integrates Unity Gaming Services for authentication, session management, and relay, and uses VContainer for dependency injection. Key entry points include ApplicationController (DI setup), ConnectionManager (network state machine), and GameStateBehaviour subclasses. Data flows involve client input sent via RPCs, server-side processing with NetworkVariables for state sync, and a typed NetworkedMessageChannel for decoupled event broadcasting. External dependencies include Unity Netcode, Unity Transport, Unity Gaming Services, VContainer, Cinemachine, and URP.
MicroLink v2 is a production-ready Tailscale VPN client for ESP32-S3 devices that establishes secure WireGuard tunnels through Tailscale's control plane. It implements the full Tailscale protocol stack including Noise protocol for control plane encryption, HTTP/2 framing, DISCO peer discovery, STUN for NAT traversal, DERP relay fallback, and WireGuard encryption via wireguard-lwip integration. The architecture uses a multi-task FreeRTOS design with separate tasks for coordination, WireGuard management, DERP transmission, network I/O, and application logic, communicating via message queues and event groups. Key features include WiFi/cellular network failover with health monitoring, zero-copy WireGuard receive option for high-throughput scenarios, NVS-based peer caching with LRU eviction, and an HTTP configuration server for runtime management. The code demonstrates strong protocol fidelity through direct reference to Tailscale's Go source files while adapting to embedded constraints.
XQUIC is a production-grade C implementation of the QUIC transport protocol (RFC 9000) and HTTP/3 (RFC 9114), developed by Alibaba. It provides a full-featured QUIC stack including connection management, packet encryption, loss detection, congestion control (BBR, CUBIC, NewReno, Copa), and HTTP/3 with QPACK header compression. The library also supports experimental extensions such as Multipath QUIC, Forward Error Correction (FEC), and Media over QUIC (MoQ) for streaming media. The architecture is modular with a callback-driven engine, pluggable congestion control and TLS backends (BoringSSL, BabaSSL), and extensive testing infrastructure including unit tests (CUnit), integration shell scripts, and interoperability tests. The codebase is well-structured with reusable utility components (ring buffers, hash tables, object pools, timer managers) and demonstrates strong software engineering practices, though the large number of feature flags and experimental extensions introduce some complexity and potential drift.
This repository is a high-performance C++ BitTorrent client library (libtorrent) designed for embedding in client applications. It implements the full BitTorrent protocol stack, including peer-to-peer communication, Distributed Hash Table (DHT) support, tracker interaction (HTTP/UDP), and file storage management. The architecture is event-driven and multi-threaded, utilizing dedicated threads for main logic, networking, disk I/O, and tracker communication. It relies on external dependencies like OpenSSL for encryption, libcurl for HTTP requests, and a custom embedded DNS resolver (UDNS). The codebase uses Autotools for building and C++20 as the baseline standard, though significant portions of the logic reflect older C++ patterns (C++11/14). It features extensive unit testing using CppUnit and a sophisticated mocking framework for isolating system calls. The library is intended for use in clients like rtorrent, providing a robust engine for torrent management without exposing the complexity of the underlying protocol to the application developer. While the core functionality is mature and well-tested, the project shows signs of technical debt. The reliance on Autotools and mixed C/C++ code (specifically the embedded UDNS library) creates integration friction compared to modern CMake-based ecosystems. Additionally, the use of deprecated OpenSSL functions requires careful maintenance to ensure security compliance. Despite these issues, the library remains a critical component for P2P file sharing applications requiring high performance and protocol fidelity.
This is the main OpenWrt build system and firmware distribution repository. It is not a single application but a complete, cross-compiling build system for producing embedded Linux firmware images targeting a vast array of routers, access points, and other network-attached devices. The repository consists of a top-level Makefile, a package directory tree (kernel modules, userspace utilities, libraries, firmware blobs), a kconfig-based configuration system, kernel patch sets, and numerous build helper scripts. In production, users clone this repo, run `make menuconfig` to select target hardware and packages, then `make` to produce a flashable firmware image (e.g., sysupgrade or factory image). The primary data flow involves downloading upstream source tarballs, applying OpenWrt-specific patches, compiling packages and the Linux kernel using a custom toolchain, and assembling the firmware image via mtd-utils and image generation scripts. External dependencies include the Linux kernel source, GNU toolchain (gcc, binutils, musl/glibc), and hundreds of upstream projects (hostapd, dnsmasq, openssl, etc.). The architecture is a monolithic build system with modular package definitions, enabling high customization through a kconfig frontend. While the build system is the core, the repo also contains many small userspace tools (mtd, swconfig, procd, netifd, uci) that run on the target device.
This repository is the official collection of Godot Engine demo projects, maintained by the Godot Foundation. It contains hundreds of self-contained, runnable demo projects that showcase specific engine features across 2D, 3D, audio, GUI, networking, XR, mobile, compute shaders, and editor plugins. Each demo is a standalone Godot project with its own project.godot, scenes, scripts, and assets. The repository serves as both a learning resource for developers and a testbed for engine capabilities. While not a single application, it demonstrates a wide range of game development patterns and engine APIs. Notable highlights include a generic state machine implementation, a 2.5D node system, a virtual joystick for touch input, a custom logger with UI integration, and a JSON-driven dialogue system. The codebase is actively maintained with recent commits, low technical drift, and consistent use of modern Godot 4.x APIs.
This repository provides a single Bash script (`wireguard-install.sh`) that serves as an interactive installer and management tool for a WireGuard road warrior VPN server. It supports multiple Linux distributions (Ubuntu, Debian, AlmaLinux, Rocky Linux, CentOS, Fedora) and handles the full lifecycle: initial server setup with IP/port selection, firewall configuration (firewalld or iptables), client addition and removal, and complete uninstallation. The script also detects containerized environments and falls back to BoringTun (userspace WireGuard) when the kernel module is unavailable, with optional automatic updates via cron. No application framework or tests are present; it is a standalone operational tool intended for direct execution on a target server.
EdgeVPN is a decentralized peer-to-peer VPN and overlay networking tool built on libp2p. It provides a VPN tunnel (TUN interface), TCP service tunneling (ngrok-like), HTTP egress proxy, DNS resolution, file transfer, and a distributed ledger for network state coordination. The architecture is a single Go binary with an embedded React SPA dashboard, exposing a REST API (Echo framework) and CLI (urfave/cli v2). The core innovation is a blockchain-style ledger that stores machine, service, DNS, and health records, with optional signed ownership enforcement and liveness-based reaping. The system uses libp2p for peer discovery (DHT, mDNS), pubsub (gossipsub), relays, and circuit v2. It is designed for decentralized networks without central coordination, and is used in production by Kairos (Kubernetes) and LocalAI (P2P distribution). The codebase demonstrates strong engineering with functional options patterns, comprehensive test suites, documentation generation from CLI code, and a design system for the React UI. However, it carries technical debt from experimental features (PeerGuard, DHCP, IPv6), a forked libp2p-pubsub dependency, and documentation drift that requires manual regeneration.
The VK iOS SDK is a library for integrating iOS applications with the VK (VK.com) social network. It provides authentication via OAuth, API request execution with JSON parsing into model objects, and UI components for sharing, authorization, and captcha handling. The SDK features a modular architecture with distinct layers for networking (VKRequest, VKHTTPClient), API method wrappers (VKApi), dynamic object mapping (VKApiObject), and resource management (VKBundle). Key entry points include the VKSdk singleton for session management, VKApi for convenient API calls, and VKAuthorizeController/VKShareDialogController for UI flows. The SDK relies on system frameworks (UIKit, Foundation, WebKit) and includes an example demonstration application. While the codebase shows strong engineering in reusable components like VKRequest and VKApiObject, it exhibits some technical drift through deprecated APIs (UIAlertView) and version discrepancies between documentation and podspec.
This repository is a comprehensive bare-metal microcontroller programming guide, providing step-by-step examples from minimal firmware to a full embedded web server with a device dashboard. The code targets ARM Cortex-M and RISC-V microcontrollers (STM32, TI TM4C, RP2040, ESP32-C3, nRF52840, etc.) and uses only GCC, a datasheet, and the Mongoose networking library. The architecture is bare-metal, single-threaded with an event loop in the webserver step; it demonstrates direct register manipulation, interrupt handling, UART, SysTick, clock configuration, printf retargeting via newlib syscalls, CMSIS integration, and Ethernet with built-in TCP/IP (MIP). The repository also includes reusable project templates for blinky, CLI, and LittleFS filesystem. Despite being educational, the code is production-quality and follows embedded best practices such as non-blocking timers, hardware abstraction layers (hal.h), and modular startup code.
This repository is the OpenWrt packages feed: a collection of roughly 5,000 package build recipes, patches, init scripts, UCI defaults, netifd protocol handlers, and small utility programs that extend the OpenWrt embedded Linux distribution. It is not a standalone application; it is a software distribution layer consumed by OpenWrt's feed mechanism. Each package directory contains a Makefile that wraps an upstream project (download, patch, cross-compile, install) plus OpenWrt-specific runtime glue such as /etc/init.d scripts, configuration files, and ubus/rpcd plugins. It also contains language build helpers for Python, Go, Rust, Perl, and Lua packages, plus a shared CI/test framework.
Nanocl is a distributed container orchestration system designed as a Kubernetes alternative, focusing on simplicity and declarative state management. The system manages workloads termed 'Cargoes' (containers), 'VMs', and 'Jobs' using Docker as the underlying runtime. It features a client-server architecture with a CLI (`nanocl`), a central daemon (`nanocld`), and auxiliary sidecar services for proxying (`ncproxy`) and DNS (`ncdns`). The architecture relies on Rust for performance and safety, utilizing `ntex` for async HTTP handling and `diesel` for database persistence. The core operational model is driven by declarative Statefiles (YAML/TOML/JSON) processed with Liquid templating. These files define the desired infrastructure state, which the daemon reconciles against the actual runtime state. The system integrates directly with the Docker daemon via the `bollard` library to manage container lifecycles, networking, and images. It features a robust event-driven architecture where state changes trigger sidecar updates, such as Nginx configuration regeneration for routing. The codebase demonstrates a modular design with shared crates for error handling, stubs, and utilities. It implements a generic repository pattern for database access and abstract lifecycle traits for resource management. The API is versioned and documented via OpenAPI/Swagger, supporting RESTful CRUD operations and real-time event streaming. While the project shows strong architectural patterns, it carries medium technical drift due to API versioning fragmentation and heavy dependency on Docker API behavior.
This is a comprehensive Terraform module library for provisioning Google Cloud networking infrastructure. It provides building blocks for VPCs, subnets, routes, firewall rules (classic and policy-based), network peering, Private Service Connect (consumer, producer, endpoints), Network Connectivity Center hubs/spokes, and higher-level foundation patterns (shared VPC, hub-and-spoke). The architecture is modular: the root module orchestrates core resources while 30+ submodules handle specific concerns (e.g., firewall-rules, subnets-beta, network-firewall-policy). Each submodule has its own variables, outputs, and version constraints, making them independently consumable. Extensive integration tests in Go (using cloud-foundation-toolkit) validate correct behavior against real GCP projects. The module is actively maintained with frequent releases (v18.3.0) and follows Google Cloud Foundation Toolkit conventions, but exhibits some technical drift: deprecated variables remain, beta submodules may lag behind GA, and many examples pin older Terraform/provider versions.
Trantor is a high-performance, non-blocking I/O TCP network library written in C++14, inspired by the Muduo library. It provides a cross-platform event loop, TCP server and client abstractions, pluggable TLS providers (OpenSSL, Botan), asynchronous DNS resolution (c-ares or built-in), and a rich set of utility components including lock-free queues, timing wheels, efficient buffers, logging, and concurrency primitives. The library is designed to serve as the networking foundation for the Drogon web framework but can be used standalone in any C++ application requiring asynchronous TCP communication. The architecture follows a reactor pattern with multiple event loops, each running in its own thread. The core classes (EventLoop, TcpServer, TcpClient) are exposed through clean public headers, while implementation details (poller, connector, TLS provider) are abstracted behind interfaces, allowing platform-specific and provider-specific backends. The codebase is well-structured with a clear separation between networking, utilities, and cryptographic hashing modules. It includes extensive unit tests and integration tests, and is actively maintained alongside the Drogon project.
This is the playit.gg tunnel agent, a production-grade client-side daemon that exposes local servers (e.g., Minecraft, game servers, web services) to the internet through the playit.gg tunnel network. The system is organized as a Rust multi-package workspace comprising five main crates: `agent_core` (tunnel state machine, TCP/UDP proxying, control connection), `playitd` (background daemon with IPC server, stats, log rotation), `playit-cli` (CLI and TUI frontend using ratatui), `playit-ipc` (local IPC protocol with version negotiation), and `playitd-tray` (Windows system tray controller). It supports Linux, Windows, macOS, and FreeBSD, with platform-specific path handling (Unix sockets, named pipes, Windows service management). The architecture centers on a UDP control connection to playit.gg servers: the agent authenticates via HMAC-SHA256, receives tunnel assignments, then proxies TCP and UDP traffic between tunnel ingress points and local origin servers. The daemon runs as a background service (systemd, OpenRC, Windows service) and exposes a local IPC endpoint for the CLI/TUI to monitor logs, stats, and lifecycle status. Key entry points include `packages/playitd/src/bin/playitd.rs` (daemon binary), `packages/playitd/src/bin/playitd-service.rs` (Windows service host), `packages/playit-cli/src/main.rs` (CLI with attach/start/stop/claim commands), and `packages/playitd-tray/src/main.rs` (Windows tray application). External dependencies include tokio (async runtime), ratatui (TUI), crossterm (terminal), serde (serialization), reqwest (REST client), and ring (HMAC). The codebase demonstrates strong craftsmanship in low-level networking (zero-copy UDP packet pools, PROXY protocol, statically-sized control messages) and state machine design (connection recovery, MTU probing, address selection). However, it suffers from some production debt: panics in critical paths (UDP channel shutdown, flow invariants), duplicated code between `playitd-tray` and `playitd-windows-setup` startup shortcuts, and hardcoded configuration values (control port, protocol version). The build and release infrastructure is extensive (nfpm, WiX, Docker, Arch PKGBUILD, code signing) but shows signs of fragility (stale binary name in mac-deploy.sh, sed-based version overrides).