NvSOMEIP#

Introduction#

Overview#

NvSOMEIP is a C++ shared library that implements the SOME/IP and SOME/IP-SD middleware protocol for NVIDIA DriveOS platforms. It enables applications running on the same ECU or across a vehicle network to discover each other’s services and exchange request/response messages and event notifications over UDP and TCP.

The library is designed for embedded automotive use on Linux and QNX, including QNX safety-certified builds.

Key Characteristics#

In-Process Stack#

Every application that links libnvsomeip.so embeds the complete SOME/IP stack, including Service Discovery. There is no separate routing-manager process to deploy or configure. Each application independently joins the Service Discovery multicast group and manages its own TCP/UDP endpoints.

Singleton API#

The entire library is accessed through a single object:

NvSomeIp::Infra& infra = NvSomeIp::Infra::GetInstance();

There is no factory or create_application() call, and there is no need to manage multiple runtime objects. One Infra instance exists per process.

Raw byte payloads#

Payloads are std::shared_ptr<std::vector<uint8_t>>. The library performs no serialization or deserialization. Your application is responsible for encoding and decoding the byte stream according to its own data contract.

SOME/IP headers are always transmitted in network (big-endian) byte order on the wire; this is handled internally.

Two-phase lifecycle#

An NvSOMEIP application has exactly two phases:

Configure: Obtain the Infra singleton, supply a configuration (SetConfig), declare which services to offer or request, subscribe to eventgroups, and register callback handlers.
Run: Call Start() to activate Service Discovery and begin processing. Construct and send messages; receive messages through the registered callbacks. Finish with Stop().

SetConfig() must be the first call after GetInstance(), and it may only be called once. There is no runtime reconfiguration.

See Writing a Service and Writing a Client for the detailed API call sequence, and see Scope and Limitations for current release limitations.

This chapter covers everything needed to compile, link, and run your first NvSOMEIP application.

Getting Started#

SDK Deliverables#

The Linux and QNX SDKs deliver:

In the paths below, replace <target_sdk> with the SDK directory installed under $NV_WORKSPACE for your target OS. The exact directory name depends on the release and installation.

In this section, <sample_dir> refers to $NV_WORKSPACE/<target_sdk>/samples/nvsomeip.

Artifact	Purpose
`libnvsomeip.so`	The SOME/IP stack shared library your application links against.
`libnvsocketwrapper.so`	Transport-layer shared library that provides the UDP/TCP socket, IPv4 multicast, and network-link monitoring primitives that `libnvsomeip.so` depends on. Linked transitively; applications do not call its APIs directly. See Transport Dependency for the integration contract that any conforming implementation must satisfy.
`nvsomeip_infra.h`	Primary API header for the `Infra` singleton and callback types.
`nvsomeip_message.h`	`Message` class for creating, populating, and reading SOME/IP messages.
`nvsomeip_types.h`	Configuration structs, enums (`ErrorCode`, `MessageType`, `TPType`), wildcard constants, and SOME/IP wire return codes.
`ConfigParserText` (`<sample_dir>/config_parser/`)	Optional utility parser composed of `config_parser_text.cpp` and the headers `config_parser.h` / `config_parser_text.h`. Compile `config_parser_text.cpp` into your application when using `.kv` configuration files.
Example code (`<sample_dir>`)	Reference client and service applications with matching configuration files.

Network Prerequisites#

NvSOMEIP uses IP multicast for Service Discovery and, optionally, for event delivery. Before running any NvSOMEIP application, the operating system must be configured to route multicast traffic to the correct network interface.

Linux:

sudo ip route add <multicast_addr>/4 dev <interface>

Public API Overview#

For complete method signatures, parameter descriptions, preconditions, and thread-safety annotations, refer to the “SOME/IP Interface” section of the SDK API Reference.

The public API is contained in three headers. This section provides a brief description of each.

`nvsomeip_types.h`: Types and Configuration#

This header defines every data type needed to configure the SOME/IP stack and interpret its results. It has no dependency on the other two headers.

Configuration structs populated by your application and passed to Infra::SetConfig():

