Principle:CARLA simulator Carla Client Server Connection
| Knowledge Sources | |
|---|---|
| Domains | Autonomous Driving Simulation, Distributed Systems |
| Last Updated | 2026-02-15 00:00 GMT |
Overview
A client-server connection establishes a communication channel between a controlling application and a simulation engine over a network transport, enabling remote command execution and data retrieval.
Description
The client-server architecture pattern separates the simulation runtime (server) from the control logic (client) into distinct processes that communicate over TCP. In the context of autonomous driving simulation, the server is responsible for rendering the 3D world, executing physics, and managing all simulation state, while the client sends commands (spawn actors, apply controls, query state) and receives responses.
CARLA implements this pattern using msgpack-rpc, a lightweight remote procedure call protocol built on top of MessagePack serialization. The server listens on a configurable TCP port (default 2000), and clients connect by specifying the host address and port number. This decoupling allows multiple clients to connect to the same simulation, clients to be written in different languages (Python, C++), and the simulation to run on a different machine from the controlling code.
The connection model follows a synchronous RPC pattern where each client call blocks until the server responds, though the underlying transport uses worker threads to handle concurrent operations. An optional worker thread pool on the client side enables non-blocking patterns for advanced use cases.
Usage
Use a client-server connection whenever you need to:
- Initialize a simulation session -- Every CARLA workflow begins by establishing a client connection to the running server process.
- Remote control -- Run simulation on a powerful GPU machine while controlling it from a lightweight laptop or CI pipeline.
- Multi-client scenarios -- Connect multiple clients for cooperative testing, where one client controls the ego vehicle and another manages traffic.
- Language interoperability -- Connect from Python scripts, C++ applications, or ROS nodes to the same simulation instance.
Theoretical Basis
The client-server model follows the standard RPC communication pattern:
Connection Establishment:
1. Server binds to (host, port) and listens for incoming TCP connections
2. Client initiates TCP handshake to (host, port)
3. TCP connection is established (3-way handshake)
4. RPC channel is ready for request-response cycles
Request-Response Cycle:
Client Server
| |
|--- serialize(command) ------->|
| |--- execute(command)
| |--- serialize(result)
|<------ serialize(result) -----|
|--- deserialize(result) |
Connection Parameters:
| Parameter | Purpose | Typical Value |
|---|---|---|
| host | Network address of the server | "localhost" or "127.0.0.1" |
| port | TCP port the server listens on | 2000 |
| worker_threads | Client-side thread pool size for async operations | 0 (auto) |
| timeout | Maximum wait time for server response | 10 seconds |
Timeout semantics: If a client call does not receive a response within the configured timeout, the call raises an exception. This prevents indefinite blocking when the server is unresponsive or overloaded. The timeout should be set based on the expected latency of the most expensive operation (e.g., loading a new map can take tens of seconds).
Thread safety: The client object is designed to be used from a single thread. The worker_threads parameter controls internal I/O concurrency, not multi-threaded client access. If multiple threads need to issue commands, each should maintain its own client instance or use external synchronization.