WebSocket Server

Loading…

WebSocket Server

Relevant source files

• Cargo.lock
• experiments/simd-r-drive-muxio-service-definition/Cargo.toml
• experiments/simd-r-drive-ws-client/Cargo.toml
• experiments/simd-r-drive-ws-server/Cargo.toml

Purpose and Scope

The WebSocket Server provides remote network access to the SIMD R Drive storage engine through an RPC-based interface. This experimental component enables clients to perform storage operations over WebSocket connections using the muxio RPC framework with bitcode serialization.

This page covers the server implementation, configuration, and connection handling. For information about the RPC protocol and service definitions, see Muxio RPC Framework. For client-side implementation, see Native Rust Client. For the underlying storage operations, see DataStore API.

Sources: experiments/simd-r-drive-ws-server/Cargo.toml:1-23

Server Architecture

The WebSocket Server acts as a bridge between remote clients and the local storage engine, handling WebSocket connections, deserializing RPC requests, executing storage operations, and returning serialized responses.

graph TB
    subgraph "simd-r-drive-ws-server"
        MAIN["main.rs\nServer Entry Point"]
CLI["clap Parser\nCLI Arguments"]
SERVER["muxio-tokio-rpc-server\nWebSocket Server"]
SERVICE["Service Implementation\nRPC Handler"]
end
    
    subgraph "Dependencies"
        DEFINITION["simd-r-drive-muxio-service-definition\nService Contract"]
CORE["simd-r-drive\nDataStore"]
TOKIO["tokio Runtime\nAsync Executor"]
TRACING["tracing-subscriber\nLogging"]
end
    
    subgraph "Network"
        WS_CONN["WebSocket Connection\ntokio-tungstenite"]
CLIENT["Remote Client"]
end
    
 
   MAIN --> CLI
 
   MAIN --> TRACING
 
   MAIN --> SERVER
 
   SERVER --> SERVICE
 
   SERVICE --> DEFINITION
 
   SERVICE --> CORE
 
   SERVER --> TOKIO
 
   SERVER --> WS_CONN
 
   WS_CONN --> CLIENT
    
    style SERVER fill:#f9f9f9
    style SERVICE fill:#f9f9f9
    style CORE fill:#e8e8e8

Component Overview

Sources: experiments/simd-r-drive-ws-server/Cargo.toml:13-23

Server Implementation

Package Structure

The simd-r-drive-ws-server package implements the WebSocket server as an experimental component in the workspace. It provides a binary that can be executed to start the server.

Service Implementation Flow

Sources: experiments/simd-r-drive-ws-server/Cargo.toml:13-18

Configuration and Startup

Command-Line Arguments

The server uses clap for CLI argument parsing with the derive feature, providing a structured interface for configuration.

Expected Configuration Options

Initialization Sequence

The server initialization creates a local DataStore instance which is then accessed by the service handler for all RPC operations. The tracing-subscriber dependency with env-filter feature allows runtime configuration of logging levels.

Sources: experiments/simd-r-drive-ws-server/Cargo.toml:19-22

Connection Handling

WebSocket Lifecycle

The muxio-tokio-rpc-server package handles the WebSocket protocol details, including:

1. Connection Upgrade : HTTP to WebSocket protocol upgrade
2. Message Framing : Binary message framing over WebSocket
3. Multiplexing : Multiple concurrent RPC calls over a single connection
4. Error Handling : Connection errors and RPC-level errors

Connection State Management

Each WebSocket connection is handled by a separate tokio task, allowing concurrent client connections without blocking.

Sources: experiments/simd-r-drive-ws-server/Cargo.toml:16-18

Service Implementation Details

RPC Service Interface

The service implementation must implement the interface defined in simd-r-drive-muxio-service-definition. This shared contract ensures type-safe communication between client and server.

Service Methods

Based on the DataStore API and typical RPC patterns, the service likely implements these methods:

Service Handler Structure

The service handler wraps a shared reference to the DataStore (likely Arc<DataStore>) to allow concurrent read access across multiple RPC calls while serializing writes through the DataStore’s internal concurrency control.

Sources: experiments/simd-r-drive-ws-server/Cargo.toml:13-17 experiments/simd-r-drive-muxio-service-definition/Cargo.toml:1-17

Dependencies and Runtime

Core Dependencies

muxio-tokio-rpc-server

The muxio-tokio-rpc-server package provides the WebSocket server implementation built on top of:

• axum for HTTP/WebSocket handling
• tokio for async runtime
• muxio-rpc-service-endpoint for RPC dispatch

graph TB
    subgraph "tokio Runtime"
        MULTI["Multi-threaded\nExecutor"]
REACTOR["Reactor\nI/O Events"]
TIMER["Timer\nTimeouts"]
end
    
    subgraph "Server Tasks"
        LISTENER["Listener Task\nAccept Connections"]
CONN1["Connection Task 1\nClient 1"]
CONN2["Connection Task 2\nClient 2"]
CONNN["Connection Task N\nClient N"]
end
    
 
   MULTI --> LISTENER
 
   MULTI --> CONN1
 
   MULTI --> CONN2
 
   MULTI --> CONNN
    
 
   REACTOR --> LISTENER
 
   REACTOR --> CONN1
 
   REACTOR --> CONN2
 
   REACTOR --> CONNN

Serialization

The service uses bitcode for binary serialization, shared through the simd-r-drive-muxio-service-definition package. Bitcode provides compact binary encoding with zero-copy deserialization where possible.

Async Runtime

The server runs on the tokio multi-threaded runtime, with each WebSocket connection handled by an independent task. This allows efficient concurrent handling of multiple clients.

Sources: experiments/simd-r-drive-ws-server/Cargo.toml:16-20

Logging and Observability

tracing Integration

The server uses tracing with tracing-subscriber for structured logging. The env-filter feature allows configuration via environment variables:

Log Levels

Key Trace Points

The server likely includes trace instrumentation at:

• Server initialization and configuration
• WebSocket connection establishment
• RPC method dispatch
• DataStore operation execution
• Error conditions and recovery

Sources: experiments/simd-r-drive-ws-server/Cargo.toml:19-20

Building and Running

Build Command

Run Command Example

Development Mode

For development with detailed logging:

Sources: experiments/simd-r-drive-ws-server/Cargo.toml:1-23

Security Considerations

Network Exposure

The WebSocket server exposes the DataStore over the network. Important considerations:

1. Authentication : The current implementation does not include authentication (experimental status)
2. Encryption : WebSocket connections are not TLS-encrypted by default
3. Access Control : No per-key or per-operation access control
4. Network Binding : Binding to 0.0.0.0 exposes the server to all network interfaces

Recommended Production Practices

For production deployment, additional layers would be needed:

• TLS/SSL termination (via reverse proxy or native support)
• Authentication middleware
• Rate limiting
• Request validation
• Network-level access control (firewall rules)

Note: This is an experimental component and should not be used in production without additional security hardening.

Sources: experiments/simd-r-drive-ws-server/Cargo.toml:1-11

Integration with Core Storage

DataStore Access Pattern

The server maintains a single DataStore instance that is shared across all RPC handlers. Write operations serialize through the DataStore’s internal RwLock, while read operations can proceed concurrently through the lock-free DashMap index.

Thread Safety

The server implementation relies on the DataStore’s thread-safe design:

• Multiple concurrent reads via DashMap
• Serialized writes via RwLock
• Atomic tail offset tracking via AtomicU64

This allows multiple WebSocket connections to safely access the same DataStore instance without additional synchronization.

Sources: experiments/simd-r-drive-ws-server/Cargo.toml:14-15

Dismiss

Refresh this wiki

Enter email to refresh