asupersync

The postgres_parameter_messages fuzz target tests the parsing robustness of PostgreSQL protocol parameter messages. It focuses on two primary message types:

• ParameterDescription (parse_parameter_description in src/database/postgres.rs):

  • Format: i16 parameter count followed by an array of i32 OID values.
  • Tests: Negative counts, oversized arrays, and invalid OIDs.

• ParameterStatus (handle_parameter_status in src/database/postgres.rs):

  • Format: Null-terminated parameter name followed by a null-terminated value.
  • Tests: Embedded nulls, encoding corruption, and oversized strings.

The fuzzer uses structure-aware generation to create test cases including standard PostgreSQL types (e.g., TEXT(25), INT4(23), BOOL(16), UUID(2950)), common runtime parameters (e.g., application_name, client_encoding, TimeZone), and various corruption patterns like truncated messages or invalid UTF-8.

The ATP vs rsync benchmark matrix is a rigorous harness used to compare the performance and integrity of atp against rsync. It consists of four primary components:

1. matrix_bench.sh (Planner/Resume Layer): Enumerates all combinations of (workload, regime, tier, method, rep), generates a resumable plan in JSONL format, and skips cells that have already been completed.
2. run_matrix_cell.sh (Per-cell Runner): Executes a single transfer within a hermetic network namespace (netns), virtual ethernet pair (veth), and network emulation (netem). It measures wall time, peak/average RSS, CPU usage, and feedback rounds, then performs SHA-256 verification.
3. gen_tree.py (Tree Generator): A deterministic, seeded power-law tree generator (supporting tree_small and tree_big) that also produces per-file manifests.
4. score_matrix.py (Scorer): Processes the JSONL results to produce a markdown scorecard containing medians, coefficients of variation (cv), and ATP/rsync ratios for wall time and RSS.

Asupersync is a spec-first, cancel-correct, and capability-secure async runtime for Rust. It is designed as a broad replacement for Tokio stacks rather than a simple wrapper, providing stronger guarantees through several core design principles:

• Structured Concurrency: Every task is owned by a specific region; closing a region ensures quiescence (no live children and all finalizers are complete).
• Cancel-Correctness: Cancellation follows a strict protocol: request -> drain -> finalize. It is not a silent drop; races must cancel and fully drain 'losers'.
• Two-Phase Effects: Uses reservation/commit APIs to protect channel and effect boundaries from data loss during cancellation windows.
• Capability Security: Effects are gated by held Cx authority. While ambient lookup can mirror an installed context, it cannot mint new authority.
• Deterministic Testing: Provides LabRuntime with virtual time, DPOR, oracles, and chaos injection.
• Obligation Tracking: Permits, acks, and leases must resolve by either a commit or an abort.

Supported Capabilities:

• Networking: TCP, HTTP/1.1, HTTP/2, WebSocket, TLS, gRPC, DNS, and feature-gated native QUIC/H3.
• Databases: SQLite, PostgreSQL (wire protocol), and MySQL (wire protocol).
• Supervision: OTP-style actors, GenServer, supervision trees, AppSpec, and Spork.

This document provides end-to-end migration cookbooks for replacing tokio and related ecosystem crates (like axum, tonic, quinn, h3) with asupersync equivalents. The migration is organized into 6 tracks based on capability domains. Each cookbook provides recipes, code transformations (before/after), anti-patterns, failure modes, and rollback criteria.

Migration Tracks

Prerequisites

• asupersync-2oh2u.10.13 (golden log corpus)
• asupersync-2oh2u.2.10 (I/O e2e logging)
• asupersync-2oh2u.11.1 (migration strategy framework)

Asupersync provides migration packs to help developers translate usage patterns from common tokio-ecosystem crates (like sqlx, tokio-postgres, redis, nats, etc.) to equivalent Asupersync patterns. Each pack covers connection setup, query execution, transactions, and error handling.

Supported Migrations

The asupersync project provides several primary CLI binaries, each with distinct feature requirements and command structures:

• asupersync: The main entry point. Includes command families for atp, trace, conformance, lab, and doctor. When the remote-service feature and Unix platform are enabled, it also exposes remote serve and remote probe commands.
• atp: A standalone transfer binary used for data movement. It features commands like send, recv, serve, and various bond-* commands.
• atpd: The daemon binary. Manages the lifecycle of the service with commands like start, stop, status, reload, init, diagnostics, and identity (which includes show, generate, import, and export).
• offline_tuner: A utility for optimization. Commands include optimize, candidates, emit-profile, validate, and scheduler-recommend. Requires cli and simd-intrinsics features.

The performance benchmarking system uses a single registry, artifacts/baseline.json, to store gated p50 (median) performance rows. Each benchmark binary is responsible for a specific disjoint operation prefix. The gate mechanism ensures that a binary only compares its own results against its own registered rows, preventing cross-binary failures.

Benchmark Binary Mapping:

Important Notes:

• io_token_dedup is ungated because its absolute costs are highly sensitive to host noise; it is intended for relative strategy comparison only.
• sched/task_state/ rows are historical and should not be used as production hot-read baselines. Use the sched/hotread/v2/ replacement operations instead.
• New semantic paths must use new operation IDs rather than overwriting existing ones.

The RABS project is a multi-phase master plan to implement a native, accelerated build sidecar for Asupersync. The development is organized into Milestones (M0 through M9) that transition from local record/replay capabilities to a fully distributed, ATP-native (Asupersync Transport Protocol) remote execution system.

Key architectural phases include:

• M0-M1: Foundation: Establishing rabs-protocol, local request/event schemas, and a canonical Cargo-driver using Linux mount namespaces for isolation.
• M2-M3: Runtime & Storage: Implementing the Asupersync runtime island, process ownership, and a durable object store (rabs-cas) with atomic publication.
• M4-M5: Dependency Caching: Implementing immutable dependency action-family caching and native toolchain/linker (CC/CXX/AR) wrappers.
• M6-M9: Distributed Coordination & ATP: Moving to an authoritative coordinator (rabs-coord), a native ATP control plane, and whole-command remote execution over ATP.