NvSomeIpConfig: Top-level bundle containing network addresses, a list of service configurations, Service Discovery settings, and SOME/IP-TP settings.
ServiceConfig: One entry per service or client: service/instance IDs, ports, protocol preference, version, and nested lists of methods, events, and eventgroups.
MethodConfig: Method ID, transport protocol override, and TP flag.
EventConfig: Event ID, isField flag, transport protocol override, and TP flag.
EventgroupConfig: Eventgroup ID, multicast threshold, and the list of event IDs that belong to the group.
ServiceDiscoveryConfig: SD multicast address/port, subscribe retry parameters, and a vector of TimerConfig entries.
TimerConfig: SD timing parameters (initial delay, repetitions, cyclic offer interval, TTL, request/response delay).
TpConfig: SOME/IP-TP reassembly timeout, buffer size, and buffer count.

Enums:

ErrorCode: Return value of every Infra and Message method (E_SUCCESS, E_CFG_NOT_SET, E_ENDPOINT, etc.).
MessageType: REQUEST, REQUEST_NO_RETURN, NOTIFICATION, RESPONSE, ERROR.
TPType: E_UDP, E_TCP.

Constants:

Wildcard filters for handler registration: ALL_SERVICES, ALL_INSTANCES, ALL_METHODS, ALL_EVENTS (all 0xFFFF).
SOME/IP wire return codes: E_OK, E_NOT_OK, E_UNKNOWN_SERVICE, E_UNKNOWN_METHOD, etc.

`nvsomeip_message.h`: Message#

This header defines the Message class, which represents a single SOME/IP message (request, response, or event notification). It includes nvsomeip_types.h.

Message is an abstract base class. You never construct one directly; instead, use the three static factory methods:

Message::GetRequest(): creates a message for sending a REQUEST or REQUEST_NO_RETURN.
Message::GetResponse(request): creates a response message pre-filled with the addressing information from the original request.
Message::GetEvent(): creates a message for sending an event notification.

All factories return std::shared_ptr<Message>. The class is non-copyable and non-movable.

Once you have a message, use setters to fill in identifiers (SetServiceID, SetMethodID or SetEventID), the message type (SetMessageType), the return code (SetReturnCode, typically for responses), and the payload (SetPayload). Corresponding getters are available for reading received messages in callbacks.

Payloads are std::shared_ptr<std::vector<uint8_t>> containing raw bytes with no library-imposed serialization.

`nvsomeip_infra.h`: Infra#

This header defines the Infra singleton and the callback type aliases. It includes both of the other headers.

Infra is the primary interface to the library. Every operation, including configuration, service lifecycle, handler registration, message sending, and stack start/stop, goes through this single class.

Callback type aliases defined alongside Infra:

MsgHandlerType (void(std::shared_ptr<Message>)): Invoked when a method request/response or event notification is received.
ServiceAvlblHandlerType (void(uint16_t serviceID, uint16_t instanceID, bool isAvailable)): Invoked when a remote service is discovered or lost.
EventgroupHandlerType: (void(uint16_t serviceID, uint16_t instanceID, uint16_t eventgroupID, bool isSubscribed)): Invoked on the server side when a client subscribes or unsubscribes.

Callback Dispatch#

Register callback handlers during the configure phase, before calling Start(). Handler registration APIs support wildcard filters: ALL_SERVICES, ALL_INSTANCES, ALL_METHODS, and ALL_EVENTS. For example, registering with ALL_SERVICES lets one callback receive messages for any configured service that matches the remaining filters.

The message handler APIs are split by message role:

RegisterMethodHandler() is used by services to receive REQUEST and REQUEST_NO_RETURN messages, and by clients to receive RESPONSE and ERROR messages.
RegisterEventHandler() is used by clients to receive NOTIFICATION messages from subscribed eventgroups.
RegisterServiceAvlblHandler() is used by clients to learn when a remote service becomes available or unavailable.
RegisterEventgroupHandler() is used by services to learn when clients subscribe or unsubscribe to eventgroups.

Callbacks are invoked by NvSOMEIP internal processing threads. Keep callback work short and non-blocking: copy the message data you need, signal your application thread, and return. Avoid long sleeps, blocking I/O, or calling APIs that wait for shutdown from inside a callback.

The API Reference Guide documents each Infra method in detail, including preconditions (e.g., which methods must be called before Start()) and thread-safety properties.

Usage#

NvSOMEIP requires an NvSomeIpConfig struct to be passed to Infra::SetConfig() before Start() is called. You can build this struct in code or parse it from a supplied .kv file using ConfigParserText. The SDK examples use .kv files; see Configuration for the full reference.

