* chore: dead-code sweep - Delete socktop_connector/src/connector.rs: orphaned since08f248cremoved 'pub mod connector;' during the modularization refactor. Never compiled (verified under default, wasm, and workspace feature combos) but shipped in the crates.io tarball and contained an outdated copy of the TLS verifier — a trap for anyone patching the pinning bug in the dead copy. - Delete empty socktop/src/ws.rs, tracked editor backup ui/.modal.rs.backup, and stray test_thiserror.rs at the repo root. - Delete the two LEGACY #[allow(dead_code)] process input handlers; the header-click render test now exercises the live _with_selection handler instead (better coverage of the real path). - Drop unused sysinfo dependency from the socktop client. - Replace stale 'temporarily increased for testing' comment on COMPRESSION_THRESHOLD (it already held the production value). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(connector): make certificate pinning real; disable Nagle Security: with --verify-hostname off (the default), the old NoVerify verifier accepted ANY server certificate — the CA loaded from --tls-ca was never consulted, so the documented pinning was a no-op and the connection was trivially MITM-able. Replace it with PinnedCertVerifier: the presented end-entity cert must be byte-identical to a cert in the --tls-ca file (any cert in a multi-cert PEM matches, supporting rotation). Signature validation now uses the ring provider's full algorithm set instead of a hardcoded 3-scheme list. Empty PEM files fail fast instead of failing closed per-handshake. The --verify-hostname path is unchanged (WebPki root-store validation). Also: the third argument of connect_async_tls_with_config is tungstenite's disable_nagle flag, not a verification toggle — we were passing verify_hostname there, leaving Nagle ON for default users. Pass true unconditionally, and disable Nagle on the plain ws:// path too; socktop exchanges small request/response frames where Nagle only adds latency. Client now consumes the connector via a dual path+version dep so these fixes are in local builds and CI before the crates.io publish (cargo strips the path on publish). Connector version -> 1.51.0. Verified E2E: agent A's cert connects to agent A; agent B's cert against agent A fails the handshake (the rpi-worker-1 wrong-PEM scenario); --verify-hostname against a 127.0.0.1 SAN still connects. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(agent): GPU worker thread, async journalctl, correctness + cache fixes Lightweight: - GPU collection moves to a dedicated worker thread that owns the gfxinfo handle for the process lifetime. gfxinfo's active_gpu() runs a full NVML init/teardown (~20ms, blocking) and we were paying it on the async runtime for every collect — measured at ~80% of the agent's entire active CPU on a GPU machine. The handle holds Rc<Nvml> (not Send), so a thread + mpsc/oneshot channel pair confines it; a zero-total-VRAM reply is treated as a dead session (driver reload) and re-probed. - journalctl now runs via tokio::process instead of blocking one of the two runtime workers for the duration of the subprocess. - TtlCell (state.rs) replaces the four hand-rolled static TTL caches; a cached negative result now counts as fresh, so hosts with no matching temp sensor or GPU stop rescanning every request. Single lock+clone on the GPU cache hit path (was two). Correctness: - Process/child CPU times are now microseconds as documented; they were milliseconds, rendering 1000x too small next to (correct) thread times. - Non-Linux per-process CPU%% clamps AFTER dividing by core count; a 4-cores-busy process on an 8-core box reported 12.5% instead of 50%. - Journal timestamps are real RFC 3339 UTC plus an additive timestamp_us field (sorting is now numeric); the old strings were Debug-formatted SystemTime mangled by string replace. - Partition detection uses /sys/block on Linux: whole-disk filesystems on names like nvme0n1 or zram1 are no longer misclassified as partitions. One shared parent_disk_name() replaces two inline copies. - New sampled_at_ms on the metrics payload (additive) records when the snapshot was actually collected, so clients can compute exact rates across the agent's TTL cache. Security/robustness: - key.pem is created 0600 (was umask default 0644, world-readable) and pre-1.51 keys are tightened on startup. - Per-PID detail/journal caches now evict (60s max age, 64 entries max); they previously grew without bound under PID-walking clients. - The two per-PID ws handlers collapse into one generic helper. - /proc/<pid>/stat parsing unified in one comm-safe module. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(tui): responsive input, request timeouts, poisoned-stream reconnect R1 — input latency: the event loop drained input once per iteration, then slept the whole metrics interval; keys and wheel events queued for up to 500ms (or the full interval at slower rates) and applied in bursts. The input block is extracted to drain_input() and the tail sleep replaced by a deadline wait in <=33ms poll slices that handles and repaints input the moment it arrives. Verified: help modal opens <150ms into a 2000ms tick. R2 — freeze-proofing: metrics/processes/disks requests had no timeout; a half-dead connection left ws.next() pending forever and froze the TUI with no way to quit (raw mode eats Ctrl+C as an unread key event). All requests now carry a 5s budget. C3 — desync: replies are matched to requests by order alone, so a timed- out request's late reply would shift every subsequent reply off by one. Any timeout now treats the stream as poisoned and goes through the reconnect flow — a fresh stream is aligned by construction. The modal endpoints additionally mark process details unsupported (flag resets on modal close/selection change) so a detail-less agent doesn't cause a reconnect loop. While disconnected the fetch path idles: recovery belongs to the manual/auto retry paths instead of 5s-timeout hammering. C7 — fit::truncate_middle_cols replaces util::truncate_middle: display- width aware and char-boundary safe; the byte-slicing version panicked the draw loop on non-ASCII device names. Verified live: agent kill -9 mid-session -> error modal in <3s, q exits while disconnected, r reconnects and resumes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * chore: version 1.51.0, path-dep the wasm examples, README notes - socktop, socktop_agent, socktop_connector -> 1.51.0. - socktop_wasm_test and zellij_socktop_plugin consume the in-repo connector via path deps so wasm-feature API drift is caught at PR time instead of after publish. Immediately proved out: the wasm requests module needed the new sampled_at_ms field, invisible to native builds. - zellij plugin gains the standalone [workspace] marker (it could not be cargo-checked in-tree at all before). NOTE: its lib.rs has pre-existing compile errors unrelated to the connector (static mut STATE conflicts with register_plugin!, missing BTreeMap import) — needs its own rework, out of scope here. - README: sampled_at_ms in the example payload. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(review): restore Agent Update Required flow, command field, axis alignment Fixes from Jason's hands-on verification of the branch: 1. Old-agent messaging regression (this branch): a detail-request timeout went through the loud poison/reconnect flow, burying the ProcessDetails modal's 'Agent Update Required' message under a connection-error modal. Old agents IGNORE unknown messages (no late reply, no desync), so the optional per-PID endpoints now use quiet_reconnect(): swap the stream silently (still safe against merely-slow agents) and let the modal show its message. Only a failed reconnect surfaces loudly. Verified against a real v1.40.0 agent: message shows, session stays healthy. 2. Draw starvation (this branch): an agent that never answers get_metrics put the loop in fetch->timeout->poison->restart cycles that never reached the draw call — permanently blank TUI. The iteration now paints before fetching, and a second consecutive metrics timeout trips a circuit breaker: persistent 'Agent is not responding' error, recovery left to the manual/30s retry paths. Verified against a 0.9-era agent. 3. Command & Details pane blank (pre-existing on master): the minimal- refresh optimization dropped cmd/exe/cwd from the detail endpoint's ProcessRefreshKind, so process.cmd() had nothing to return. Restored with UpdateKind::OnlyIfNotSet — immutable values, read once per PID. Regression test added; journal E2E re-verified (100 entries render). 4. Scatter-plot axis misalignment: Y labels used a fixed 4-char field from the era when CPU times were 1000x too small; honest millisecond values (e.g. 136114) blew through it. Labels now right-align to the widest value per frame and X labels/titles share the dynamic padding. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * feat: journal access notice, 1.60.0, install script, changelog, riscv protoc fallback - Journal pane now distinguishes 'no entries' from 'no journal access': journalctl exits 0 with empty output when the agent's user simply can't see the target's entries (demo mode / user-run agents), explaining itself only on stderr. The agent forwards that hint as an additive JournalResponse.notice and the client renders it with practical advice. Verified E2E via a stub journalctl emulating the unprivileged case. - Version 1.60.0 across all crates (1.51 would read fine, but the repo's scheme is 1.40/1.50/…, and a literal 1.6.0 would sort BELOW 1.50.0 in semver). All user-facing version strings already come from CARGO_PKG_VERSION — a stale binary was the only way to see an old one. - scripts/install.sh: build-from-source install/upgrade for the test fleet (Linux + macOS). Detects in-repo checkouts, installs rustup when missing, replaces a systemd socktop-agent service binary in place and restarts it, requires system protoc on riscv64. - build.rs (agent + connector): fall back to $PROTOC / PATH when protoc-bin-vendored has no binary for the host (riscv64) — native SBC builds previously panicked in the build script. - CHANGELOG.md covering v1.50.0 -> 1.60.0. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * test: add notice field to cache test initializer Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix: untrack zellij plugin build dir; installer updates all PATH copies - Remove zellij_socktop_plugin/target from git (3,577 files committed by accident inbf6ac87): the root .gitignore anchors /target to the repo root, so the standalone plugin's own build dir wasn't covered. Ignore target/ at any depth (also fixes the pre-existing '/socktop-wasm-test/target' entry, which pointed at a hyphenated path that doesn't exist). - install.sh now updates EVERY copy of socktop/socktop_agent on PATH, not just $PREFIX: a stale 'cargo install' in ~/.cargo/bin shadows /usr/local/bin on most PATHs, so an install could 'succeed' while 'socktop --version' kept reporting the old release. Extra copies that can't be written are warned about, not fatal, and the script now prints which binary is actually active on PATH at the end. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * feat(installer): manage the socktop-agent systemd service Upgrade path (unit already present): NEVER touch the unit file — it is the operator's config (SSL, tokens, ports live there as Environment= lines). Only the binary at the unit's own ExecStart path is replaced, then the service restarts. Flags/args preserved by construction. Fresh path (no unit): full first-time setup mirroring the deb postinst and the agent-service docs — create the socktop system user/group and /var/lib/socktop, install docs/socktop-agent.service (ExecStart rewritten to wherever this run installed the agent; embedded fallback for old refs), daemon-reload, enable --now, and print how to turn on TLS/token. Also: system-level operations get their own sudo decision (SYS_SUDO) — previously they inherited the PREFIX sudo flag, so a writable --prefix made the service section run groupadd/systemctl unprivileged and die. No sudo at all now skips service management with a warning instead of failing the install. Both branches dry-run verified with stubbed systemctl/sudo. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(installer): don't bind fresh agent services onto occupied ports The Orange Pi install put the new service straight into a crash-restart loop: the unit's default --port 3000 collided with a Docker service already publishing 3000 (Umami; Gitea and friends default there too). Fresh installs now scan 3000/3001/3010/3231/3232 via ss and configure the unit on the first free port, warning loudly when 3000 was taken and printing the resulting ws:// URL. Upgrades still never touch the unit. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(agent): detect NVIDIA GPUs on distros without the unversioned NVML soname On Debian and derivatives the NVIDIA driver ships only libnvidia-ml.so.1 (the unversioned symlink belongs to the dev package), and nvml-wrapper's default init dlopens the unversioned name — so gfxinfo reported 'No GPU found' on a fully functional RTX A2000 host while nvidia-smi worked fine. Arch-family distros ship the symlink, which is why the desktop never showed this. The GPU worker now falls back to initializing NVML directly with the versioned soname when gfxinfo's probe fails, collecting name/util/vram through the same handle-caching path. nvml-wrapper was already in the tree via gfxinfo — same version, no new build cost. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(agent): box the NVML handle variant (clippy large_enum_variant) CI clippy runs with -D warnings; Nvml is a large struct next to the 16-byte Box<dyn Gpu> variant. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(installer): survive self-modification mid-run; sturdier unit detection Root cause of the mixed-up second install on the A2000 host: when run from the clone it manages, the script's own git checkout/merge REPLACES scripts/install.sh while bash is still executing it. Bash reads scripts lazily by byte offset, so it resumed parsing the NEW file at the OLD offset and executed an arbitrary tail of it — observed as the fresh- service path running on a host whose unit already existed: the port scan saw the still-running old service on 3000 and silently wrote a new unit on 3001, while enable --now on the already-active service changed nothing until a manual daemon-reload. Fix: the whole script now runs inside main(), invoked as 'main "$@"; exit $?' so bash parses everything up front and never reads the file again after main returns (the exit lives in the same parse unit — demonstrated necessary: with a bare 'main "$@"' ending, bash still executed the swapped file's trailing content after main returned). Also: unit existence is now checked with 'systemctl cat' instead of grepping the full list-unit-files output. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs(installer): use a durable ref in the usage example Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
socktop_connector
A WebSocket connector library for communicating with socktop agents.
Overview
socktop_connector provides a high-level, type-safe interface for connecting to socktop agents over WebSocket connections. It handles connection management, TLS certificate pinning, compression, and protocol buffer decoding automatically.
The library is designed for professional use with structured error handling that allows you to pattern match on specific error types, making it easy to implement robust error recovery and monitoring strategies.
Features
- WebSocket Communication: Support for both
ws://andwss://connections - TLS Security: Certificate pinning for secure connections with self-signed certificates
- Hostname Verification: Configurable hostname verification for TLS connections
- Type Safety: Strongly typed requests and responses
- Automatic Compression: Handles gzip compression/decompression transparently
- Protocol Buffer Support: Decodes binary process data automatically
- Error Handling: Comprehensive error handling with structured error types for pattern matching
Connection Types
Non-TLS Connections (ws://)
Use connect_to_socktop_agent() for unencrypted WebSocket connections.
TLS Connections (wss://)
Use connect_to_socktop_agent_with_tls() for encrypted connections with certificate pinning. You can control hostname verification with the verify_hostname parameter.
Quick Start
Add this to your Cargo.toml:
[dependencies]
socktop_connector = "0.1.5"
tokio = { version = "1", features = ["rt", "rt-multi-thread", "net", "time", "macros"] }
Basic Usage
use socktop_connector::{connect_to_socktop_agent, AgentRequest, AgentResponse};
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
// Connect to a socktop agent (non-TLS connections are always unverified)
let mut connector = connect_to_socktop_agent("ws://localhost:3000/ws").await?;
// Request metrics
match connector.request(AgentRequest::Metrics).await? {
AgentResponse::Metrics(metrics) => {
println!("CPU: {}%, Memory: {}/{}MB",
metrics.cpu_total,
metrics.mem_used / 1024 / 1024,
metrics.mem_total / 1024 / 1024
);
}
_ => unreachable!(),
}
// Request process list
match connector.request(AgentRequest::Processes).await? {
AgentResponse::Processes(processes) => {
println!("Total processes: {}", processes.process_count);
for process in processes.top_processes.iter().take(5) {
println!(" {} (PID: {}) - CPU: {}%",
process.name, process.pid, process.cpu_usage);
}
}
_ => unreachable!(),
}
Ok(())
}
Error Handling with Pattern Matching
Take advantage of structured error types for robust error handling:
use socktop_connector::{connect_to_socktop_agent, ConnectorError, AgentRequest};
#[tokio::main]
async fn main() {
// Handle connection errors specifically
let mut connector = match connect_to_socktop_agent("ws://localhost:3000/ws").await {
Ok(conn) => conn,
Err(ConnectorError::WebSocketError(e)) => {
eprintln!("Failed to connect to WebSocket: {}", e);
return;
}
Err(ConnectorError::UrlError(e)) => {
eprintln!("Invalid URL provided: {}", e);
return;
}
Err(e) => {
eprintln!("Connection failed: {}", e);
return;
}
};
// Handle request errors specifically
match connector.request(AgentRequest::Metrics).await {
Ok(response) => println!("Success: {:?}", response),
Err(ConnectorError::JsonError(e)) => {
eprintln!("Failed to parse server response: {}", e);
}
Err(ConnectorError::WebSocketError(e)) => {
eprintln!("Communication error: {}", e);
}
Err(e) => eprintln!("Request failed: {}", e),
}
}
TLS with Certificate Pinning
use socktop_connector::{connect_to_socktop_agent_with_tls, AgentRequest};
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
// Connect with TLS certificate pinning and hostname verification
let mut connector = connect_to_socktop_agent_with_tls(
"wss://remote-host:8443/ws",
"/path/to/cert.pem",
false // Enable hostname verification
).await?;
let response = connector.request(AgentRequest::Disks).await?;
println!("Got disk info: {:?}", response);
Ok(())
}
Advanced Configuration
use socktop_connector::{ConnectorConfig, SocktopConnector, AgentRequest};
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
// Create a custom configuration
let config = ConnectorConfig::new("wss://remote-host:8443/ws")
.with_tls_ca("/path/to/cert.pem")
.with_hostname_verification(false);
// Create and connect
let mut connector = SocktopConnector::new(config);
connector.connect().await?;
// Make requests
let response = connector.request(AgentRequest::Metrics).await?;
// Clean disconnect
connector.disconnect().await?;
Ok(())
}
WebSocket Protocol Configuration
For version compatibility (if applies), you can configure WebSocket protocol version and sub-protocols:
use socktop_connector::{ConnectorConfig, SocktopConnector, connect_to_socktop_agent_with_config};
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
// Method 1: Using the convenience function
let connector = connect_to_socktop_agent_with_config(
"ws://localhost:3000/ws",
Some(vec!["socktop".to_string(), "v1".to_string()]), // Sub-protocols
Some("13".to_string()), // WebSocket version (13 is standard)
).await?;
// Method 2: Using ConnectorConfig builder
let config = ConnectorConfig::new("ws://localhost:3000/ws")
.with_protocols(vec!["socktop".to_string()])
.with_version("13");
let mut connector = SocktopConnector::new(config);
connector.connect().await?;
Ok(())
}
Note: WebSocket version 13 is the current standard and is used by default. The sub-protocols feature is useful for protocol negotiation with servers that support multiple protocols.
Continuous Updates
The socktop agent provides real-time system metrics. Each request returns the current snapshot, but you can implement continuous monitoring by making requests in a loop:
use socktop_connector::{connect_to_socktop_agent, AgentRequest, AgentResponse, ConnectorError};
use tokio::time::{sleep, Duration};
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
let mut connector = connect_to_socktop_agent("ws://localhost:3000/ws").await?;
// Monitor system metrics every 2 seconds
loop {
match connector.request(AgentRequest::Metrics).await {
Ok(AgentResponse::Metrics(metrics)) => {
// Calculate total network activity across all interfaces
let total_rx: u64 = metrics.networks.iter().map(|n| n.received).sum();
let total_tx: u64 = metrics.networks.iter().map(|n| n.transmitted).sum();
println!("CPU: {:.1}%, Memory: {:.1}%, Network: ↓{} ↑{}",
metrics.cpu_total,
(metrics.mem_used as f64 / metrics.mem_total as f64) * 100.0,
format_bytes(total_rx),
format_bytes(total_tx)
);
}
Err(e) => {
eprintln!("Error getting metrics: {}", e);
// You can pattern match on specific error types for different handling
match e {
socktop_connector::ConnectorError::WebSocketError(_) => {
eprintln!("Connection lost, attempting to reconnect...");
// Implement reconnection logic here
break;
}
socktop_connector::ConnectorError::JsonError(_) => {
eprintln!("Data parsing error, continuing...");
// Continue with next iteration for transient parsing errors
}
_ => {
eprintln!("Other error, stopping monitoring");
break;
}
}
}
_ => unreachable!(),
}
sleep(Duration::from_secs(2)).await;
}
Ok(())
}
fn format_bytes(bytes: u64) -> String {
const UNITS: &[&str] = &["B", "KB", "MB", "GB"];
let mut size = bytes as f64;
let mut unit_index = 0;
while size >= 1024.0 && unit_index < UNITS.len() - 1 {
size /= 1024.0;
unit_index += 1;
}
format!("{:.1}{}", size, UNITS[unit_index])
}
Understanding Data Freshness
The socktop agent implements intelligent caching to avoid overwhelming the system:
- Metrics: Cached for ~250ms by default (cheap / fast-changing data like CPU, memory)
- Processes: Cached for ~1500ms by default (exppensive / moderately changing data)
- Disks: Cached for ~1000ms by default (cheap / slowly changing data)
These values have been generally tuned in advance. You should not need to override them. The reason for this cache is for the use case that multiple clients are requesting data. In general a single client should never really hit a cached response since the polling rates are slower that the cache intervals. Cache intervals have been tuned based on how much work the agent has to do in the case of reloading fresh data.
This means:
- Multiple rapid requests for the same data type will return cached results
- Different data types have independent cache timers
- Fresh data is automatically retrieved when cache expires
use socktop_connector::{connect_to_socktop_agent, AgentRequest, AgentResponse};
use tokio::time::{sleep, Duration};
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
let mut connector = connect_to_socktop_agent("ws://localhost:3000/ws").await?;
// This demonstrates cache behavior
println!("Requesting metrics twice quickly...");
// First request - fresh data from system
let start = std::time::Instant::now();
connector.request(AgentRequest::Metrics).await?;
println!("First request took: {:?}", start.elapsed());
// Second request immediately - cached data
let start = std::time::Instant::now();
connector.request(AgentRequest::Metrics).await?;
println!("Second request took: {:?}", start.elapsed()); // Much faster!
// Wait for cache to expire, then request again
sleep(Duration::from_millis(300)).await;
let start = std::time::Instant::now();
connector.request(AgentRequest::Metrics).await?;
println!("Third request (after cache expiry): {:?}", start.elapsed());
Ok(())
}
The WebSocket connection remains open between requests, providing efficient real-time monitoring without connection overhead.
Request Types
The library supports three types of requests:
AgentRequest::Metrics- Get current system metrics (CPU, memory, network, etc.)AgentRequest::Disks- Get disk usage informationAgentRequest::Processes- Get running process information
Response Types
Responses are automatically parsed into strongly-typed structures:
AgentResponse::Metrics(Metrics)- System metrics with CPU, memory, network dataAgentResponse::Disks(Vec<DiskInfo>)- List of disk usage informationAgentResponse::Processes(ProcessesPayload)- Process list with CPU and memory usage
Configuration Options
The library provides flexible configuration through the ConnectorConfig builder:
with_tls_ca(path)- Enable TLS with certificate pinningwith_hostname_verification(bool)- Control hostname verification for TLS connectionstrue(recommended): Verify the server hostname matches the certificatefalse: Skip hostname verification (useful for localhost or IP-based connections)
with_protocols(Vec<String>)- Set WebSocket sub-protocols for protocol negotiationwith_version(String)- Set WebSocket protocol version (default is "13", the current standard)
Note: Hostname verification only applies to TLS connections (wss://). Non-TLS connections (ws://) don't use certificates, so hostname verification is not applicable.
WASM Compatibility (experimental)
socktop_connector provides full WebSocket support for WebAssembly (WASM) environments, including complete networking functionality with automatic compression and protobuf decoding.
Quick Setup
[dependencies]
socktop_connector = { version = "0.1.5", default-features = false, features = ["wasm"] }
wasm-bindgen = "0.2"
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"
What Works
- ✅ Full WebSocket connectivity (
ws://connections) - ✅ All request types (
Metrics,Disks,Processes) - ✅ Automatic gzip decompression for metrics and disks
- ✅ Automatic protobuf decoding for process data
- ✅ All types (
ConnectorConfig,AgentRequest,AgentResponse) - ✅ JSON serialization/deserialization
- ✅ Protocol and version configuration
What Doesn't Work
- ❌ TLS connections (
wss://) - usews://only - ❌ TLS certificate handling
Basic WASM Usage
use wasm_bindgen::prelude::*;
use socktop_connector::{ConnectorConfig, SocktopConnector, AgentRequest};
#[wasm_bindgen]
pub async fn test_connection() {
let config = ConnectorConfig::new("ws://localhost:3000/ws");
let mut connector = SocktopConnector::new(config);
match connector.connect().await {
Ok(()) => {
// Request metrics with automatic gzip decompression
let response = connector.request(AgentRequest::Metrics).await.unwrap();
console_log!("Got metrics: {:?}", response);
// Request processes with automatic protobuf decoding
let response = connector.request(AgentRequest::Processes).await.unwrap();
console_log!("Got processes: {:?}", response);
}
Err(e) => console_log!("Connection failed: {}", e),
}
}
Complete WASM Guide
For detailed implementation examples, complete code samples, and a working test environment, see the WASM Compatibility Guide in the socktop_wasm_test/ directory.
Security Considerations
- Production TLS: You can enable hostname verification (
verify_hostname: true) for production systems, This will add an additional level of production of verifying the hostname against the certificate. Generally this is to stop a man in the middle attack, but since it will be the client who is fooled and not the server, the risk and likelyhood of this use case is rather low. Which is why this is disabled by default. - Certificate Pinning: Use
with_tls_ca()for self-signed certificates, the socktop agent will generate certificates on start. see main readme for more details. - Non-TLS: Use only for development or trusted networks
Environment Variables
Currently no environment variables are used. All configuration is done through the API.
Error Handling
The library uses structured error types via thiserror for comprehensive error handling. You can pattern match on specific error types:
use socktop_connector::{connect_to_socktop_agent, ConnectorError, AgentRequest};
#[tokio::main]
async fn main() {
match connect_to_socktop_agent("invalid://url").await {
Ok(mut connector) => {
// Handle successful connection
match connector.request(AgentRequest::Metrics).await {
Ok(response) => println!("Got response: {:?}", response),
Err(ConnectorError::WebSocketError(e)) => {
eprintln!("WebSocket communication failed: {}", e);
}
Err(ConnectorError::JsonError(e)) => {
eprintln!("Failed to parse response: {}", e);
}
Err(e) => eprintln!("Other error: {}", e),
}
}
Err(ConnectorError::UrlError(e)) => {
eprintln!("Invalid URL: {}", e);
}
Err(ConnectorError::WebSocketError(e)) => {
eprintln!("Failed to connect: {}", e);
}
Err(ConnectorError::TlsError(msg)) => {
eprintln!("TLS error: {}", msg);
}
Err(e) => {
eprintln!("Connection failed: {}", e);
}
}
}
Error Types
The ConnectorError enum provides specific variants for different error conditions:
ConnectorError::WebSocketError- WebSocket connection or communication errorsConnectorError::TlsError- TLS-related errors (certificate validation, etc.)ConnectorError::UrlError- URL parsing errorsConnectorError::JsonError- JSON serialization/deserialization errorsConnectorError::ProtocolError- Protocol-level errorsConnectorError::CompressionError- Gzip compression/decompression errorsConnectorError::IoError- I/O errorsConnectorError::Other- Other errors with descriptive messages
All errors implement std::error::Error so they work seamlessly with Box<dyn std::error::Error>, anyhow, and other error handling crates.
Migration from Generic Errors
If you were previously using the library with generic error handling, your existing code will continue to work:
// This continues to work as before
async fn my_function() -> Result<(), Box<dyn std::error::Error>> {
let mut connector = connect_to_socktop_agent("ws://localhost:3000/ws").await?;
let response = connector.request(AgentRequest::Metrics).await?;
Ok(())
}
// But now you can also use structured error handling for better control
async fn improved_function() -> Result<(), ConnectorError> {
let mut connector = connect_to_socktop_agent("ws://localhost:3000/ws").await?;
let response = connector.request(AgentRequest::Metrics).await?;
Ok(())
}
License
MIT License - see the LICENSE file for details.