tokio_ipc
A high-performance, multi-protocol RPC framework built on top of tokio_socket, enabling type-safe inter-process communication with support for multiple protocols over a single connection.
Features
- Multi-Protocol Support: Run multiple protocols over a single connection
- Type-Safe RPC: Compile-time checked request/response types using macros
- Bidirectional Communication: Both client and server can initiate calls
- Protocol Multiplexing: Route messages to different handlers based on protocol ID
- Zero-Copy Serialization: Efficient binary protocol using bincode
- Async/Await: Built on Tokio for high-performance async I/O
Quick Start
Define your protocols using the protocol! macro:
use protocol;
protocol!
Implement the protocol handler:
;
Examples
The examples/ directory contains comprehensive real-world examples demonstrating various use cases:
Basic Example (basic.rs)
The simplest multi-protocol example showing:
- Two protocols on a single handler (
app_protocol+admin_protocol) - Request/response RPC calls
- Auto-generated sender/receiver types
- Minimal boilerplate
Run it:
# Demo mode (integrated)
# Separate processes
Bidirectional Example (bidirectional.rs)
Demonstrates full-duplex communication:
- Server calling methods on the client
- Client calling methods on the server
- Push notifications from server to client
- Bidirectional RPC patterns
Run it:
File Transfer Example (file_transfer.rs)
Real-world file transfer with progress tracking:
- Protocols:
file_protocol+progress_protocol - Chunked data transfer with configurable chunk size
- Progress updates sent from server to client
- Checksum verification on completion
- Flow control and error handling
Key Features:
- Demonstrates one-way messages (chunks) and request/response (file request)
- Shows bidirectional communication (server pushes progress updates)
- Realistic data streaming patterns
Run it:
Database Example (database.rs)
In-memory database with transaction support:
- Protocols:
db_protocol+replication_protocol - ACID transaction support (begin, commit, rollback)
- In-memory key-value store
- Write replication to clients
- Transaction isolation
Key Features:
- Demonstrates stateful protocol handlers
- Shows transaction management patterns
- Illustrates replication via bidirectional protocols
Run it:
Service Mesh Example (service_mesh.rs)
Service discovery and health monitoring:
- Protocols:
service_protocol+health_protocol+discovery_protocol - Service registration and discovery
- Health check monitoring
- Metrics collection and reporting
- Service-to-service RPC routing
Key Features:
- Demonstrates three protocols working together
- Shows service registry patterns
- Illustrates health monitoring and metrics
Run it:
# Demo mode
# Separate processes
Multi-Protocol Patterns
Single Handler, Multiple Protocols
Implement multiple protocol traits on one handler:
// Generate sender and receiver
protocol_sender!
Protocol Registry
Compose protocols at runtime:
let registry = registry! ;
Bidirectional Protocols
Server can call client methods:
// Server handler receives client sender
Protocol Design Guidelines
Separation of Concerns
Each protocol should handle one aspect of functionality:
- Data Protocol: File transfer, database operations
- Control Protocol: Service registration, configuration
- Monitoring Protocol: Health checks, metrics, logging
Message Types
- Request/Response: Use
-> { fields }for operations that need acknowledgment - One-Way: Omit return type for fire-and-forget notifications
- No Parameters: Omit request fields for simple queries
Protocol Versioning
Protocol IDs are auto-generated from name + version:
Testing
All examples have comprehensive integration tests in tests/test_new_examples.rs:
# Run all example tests
# Run specific example test
Tests verify:
- Demo mode execution
- Separate server/client processes
- Protocol message exchange
- Error handling
- Proper cleanup
Architecture
┌─────────────────────────────────────────────────────────────┐
│ Application Layer │
│ (Your protocol implementations: Receive + Sender traits) │
└─────────────────────────────────────────────────────────────┘
│
┌─────────────────────────────────────────────────────────────┐
│ Protocol Layer (tokio_ipc) │
│ • Protocol multiplexing (protocol_id routing) │
│ • RPC packet handling (request/response matching) │
│ • Serialization (bincode) │
└─────────────────────────────────────────────────────────────┘
│
┌─────────────────────────────────────────────────────────────┐
│ Transport Layer (tokio_socket) │
│ • Socket abstraction (TCP/UDS) │
│ • Packet framing (length-prefixed) │
│ • Connection management │
└─────────────────────────────────────────────────────────────┘
Performance Considerations
- Zero-Copy: Messages are serialized directly to socket buffers
- Async I/O: Non-blocking operations using Tokio
- Connection Pooling: Reuse connections for multiple requests
- Backpressure: Flow control via async/await
License
See workspace LICENSE file.