Building and Linking#

Your source files need a single include:

#include "nvsomeip_infra.h"

This transitively pulls in nvsomeip_message.h and nvsomeip_types.h, so all public types, enums, and the Message class are available.

Add the NvSOMEIP header directory to your compiler’s include path:

-I$NV_WORKSPACE/<target_sdk>/include

Link Flags#

Platform	Link Libraries
Linux	`-lnvsomeip -lnvsocketwrapper -lpthread`
QNX	`-lnvsomeip -lnvsocketwrapper`

Both platforms require libnvsomeip.so and libnvsocketwrapper.so to be on the library search path at link time and in LD_LIBRARY_PATH (or the equivalent) at run time.

Writing a Service#

A service (server) offers methods that clients can call and publishes event notifications to subscribed clients. The API call sequence has two phases.

Configure Phase#

Obtain the singleton: Infra::GetInstance().
Supply configuration: build or parse an NvSomeIpConfig and call SetConfig(). This must be the first call and can only be done once.
Offer the service: OfferService(serviceID, instanceID). This declares intent; actual SD Offer messages are sent after Start().
Register a method handler: RegisterMethodHandler(callback, ...). The callback receives both REQUEST and REQUEST_NO_RETURN messages; inspect GetMessageType() to distinguish them.
Register an eventgroup handler (optional but typical): RegisterEventgroupHandler(callback, ...). The callback fires when clients subscribe or unsubscribe, so you know when to start or stop publishing events.

Run Phase#

Start the stack: Start(). Returns immediately; Service Discovery begins in the background.

Handle requests: when a REQUEST arrives in your method handler, build a response and send it:

auto response = NvSomeIp::Message::GetResponse(request);
response->SetMessageType(NvSomeIp::MessageType::RESPONSE);
response->SetReturnCode(NvSomeIp::E_OK);
response->SetPayload(payload);
infra.Send(response);

For REQUEST_NO_RETURN messages, no response is expected.

Publish events: when your eventgroup handler reports isSubscribed == true, construct and send notifications:

auto event = NvSomeIp::Message::GetEvent();
event->SetServiceID(serviceID, instanceID);
event->SetEventID(eventID);
event->SetMessageType(NvSomeIp::MessageType::NOTIFICATION);
event->SetPayload(payload);
infra.Send(event);

Stop publishing when the handler reports isSubscribed == false.

Shut down: call Stop(). If the application will continue running after stopping SOME/IP, call StopOfferService(serviceID, instanceID) before Stop() to gracefully withdraw the service.

For a complete working example, see $NV_WORKSPACE/<target_sdk>/samples/nvsomeip/service/service.cpp and its companion configuration file $NV_WORKSPACE/<target_sdk>/samples/nvsomeip/service/service-nvsomeip_cfg-data.kv.

Writing a Client#

A client discovers a remote service, sends requests, and receives responses and event notifications.

Configure Phase#

Obtain the singleton: Infra::GetInstance().
Supply configuration: SetConfig() with an NvSomeIpConfig where the service entry has isService = false.
Request the service: RequestService(serviceID, instanceID). This triggers SD Find messages after Start().
Subscribe to eventgroups (if events are needed): SubscribeEventgroup(serviceID, instanceID, eventgroupID). SD Subscribe messages are sent once an Offer is received.
Register handlers:
- RegisterServiceAvlblHandler(callback, ...): Notified when the remote service is discovered or lost.
- RegisterMethodHandler(callback, ...): Receives RESPONSE and ERROR messages.
- RegisterEventHandler(callback, ...): Receives NOTIFICATION messages from subscribed eventgroups.

Run Phase#

Start the stack: Start().
Wait for availability: your ServiceAvlblHandler fires with isAvailable == true when the service is found. Only send requests after this point.

Send requests:

auto msg = NvSomeIp::Message::GetRequest();
msg->SetServiceID(serviceID, instanceID);
msg->SetMethodID(methodID);
msg->SetMessageType(NvSomeIp::MessageType::REQUEST);
msg->SetPayload(payload);
infra.Send(msg);

