Skip to content

ThunderBroker

Vinod Sathyaseelan edited this page Aug 14, 2025 · 3 revisions

Thunder Broker

The Thunder Broker is a specialized component in Ripple that manages communication with Thunder plugins through WebSocket connections.

Overview

The Thunder Broker provides a reliable communication channel between Ripple and Thunder plugins. It handles connection management, request routing, and event subscription for Thunder-based services.

Key Components

ThunderClient

  • Manages WebSocket connections to Thunder
  • Handles request/response cycles
  • Manages subscriptions to Thunder events
  • Provides connection pooling capabilities

Thunder Message Types

  1. ThunderCallMessage

    • Used for one-time RPC calls
    • Contains method, parameters, and callback
  2. ThunderSubscribeMessage

    • Used for event subscriptions
    • Manages ongoing event streams
    • Contains module, event name, and handlers
  3. ThunderUnsubscribeMessage

    • Handles subscription cleanup
    • Removes event listeners

Features

Connection Management

  • Automatic reconnection handling
  • Connection state monitoring
  • Token-based authentication support
  • Pooled connections for better resource utilization

Request Handling

  • Asynchronous request processing
  • Response transformation
  • Error handling and recovery
  • Request queuing during reconnection

Subscription Management

  • Event subscription tracking
  • Multiple handler support per subscription
  • Automatic resubscription after reconnection
  • Subscription cleanup on disconnect

Plugin Management

  • Plugin activation checking
  • Automatic plugin activation
  • Plugin state monitoring
  • Version compatibility checking

Implementation Details

Connection States

  1. Connected
  2. Disconnected
  3. Reconnecting
  4. Error

Message Flow

  1. Request received from client
  2. Message wrapped in appropriate Thunder format
  3. Sent through WebSocket connection
  4. Response received and transformed
  5. Result returned to client

Subscription Flow

  1. Subscribe request received
  2. Thunder subscription established
  3. Event handlers registered
  4. Events forwarded to handlers
  5. Subscription maintained across reconnections

Error Handling

The Thunder Broker implements comprehensive error handling:

  • Connection failures
  • Message timeouts
  • Plugin activation failures
  • Subscription errors
  • Response validation

Performance Optimization

Connection Pooling

  • Multiple connections managed
  • Load balancing across connections
  • Connection reuse
  • Pool size management

Message Batching

  • Groups related messages
  • Reduces connection overhead
  • Improves throughput

Caching

  • Plugin state caching
  • Connection state caching
  • Response caching where appropriate

Best Practices

  1. Make sure that the plugin is activated before sending requests
  2. Implement proper error handling
  3. Clean up subscriptions when no longer needed
  4. Monitor connection health
  5. Use appropriate timeout values
  6. Handle reconnection scenarios gracefully

See also

Clone this wiki locally