Technical Architecture

System Components

Self Service consists of the following core components, forming a complete decentralized service ecosystem:

MarsApp Frontend

• Role: User interaction interface and request initiator

• Core Capabilities:

  • Protocol conversion from HTTP requests to P2P messages

  • Response result reception and display

  • Local caching and offline processing

MarsX Node

• Role: Efficient routing and forwarding dedicated to Self Service messages

• Core Capabilities:

  • Intelligent routing algorithms optimizing transmission paths

  • Load balancing avoiding single-node overload

  • Message encryption and forwarding

  • Network topology maintenance and optimization

Regular Node

• Role: General P2P network node

• Core Capabilities:

  • Participate in message forwarding, increasing network complexity

  • Provide random routing paths

  • Enhance network anonymity and censorship resistance

Self Service Node

• Role: Bridge between P2P network and traditional application services

• Core Capabilities:

  • Protocol conversion from P2P messages to HTTP requests

  • Application service access and management

  • Request verification and permission control

  • Response data encapsulation and return

Application Service

• Role: Actual business logic processing unit

• Core Capabilities:

  • Maintain existing business logic unchanged

  • Communicate only with Self Service nodes, completely hiding public network addresses

  • Standard HTTP API interfaces

Network Topology

Request Processing Flow

Complete Call Chain

Key Processing Steps

1

Request Initiation Stage

• User initiates API call through RelayApp frontend

• Frontend performs identity verification and request format validation

• Generate unique request ID for response matching

2

Protocol Conversion Stage (Request)

• RelayApp encapsulates HTTP request and sends to RelayX Client

• RelayX Client converts request to P2P network message format

• Encrypt request content and add routing information

3

Network Transmission Stage

• RelayX Client sends P2P message to network

• Message forwarded through multiple random nodes

• Nodes select forwarding paths based on network topology and routing algorithms

4

Service Invocation Stage

• Self Service Node receives P2P message

• Convert to standard HTTP request format

• Call corresponding application service endpoint

5

Response Return Stage

• Application service returns processing results

• Self Service Node encapsulates as P2P message

• Return to RelayX Client through random network paths

6

Protocol Conversion Stage (Response)

• RelayX Client receives P2P response message

• Convert to standard HTTP response format

• Return to RelayApp frontend for user display

Technical Features and Limitations

Core Features

• Latency: Average 1-3 seconds response time, affected by local network

• Message Size: Maximum 10 MiB per message, exceeding messages are directly discarded

• Consistency: Eventual consistency model, suitable for distributed scenarios

• Concurrency: Single node supports medium-low concurrency, overall network can scale horizontally

Application Scenario Analysis

Unsuitable Scenarios

• High real-time requirements: Game operations, high-frequency trading, instant messaging

• Strong consistency requirements: Bank transfers, inventory deduction, order payments

• High concurrency intensive: Flash sales, hotspot data access, high-traffic APIs

• Ultra-large data transmission: Video streaming, large file downloads, real-time synchronization

Suitable Scenarios

• Asynchronous processing: Message notifications, email sending, background task scheduling

• Content management: Article publishing, comment systems, user profile updates

• Data synchronization: Configuration updates, state synchronization, log collection

• Lightweight interaction: Form submission, data queries, simple CRUD operations

• Privacy protection: Anonymous voting, privacy social, sensitive data processing