Handle E_ENDPOINT: Send() may return ErrorCode::E_ENDPOINT if the transport connection is not yet established. Retry after a short delay:
```
NvSomeIp::ErrorCode err = infra.Send(msg);
if (err == NvSomeIp::ErrorCode::E_ENDPOINT)
{
    std::this_thread::sleep_for(std::chrono::milliseconds(1));
    err = infra.Send(msg);
}
```
Production code should use a bounded retry policy or wait for service availability before sending.
Receive responses and events: these arrive in the registered RegisterMethodHandler and RegisterEventHandler callbacks respectively.
Shut down: call Stop(). If the application will continue
running after stopping SOME/IP, call StopSubscribeEventgroup(...), then StopRequestService(...) before Stop() to gracefully release subscriptions and service requests.

For a complete working example, see $NV_WORKSPACE/<target_sdk>/samples/nvsomeip/client/client.cpp and its companion configuration file $NV_WORKSPACE/<target_sdk>/samples/nvsomeip/client/client-nvsomeip_cfg-data.kv.

Running the Example Client and Service#

The SDK ships a matching pair of example applications under $NV_WORKSPACE/<target_sdk>/samples/nvsomeip/.

Sample Files#

SDK Path	Description
`samples/nvsomeip/service/service.cpp`	Example service application source.
`samples/nvsomeip/service/service-nvsomeip_cfg-data.kv`	KV configuration for the service.
`samples/nvsomeip/service/service-nvsomeip_cfg-data.cue`	CUE source for the service configuration.
`samples/nvsomeip/client/client.cpp`	Example client application source.
`samples/nvsomeip/client/client-nvsomeip_cfg-data.kv`	KV configuration for the client.
`samples/nvsomeip/client/client-nvsomeip_cfg-data.cue`	CUE source for the client configuration.

All paths are relative to $NV_WORKSPACE/<target_sdk>/.

Build#

From the SDK sample directory, using the provided Makefiles:

cd $NV_WORKSPACE/<target_sdk>/samples/nvsomeip/service && make
cd $NV_WORKSPACE/<target_sdk>/samples/nvsomeip/client  && make

Each produces an executable (nvsomeip_service and nvsomeip_client) alongside the matching .kv configuration file.

Before launching the samples, read the sample READMEs for platform-specific setup commands such as Linux multicast routes and QNX loopback alias configuration:

$NV_WORKSPACE/<target_sdk>/samples/nvsomeip/service/README
$NV_WORKSPACE/<target_sdk>/samples/nvsomeip/client/README

Launch#

Start the service first, then the client. Both take a .kv configuration file as the first argument and an optional local IP address override as the second:

# Terminal 1
./nvsomeip_service service-nvsomeip_cfg-data.kv [self_ip]

# Terminal 2
./nvsomeip_client client-nvsomeip_cfg-data.kv [self_ip]

The self_ip argument, when provided, overrides networkIPAddr from the configuration file before Infra::SetConfig() is called.

Both applications must agree on the Service Discovery multicast address and port. The shipped .kv files are pre-configured to work together.

What to Expect#

The service starts, offers its service, and waits for clients.
The client discovers the service via SD, sends requests (over UDP, TCP, and UDP with SOME/IP-TP), and subscribes to eventgroups.
The service responds to requests and publishes periodic events to subscribed eventgroups.
The client logs received responses and events, then exits when all expected outcomes are observed. The service runs until Ctrl+C.

Configuration#

NvSOMEIP requires an NvSomeIpConfig struct to be passed to Infra::SetConfig() before Start() is called. You can populate this struct programmatically or parse it from a key-value (.kv) text file using the supplied ConfigParserText utility.

Key-Value Configuration Files#

A .kv file is a plain-text file where each line is a key=value pair. Hierarchical keys use dot notation, and array elements use a zero-based index:

# Comment lines start with #
section.subsection.key=value
array.0.key=value

The parser ignores blank lines and lines beginning with #.

The SDK ships matching .kv files alongside the example applications in $NV_WORKSPACE/<target_sdk>/samples/nvsomeip/.

File Structure#

The tables below list the most commonly used keys.

Global and Network#

Key	Description
`client_id`	Unique numeric ID for this application instance.
`network.IP Address`	Local IP address of the SOME/IP interface.
`network.multicast_ip`	Multicast IP used for event delivery (optional).

Service / Client Entries#

A server application uses the services section; a client application uses the clients section. Both accept the same keys. Indexing starts at 0.

