Powered by SnapDock Rendering

StaxPing — Modules Explained

← Back to StaxPing Index

Modules Explained

StaxPing is built around a set of focused, independent modules.
Each module handles a specific part of the diagnostic workflow, and all modules follow the same principles:

  • predictable behavior
  • clean, aligned output
  • safe fallbacks
  • cross‑platform consistency

This page explains how each subsystem works at a high level.


DNS Module

The DNS module performs hostname resolution before any other diagnostic step.

Responsibilities

  • Resolve IPv4 (A) and IPv6 (AAAA) records
  • Measure lookup time
  • Provide clean, structured output
  • Handle multiple results consistently

Behavior

If DNS resolution fails, StaxPing:

  • reports the failure clearly
  • skips dependent modules (ping, HTTP, traceroute)
  • exits with the appropriate error code

DNS is the foundation of the diagnostic chain.


ICMP Module

The ICMP module measures latency and packet reliability.

Responsibilities

  • Send ICMP echo requests
  • Measure min/avg/max latency
  • Track packet loss
  • Provide jitter‑friendly timing

Behavior

If ICMP is unavailable (permissions, OS restrictions, or missing capability):

  • StaxPing reports the limitation
  • The rest of the diagnostics continue normally
  • The tool does not exit unexpectedly

This ensures consistent behavior across Linux and Windows.


HTTP Module

The HTTP module performs a lightweight reachability check.

Responsibilities

  • Send a minimal HTTP request
  • Measure response time
  • Report status code
  • Follow redirects
  • Display the final resolved URL

Behavior

The HTTP module is designed to be fast and safe:

  • no large downloads
  • no body parsing
  • no persistent connections

If the HTTP check fails, StaxPing reports the error without interrupting other modules.


Traceroute Module

The traceroute module is optional and enabled with --trace.

Responsibilities

  • Perform hop‑by‑hop routing
  • Measure latency per hop
  • Display IP addresses cleanly
  • Align output for readability

Behavior

If traceroute is not supported on the system:

  • StaxPing prints a clear fallback message
  • The rest of the output remains intact
  • The tool exits normally

Traceroute is designed to be helpful, not disruptive.


Capability Detection

Before running diagnostics, StaxPing checks which features are supported on the current system.

Responsibilities

  • Detect OS
  • Check DNS, ICMP, HTTP, and traceroute availability
  • Store results in the config file
  • Avoid running unsupported modules

Behavior

Capability detection ensures:

  • no unexpected crashes
  • no platform‑specific surprises
  • consistent output across systems

This is part of the first‑run setup and rarely needs to be repeated.


Config System

StaxPing stores a small configuration file after the first run.

Responsibilities

  • Store accepted EULA state
  • Store detected capabilities
  • Store OS information
  • Provide a stable environment for future runs

Locations

Linux:

$HOME/.config/staxping/config.json

Windows:

%APPDATA%\StaxPing\config.json

Behavior

The config file is intentionally minimal:

  • no user data
  • no history
  • no telemetry
  • no persistent logs

It exists only to ensure predictable behavior across sessions.


StaxPing’s modular architecture keeps each subsystem focused, reliable, and easy to maintain while providing a unified diagnostic experience.