Market Data Relay Server

From Spire Trading Inc.
Jump to: navigation, search

Market Data Relay Server

The Market Data Relay Server provides load-balanced distribution of market data to end users. It acts as an intermediary layer between the Market Data Server and client applications, receiving market data updates from the Market Data Server and relaying them to subscribed clients. By deploying multiple relay servers in parallel, the system can distribute client connections across instances, ensuring scalable and resilient market data delivery.

The Market Data Relay Server integrates with the Service Locator for authentication and service registration. Multiple relay servers can operate concurrently to distribute load across the infrastructure.

Configuration

The Market Data Relay Server is configured via a YAML file that defines its network interface and Service Locator integration. Below is the structure of the configuration file with example values:

---
server:
  # Primary network interface and port the Market Data Relay Server binds to.
  interface: "0.0.0.0:22300"
  
  # List of addresses the server is reachable at (for registration with Service Locator).
  # Typically includes both public-facing and local addresses.
  addresses: ["198.51.100.5:22300", "10.0.0.5:22300"]

service_locator:
  # The address of the Service Locator (host:port).
  address: "10.0.0.5:20000"
  
  # The account username used by the Market Data Relay Server to authenticate with the Service Locator.
  username: market_data_relay_service
  
  # The password for the Market Data Relay Server's Service Locator account.
  password: admin_password
...

Architecture

The market data distribution architecture consists of three tiers:

  1. Feed Clients publish raw market data to the Market Data Server
  2. Market Data Server organizes, sequences, and persists market data
  3. Market Data Relay Servers distribute market data to end-user clients

This architecture separates data processing from distribution, allowing the Market Data Server to focus on sequencing and storage while relay servers handle the potentially large number of client connections. Multiple relay servers can be deployed to distribute client load geographically or by capacity requirements.

Installation & Setup

A setup.py script is provided to generate the final config.yml from the config.default.yml template.

The script supports the following arguments:

python setup.py
  --local 0.0.0.0           # Local interface (default: auto-detected IP)
  --world 198.51.100.5      # Global/public interface (optional)
  --address 10.0.0.5:20000  # Service Locator address (default: local_interface:20000)
  --password [REQUIRED]     # Service password for authentication

Operations

The Market Data Relay Server is controlled using three operational scripts: start.sh, stop.sh, and check.sh.

Log files are generated in the format:

srv_YYYYMMDD_HH_MM_SS.log

Upon startup, older log files are moved into the logs/ directory.

check.sh

The check.sh script verifies whether the server is currently running by inspecting the PID recorded in pid.lock and testing whether the associated process exists.

If the server is not running, it prints:

MarketDataRelayServer is not running.

start.sh

The start.sh script:

  • Exits immediately if the server is already running
  • Creates a logs/ directory if necessary
  • Moves any existing srv_*.log files into logs/
  • Starts the MarketDataRelayServer process in the background
  • Writes the PID to pid.lock
  • Reads network interfaces from config.yml and waits until the server is listening on at least one configured address

This ensures the server is fully initialized before the script exits.

stop.sh

The stop.sh script:

  • Reads the PID from pid.lock
  • Sends SIGINT to request a graceful shutdown
  • Waits for termination using exponential backoff (up to 300 seconds)
  • Sends SIGKILL if the server fails to stop cleanly
  • Appends a forced-termination message to the most recent log file (if applicable)
  • Removes the pid.lock file

This guarantees consistent shutdown behavior across normal and exceptional conditions.