Key (`services.<i>.` or `clients.<i>.`)	Description
`.service_id`	SOME/IP service identifier.
`.instance_id`	Instance identifier.
`.udp_port` / `.tcp_port`	Transport ports.
`.multicast_port`	Multicast port for event delivery (server-side; used with eventgroups whose `multicast_threshold` is non-zero).
`.preferred_protocol`	Default transport: `udp` or `tcp`.
`.major_version` / `.minor_version`	SOME/IP interface version.
`.methods.<j>.method_id`	Method identifier within the service.
`.events.<j>.event_id`	Event identifier within the service.
`.eventgroups.<j>.eventgroup_id`	Eventgroup identifier; lists its member events.
`.timer_config_index`	Index into `service_discovery.timer_configs` for per-service SD timing (optional; defaults to 0).

Methods, events, and eventgroups support additional optional keys such as preferred_protocol, tp_enabled, is_field, and multicast_threshold.

Service Discovery#

Key	Description
`service_discovery.multicast_ip`	SD multicast group address.
`service_discovery.multicast_port`	SD multicast port.
`service_discovery.subscribe_retry_delay_ms`	Delay between subscribe retry attempts (client-side, optional).
`service_discovery.subscribe_retry_max`	Maximum subscribe retry attempts (client-side, optional).

Timer Configs#

The service_discovery.timer_configs array holds one or more SD timer profiles. Each service or client can reference a profile by index via timer_config_index (defaults to 0).

Key (`service_discovery.timer_configs.<i>.`)	Description
`.initial_delay_min_ms`	Minimum random delay before the first SD message.
`.initial_delay_max_ms`	Maximum random delay before the first SD message.
`.repetitions_base_delay_ms`	Base delay between SD repetition-phase messages.
`.repetitions_max`	Number of SD messages in the repetition phase.
`.ttl_seconds`	Time-to-live advertised in SD entries.
`.cyclic_offer_delay_ms`	Interval between cyclic Offer messages.
`.request_response_delay_min_ms`	Minimum response delay to multicast entries (optional).
`.request_response_delay_max_ms`	Maximum response delay to multicast entries (optional).

SOME/IP-TP (Optional)#

Key	Description
`tp_config.reassembly_timeout_ms`	SOME/IP-TP reassembly timeout.
`tp_config.reassembly_buffer_size_bytes`	Maximum bytes per reassembled message (0 = 4 MiB default).
`tp_config.reassembly_buffer_count`	Maximum concurrent reassembly buffers (0 = 32-stream default).

For the exhaustive list of keys, required/optional status, and value constraints, refer to the CUE schema at $NV_WORKSPACE/<target_sdk>/filesystem/contents/config/nvsomeip/nvsomeip_cfg-defs.cue. The shipped example .kv files demonstrate all sections in practice.

Loading a KV File#

Use ConfigParserText to parse a .kv file into an NvSomeIpConfig:

#include "config_parser_text.h"

NvSomeIp::ConfigParserText parser;
NvSomeIp::NvSomeIpConfig config;
NvSomeIp::ErrorCode err = parser.ParseFile("my-config.kv", config);

NvSomeIp::Infra& infra = NvSomeIp::Infra::GetInstance();
infra.SetConfig(config);

config_parser_text.cpp must be compiled and linked into your application. See the SDK example Makefiles for the required include and source paths.

CUE Schema Validation#

The SDK provides a CUE schema that defines the structure and constraints of a valid NvSOMEIP configuration. Using CUE lets you validate configuration at authoring time, before the application runs.

Use the CUE binary supplied with the DRIVE OS SDK. The exact versioned path under $NV_WORKSPACE/drive-foundation/tools/pct/cue/ may change between releases, so either add the shipped cue binary to PATH or invoke the versioned binary from that directory.

The workflow is:

Write a CUE data file that imports the schema and defines your configuration. See the example at $NV_WORKSPACE/<target_sdk>/samples/nvsomeip/service/service-nvsomeip_cfg-data.cue.

Validate the data file against the schema:

cue vet nvsomeip_cfg-defs.cue my-config-data.cue

Export to JSON, then convert to KV format for use at runtime:

cue eval nvsomeip_cfg-defs.cue my-config-data.cue -o my-config.json
python3 $NV_WORKSPACE/<target_sdk>/samples/mcc_daemon/json_to_keyvalue.py my-config.json my-config.kv

