How do I install the Websocket Connection skill?

Run npx skillmds@latest add lichtblick-suite/websocket-connection in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Websocket Connection safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Websocket Connection?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Websocket Connection free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Websocket Connection?

lichtblick-suite (@lichtblick-suite) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Websocket Connection by lichtblick-suite

Name: Websocket Connection
Author: lichtblick-suite

Websocket Connection

Deep WebSocket connection knowledge: FoxgloveWebSocketPlayer state machine, WorkerSocketAdapter postMessage protocol, the Foxglove WebSocket protocol handshake, RAF-based state emission, and reconnection.

File contents

WebSocket Connection Skill

The real-time data path from a robot/simulation/bridge to visualization.

Architecture

Foxglove WebSocket Server (robot/bridge)
    │  WebSocket protocol
    ▼
WorkerSocketAdapter (Worker thread)
    │  postMessage (raw, not Comlink)
    ▼
FoxgloveWebSocketPlayer (main thread)
    │
    ▼
MessagePipeline → Panels

Core Files

File	Role
`packages/suite-base/src/players/FoxgloveWebSocketPlayer/index.ts`	Player implementation for WebSocket connections
`packages/suite-base/src/players/FoxgloveWebSocketPlayer/WorkerSocketAdapter.ts`	Offloads WebSocket I/O to a Worker
`packages/suite-base/src/players/FoxgloveWebSocketPlayer/worker.ts`	Worker-side WebSocket handling

Foxglove WebSocket Protocol

Connection Lifecycle

Server sends serverInfo (capabilities, session ID)
Server sends advertise with available channels (topic + schema)
Client sends subscribe with channel IDs
Server streams messageData binary frames
Client can publish messages back to the server

Key Operations

serverInfo — server capabilities, session ID
advertise / unadvertise — channel availability (topics can appear/disappear)
subscribe / unsubscribe — client topic selection
messageData — binary message payload with channel ID + timestamp
time — server clock synchronization
parameterValues — server parameters

FoxgloveWebSocketPlayer

Message Processing

Messages arrive as binary frames via WebSocket
Deserialized on the main thread (unlike file-based players, which decode in a Worker)
Accumulated in a parsedMessages queue
Queue flushed on requestAnimationFrame → emits state to the pipeline

Connection Management

Auto-reconnect with exponential backoff
Handles advertise/unadvertise dynamically
Subscription changes are sent immediately to the server (no debounce)

State Emission

requestAnimationFrame-driven flush of the message queue
Coalesces all messages received between frames into one state update (max ~60 updates/sec)
Prevents UI thrashing during high-frequency bursts

WorkerSocketAdapter

The WebSocket connection lives in a dedicated Worker
Avoids main-thread blocking during TLS handshake / large frame parsing
Communicates with the main thread via raw postMessage (not Comlink)
Binary frames are transferred (zero-copy) using Transferable ArrayBuffers

Performance Notes

Main-thread deserialization — current limitation; high message rates can drop frames
RAF-based flush — batches messages per animation frame
Binary transfer — ArrayBuffer transferred from the Worker (zero-copy)
Subscription filtering — only subscribed topics are sent → reduces bandwidth
Backpressure — if the main thread can't keep up, messages queue in the Worker

Skills Reference

For Worker patterns: load web-workers skill
For deserialization of incoming frames: load deserialization skill

---name: websocket-connectiondescription: Deep WebSocket connection knowledge: FoxgloveWebSocketPlayer state machine, WorkerSocketAdapter postMessage protocol, the Foxglove WebSocket protocol handshake, RAF-based state emission, and reconnection.---# WebSocket Connection SkillThe real-time data path from a robot/simulation/bridge to visualization.## Architecture```textFoxglove WebSocket Server (robot/bridge) │ WebSocket protocol ▼WorkerSocketAdapter (Worker thread) │ postMessage (raw, not Comlink) ▼FoxgloveWebSocketPlayer (main thread) │ ▼MessagePipeline → Panels```## Core Files| File | Role ||------|------|| `packages/suite-base/src/players/FoxgloveWebSocketPlayer/index.ts` | Player implementation for WebSocket connections || `packages/suite-base/src/players/FoxgloveWebSocketPlayer/WorkerSocketAdapter.ts` | Offloads WebSocket I/O to a Worker || `packages/suite-base/src/players/FoxgloveWebSocketPlayer/worker.ts` | Worker-side WebSocket handling |## Foxglove WebSocket Protocol### Connection Lifecycle1. Server sends `serverInfo` (capabilities, session ID)2. Server sends `advertise` with available channels (topic + schema)3. Client sends `subscribe` with channel IDs4. Server streams `messageData` binary frames5. Client can `publish` messages back to the server### Key Operations- `serverInfo` — server capabilities, session ID- `advertise` / `unadvertise` — channel availability (topics can appear/disappear)- `subscribe` / `unsubscribe` — client topic selection- `messageData` — binary message payload with channel ID + timestamp- `time` — server clock synchronization- `parameterValues` — server parameters## FoxgloveWebSocketPlayer### Message Processing- Messages arrive as binary frames via WebSocket- **Deserialized on the main thread** (unlike file-based players, which decode in a Worker)- Accumulated in a `parsedMessages` queue- Queue flushed on `requestAnimationFrame` → emits state to the pipeline### Connection Management- Auto-reconnect with exponential backoff- Handles `advertise`/`unadvertise` dynamically- Subscription changes are sent immediately to the server (no debounce)### State Emission- `requestAnimationFrame`-driven flush of the message queue- Coalesces all messages received between frames into one state update (max ~60 updates/sec)- Prevents UI thrashing during high-frequency bursts## WorkerSocketAdapter- The WebSocket connection lives in a dedicated Worker- Avoids main-thread blocking during TLS handshake / large frame parsing- Communicates with the main thread via raw `postMessage` (**not** Comlink)- Binary frames are **transferred** (zero-copy) using `Transferable` `ArrayBuffer`s## Performance Notes1. **Main-thread deserialization** — current limitation; high message rates can drop frames2. **RAF-based flush** — batches messages per animation frame3. **Binary transfer** — `ArrayBuffer` transferred from the Worker (zero-copy)4. **Subscription filtering** — only subscribed topics are sent → reduces bandwidth5. **Backpressure** — if the main thread can't keep up, messages queue in the Worker## Skills Reference- For Worker patterns: load `web-workers` skill- For deserialization of incoming frames: load `deserialization` skill

Frequently asked questions