Transport Requirements¶
This section defines requirements for the transport layer implementation in OpenSOMEIP, including UDP and TCP transports.
Overview¶
The transport layer provides:
UDP transport with multicast support
TCP transport with connection management
Abstract transport interface for extensibility
Requirements¶
UDP Transport¶
The implementation shall provide UDP transport that supports binding to local address and port, sending messages to unicast destinations, and receiving messages from any source. Rationale: UDP unicast is the foundation for SOME/IP point-to-point communication. Code Location: |
The implementation shall support sending to multicast destinations and multicast group join/leave for receiving multicast traffic. Rationale: Multicast is required for Service Discovery and eventgroup subscriptions. Code Location: |
The implementation shall provide non-blocking I/O with configurable timeouts and thread-safe operation for concurrent send/receive. Rationale: Non-blocking I/O and thread safety enable integration with event loops and multi-threaded applications. Code Location: |
TCP Transport¶
The implementation shall provide a TCP transport ( Rationale: Client and server modes cover both initiator and responder roles in TCP communication. Code Location: |
The implementation shall provide message framing over TCP streams, connection state management, automatic reconnection (configurable), and thread-safe operation. Rationale: TCP streams require framing to delimit messages; state management enables robust reconnection. Code Location: |
Connection Management¶
The TCP transport shall track connection state (disconnected, connecting, connected) and notify listeners of connection state changes. Rationale: State tracking and notifications enable applications to react to connection lifecycle events. Code Location: |
The TCP transport shall support graceful connection shutdown, handle connection errors and timeouts, and support multiple simultaneous connections (server mode). Rationale: Graceful shutdown and error handling ensure clean resource release and predictable behavior on failures. Code Location: |
Error Recovery¶
The transport layer shall retry send operations on transient errors (e.g., EAGAIN, EWOULDBLOCK) according to configurable retry policy. Rationale: Transient errors are common in non-blocking I/O and often resolve on retry. Code Location: |
The transport layer shall close and reopen sockets when persistent errors occur (e.g., connection reset, broken pipe). Rationale: Persistent errors indicate the socket is unusable; reopening restores communication. Code Location: |
The transport layer shall log errors with sufficient detail for diagnosis (errno, endpoint, operation context). Rationale: Detailed error logs enable rapid troubleshooting in production environments. Code Location: |
The transport layer shall return appropriate error codes to callers and support configurable retry policies (count, delay). Rationale: Error codes allow application-layer handling; configurable retry adapts to different deployment requirements. Code Location: |
Transport Interface¶
The implementation shall provide an abstract transport interface
(
Rationale: Abstract interface enables transport-agnostic application code and testing. Code Location: |
Endpoint Configuration¶
The implementation shall provide endpoint configuration:
Rationale: Proper endpoint handling is fundamental to network communication. Code Location: |
Transport Protocol Binding¶
The software shall support transporting more than one SOME/IP message in a single transport layer PDU (nPDU feature). For cyclic senders, nPDU shall be supported without explicit configuration. Rationale: nPDU reduces per-message overhead for high-frequency communication. Code Location: |
The software shall support UDP unicast and multicast transmission. Multicast eventgroups shall use unicast for initial field events. Clients shall support receiving via unicast and/or multicast. Rationale: Multicast reduces bandwidth for events delivered to many subscribers. Code Location: |
The software shall support dynamic switching of eventgroups between unicast and multicast based on the Multicast-Threshold configuration. Rationale: Dynamic switching optimizes bandwidth based on actual subscriber count. Code Location: |
The software shall support internal de/multiplexing of SOME/IP messages independent of the number of controllers, cores, and IP addresses. Rationale: Internal multiplexing decouples service routing from physical network topology. Code Location: |
The software shall read port numbers from configuration files. Port 30490 shall only be used for SOME/IP-SD, not application communication. Rationale: Configuration-driven ports ensure deterministic network resource allocation. Code Location: |
The software shall use IETF/IANA ephemeral port range (49152-65535) for dynamic ports. Rationale: Ephemeral port range compliance avoids conflicts with well-known services. Code Location: |
TCP Connection Management¶
The software shall open TCP connections from the client side when the first method call or notification subscription is needed. The client is responsible for re-establishing failed connections. Rationale: Client-initiated connections simplify server-side connection management. Code Location: |
The software shall use a single TCP connection for all methods, events, and notifications of a service instance. TCP connections shall be shared across services to minimize connection count. Rationale: Connection sharing minimizes TCP connection overhead and OS resource usage. Code Location: |
TCP connections shall be closed by the client when no longer required or when all services are unavailable. The server shall not close connections preemptively. Rationale: Client-controlled closure prevents servers from disrupting active communication. Code Location: |
The software shall treat outstanding requests as timeouts when the TCP connection is lost. Rationale: Timeout handling prevents clients from waiting indefinitely for responses on broken connections. Code Location: |
Service Instance Binding¶
The software shall support multiple service instances on different ECUs and on the same ECU. Multiple instances of the same service on one ECU shall listen on different ports. Rationale: Multi-port binding enables horizontal scaling of service instances. Code Location: |
The client shall use the IP address and port number announced by the server via SOME/IP-SD for communication. Rationale: SD-announced address resolution ensures clients connect to the correct server endpoint. Code Location: |
The software shall be capable of receiving unaligned SOME/IP messages when multiple messages are transported in a single UDP or TCP PDU. Rationale: Unaligned message handling supports nPDU and multi-message PDUs. Code Location: |
Traceability¶
Implementation Files¶
include/transport/transport.h- Transport interfaceinclude/transport/udp_transport.h- UDP transport interfaceinclude/transport/tcp_transport.h- TCP transport interfaceinclude/transport/endpoint.h- Endpoint structuresrc/transport/udp_transport.cpp- UDP implementationsrc/transport/tcp_transport.cpp- TCP implementation
Test Files¶
tests/test_udp_transport.cpp- UDP transport teststests/test_tcp_transport.cpp- TCP transport tests
Examples¶
examples/basic/hello_world_client.cpp- Basic UDP clientexamples/basic/hello_world_server.cpp- Basic UDP serverexamples/advanced/tcp_client.cpp- TCP client exampleexamples/advanced/tcp_server.cpp- TCP server example