The schema file is located at $NV_WORKSPACE/<target_sdk>/filesystem/contents/config/nvsomeip/nvsomeip_cfg-defs.cue. The JSON-to-KV conversion script is at $NV_WORKSPACE/<target_sdk>/samples/mcc_daemon/json_to_keyvalue.py.

Programmatic Configuration#

Instead of using a .kv file, you can build an NvSomeIpConfig struct entirely in code. Populate the nested structs (ServiceConfig, MethodConfig, EventConfig, EventgroupConfig, ServiceDiscoveryConfig, TpConfig) and pass the top-level struct to Infra::SetConfig().

The struct fields mirror the .kv keys described above. Refer to the nvsomeip_types.h header and the Public API Overview section for the complete list of fields and their defaults.

Transport Dependency#

NvSOMEIP delegates all UDP/TCP socket I/O, IPv4 multicast group membership, and network-link state monitoring to libnvsocketwrapper.so. Applications link this library transitively; see Building and Linking below. They never call its APIs directly.

This section documents the contract NvSOMEIP relies on when an integrator ports the stack to a new platform or supplies an alternative implementation of libnvsocketwrapper.so.

Public Headers#

The library exposes its surface through four public headers under $NV_WORKSPACE/<target_sdk>/samples/NvSocketWrapper/include/. All types live in the NvSocketWrapper namespace.

Header	Contents
`nvsocketwrapper_types.h`	`ErrorCode` and `TPType` enums
`nvsocketwrapper_message.h`	Abstract `Message` class. Carries a payload (`std::shared_ptr<std::vector<uint8_t>>`), local and remote IPv4 address/port pairs, and a size. Instances are produced by the static factories `Message::GetInstance()` and `Message::GetInstance(uint32_t size)`.
`nvsocketwrapper_endpoint.h`	Abstract `Endpoint` class providing send/receive, server/client init and teardown, callback registration via `SetCallback(MsgResponderType)`, and connection management. Instances are produced by `Endpoint::GetInstance(TPType)`, which returns a UDP or TCP endpoint.
`nvsocketwrapper_link_monitor.h`	Abstract `LinkMonitor` class for observing the local interface’s link state. Instances are produced by `LinkMonitor::GetInstance(localIpAddr, pollIntervalMs, LinkUpCallback, LinkDownCallback)`.
`nvsocketwrapper_defines.h`	`maxMsgSize` constant (default 4096) used to size receive buffers when no explicit size is configured.

NvSOMEIP Expectations for `libnvsocketwrapper.so`#

ABI Surface#

A conforming implementation must export the three static factory symbols that NvSOMEIP calls into:

NvSocketWrapper::Endpoint::GetInstance(TPType)
NvSocketWrapper::Message::GetInstance() and NvSocketWrapper::Message::GetInstance(uint32_t)
NvSocketWrapper::LinkMonitor::GetInstance(...)

Each factory returns a std::shared_ptr to a concrete subclass of the public abstract class. Every virtual method declared in the public headers must be implemented; NvSOMEIP invokes the full surface on the returned objects.

Transport Semantics#

IPv4 only. NvSOMEIP does not require, and does not exercise, IPv6 support.
UDP endpoints must support unicast send/receive and IPv4 multicast group membership.
TCP endpoints must support both server mode (InitServer + AcceptConnection, accepting multiple concurrent client connections) and client mode (InitClient + ConnectToServer).
SendMsg must return E_SUCCESS on success and E_ENDPOINT when the underlying socket is not yet connected or has been torn down. NvSOMEIP propagates E_ENDPOINT to applications as NvSomeIp::ErrorCode::E_ENDPOINT so they can retry; see the E_ENDPOINT handling in Writing a Client.
RecvMsg must use ErrorCode to distinguish between transient and terminal conditions:
- E_TIMEOUT: no message within timeoutMs; NvSOMEIP simply loops.
- E_RUNNING: benign “in progress / no message yet”; NvSOMEIP ignores it and does not consume the buffer.
- E_SHUTDOWN / E_SERVER_TEARDOWN / E_ENDPOINT: terminal; NvSOMEIP closes the receive loop and recycles the endpoint.

Threading and Callbacks#

Endpoint::SetCallback registers a MsgResponderType (std::function<void(std::shared_ptr<Message>, ErrorCode)>) that the implementation invokes from its internal I/O threads whenever a message is received or a terminal error is raised on the endpoint.
LinkMonitor callbacks (LinkUpCallback / LinkDownCallback) are invoked from the monitor’s polling thread. Each link-state transition must fire the appropriate callback exactly once; spurious or duplicate edges break NvSOMEIP’s link-state handling.
LinkMonitor::Start() and Stop() are not required to be thread-safe with respect to each other; NvSOMEIP serializes them.
Objects captured by the registered callbacks must remain valid until Stop() returns or the LinkMonitor is destroyed, as documented in nvsocketwrapper_link_monitor.h.

Buffer Sizing#

Endpoint::SetMaxMsgSize must take effect before the next RecvMsg and determines the receive buffer the endpoint allocates. When NvSOMEIP does not call SetMaxMsgSize, the implementation must default to NvSocketWrapper::maxMsgSize from nvsocketwrapper_defines.h.
Message::GetInstance(uint32_t size) must produce a message whose payload buffer can hold at least size bytes. NvSOMEIP uses this factory when reassembling TCP framing and SOME/IP-TP messages above the default maxMsgSize.

Lifetime and Ownership#

All Endpoint, Message, and LinkMonitor instances are owned by NvSOMEIP through std::shared_ptr.
Message payloads are std::shared_ptr<std::vector<uint8_t>>; ownership transfers with the pointer. The implementation must not retain raw pointers or references into the payload vector beyond the lifetime of the enclosing Message.

Scope and Limitations#

The following limitations apply to the current release:

No centralized routing: every application has its own router. Multicast messages for other applications sharing the same SD group are received and silently discarded.
An application cannot be both a client and a server for the same service ID and instance ID. Separate processes are required if you need both roles.
No IPv6 support: the library supports IPv4 networking only.
No built-in SOME/IP communication policy enforcement: the library does not implement PRS_SOMEIP_00946 or PRS_SOMEIP_00947. Servers do not enforce built-in policies to reject unauthorized client method calls or eventgroup subscriptions, and clients do not enforce built-in policies to deny communication with unauthorized servers. Applications must implement any required authorization policy above NvSOMEIP or secure the transport at the network layer.
No E2E protection: the library does not implement AUTOSAR E2E protection profiles. Applications that require E2E protection must add it above NvSOMEIP.
No TCP magic cookie support: the library does not support SOME/IP TCP magic cookies.
Application-defined event publishing: the library tracks subscriptions and sends event messages requested by the application, but it does not define when or how often events are published. Applications must decide their own event sending strategy.
No payload serialization: the library treats payloads as raw byte buffers. Applications must handle SOME/IP 5.1.3 serialization of data structures (DS) for outgoing payloads and SOME/IP 5.1.4 deserialization of DS for received payloads according to their own data contract.

NvSOMEIP#

Introduction#

Overview#

Key Characteristics#

In-Process Stack#

Singleton API#

Raw byte payloads#

Two-phase lifecycle#

Getting Started#

SDK Deliverables#

Network Prerequisites#

Public API Overview#

nvsomeip_types.h: Types and Configuration#

nvsomeip_message.h: Message#

nvsomeip_infra.h: Infra#

Callback Dispatch#

Usage#

Building and Linking#

Link Flags#

Writing a Service#

Configure Phase#

Run Phase#

Writing a Client#

Configure Phase#

Run Phase#

Running the Example Client and Service#

Sample Files#

Build#

Launch#

What to Expect#

Configuration#

Key-Value Configuration Files#

File Structure#

Global and Network#

Service / Client Entries#

Service Discovery#

Timer Configs#

SOME/IP-TP (Optional)#

Loading a KV File#

CUE Schema Validation#

Programmatic Configuration#

Transport Dependency#

Public Headers#

NvSOMEIP Expectations for libnvsocketwrapper.so#

ABI Surface#

Transport Semantics#

Threading and Callbacks#

Buffer Sizing#

Lifetime and Ownership#

Scope and Limitations#

`nvsomeip_types.h`: Types and Configuration#

`nvsomeip_message.h`: Message#

`nvsomeip_infra.h`: Infra#

NvSOMEIP Expectations for `libnvsocketwrapper.so`#