ObjectDeliverer Data Formats and Production

This page explains send/receive data formats, TLS/mTLS configuration, platform-specific notes, and what to check when something goes wrong.

Data formats and serialization

When you start communication without a DeliveryBox, data is sent and received as byte arrays (TArray<uint8>). With a DeliveryBox, data is automatically converted to the chosen format on every send and receive.

The two formats of ObjectDeliveryBoxUsingJson

The JSON serialization format is switched with EODJsonSerializeType.

NoWriteType (default with Create Object Delivery Box Using Json) — the format without the class name.

{
  "Prop": 1
}

WriteType (Create Dynamic Object Delivery Box Using Json) — the format that includes the class name.

{
  "Type": "SampleClassName",
  "Body": {
    "Prop": 1
  }
}

With NoWriteType, one DeliveryBox handles a single class. With WriteType, the class name is stored in the JSON, so a single DeliveryBox can send and receive multiple classes, and objects held as properties of a base class type do not lose their type information. In exchange, the data size grows by the class name.

Create Custom Object Delivery Box Using Json mixes the formats per class. See the FAQ: using ObjectDeliveryBoxUsingJson for details.

TLS and mTLS

TCP/IP with TLS (v1.9.0 and later) encrypts the communication and provides certificate-based authentication. The plugin bundles the libraries required for TLS; no extra setup is needed.

Specifying the minimum version

Minimum Protocol sets the minimum TLS version (specifying TLS 1.2 allows 1.2 and above). TLS 1.1 and TLS 1.0 are deprecated values. Use the default TLS 1.2 in most projects.

Client-side certificate verification

Use the With nodes on the return value of Create Protocol Tcp Ip Client Tls to configure verification. Typical combinations:

The FAQ: TLS options by use case lists recommended combinations.

mTLS (mutual authentication)

On the server, setting With Client Auth Mode to Required makes client certificates mandatory (Optional verifies a certificate when presented, None does not request one). Verification uses the CA bundle specified with With Client Ca Bundle. On the client, specify the certificate and key with With Client Certificate.

See also the FAQ: difference between TLS and mTLS.

Checking why a connection failed

When a TLS connection fails, the client’s Get Last Tls Error returns the reason as a string. It covers handshake failures (such as a chain signed by a distrusted CA), certificate or CA configuration failures, and connections dropping right after the handshake. The value is cleared once a connection is established.

Specifying Peer Verification Disabled skips server certificate verification entirely. The communication is still encrypted, but impersonation can no longer be detected, so avoid this option in normal use (FAQ: is disabling peer verification safe?).

For failures caused by a mismatch between the hostname or IP address and the certificate, see the FAQ: TLS fails when hostname or IP does not match.

Creating certificates

Manual certificate creation with OpenSSL commands is described in the FAQ: creating TLS certificates with OpenSSL, and self-signed configuration in the FAQ: TLS with self-signed certificates.

From C++, UObjectDelivererCertificateGenerator can generate self-signed and CA certificates for development and testing (not exposed to Blueprint).

A sample TLS server that communicates with the ObjectDeliverer TLS client is published on GitHub at AyumaxSoft/TLSServerSample.

Certificate trust policy (v1.9.1 and later)

Starting with v1.9.1, a built-in distrusted-CA list is always applied during TLS certificate verification.

• Certificate chains issued by the eight eMudhra intermediate CAs whose private keys were compromised in October 2026, and by their three signing roots, are rejected — even if your OS or engine trust store still trusts them.
• The policy is enforced on both sides of the connection: client-side server-certificate verification and server-side client-certificate verification (mTLS).
• If the certificate chain cannot be inspected at all, the connection is rejected (fail-closed).
• The reason of a connection failure can be checked with the client’s Get Last Tls Error (readable from Blueprint).
• To block additional certificate authorities for your own incident response, use the C++ API (FObjectDelivererTlsTrustPolicy). Additional entries are process-wide only.
• When Peer Verification Disabled is specified, certificate verification itself is skipped, so this list does not apply either (not recommended).

Buffer sizes

Each protocol accepts With Receive Buffer Size and With Send Buffer Size to configure the buffer sizes. The default is 1 MB. Adjust them when you send or receive large amounts of data at once.

Platform notes

The iOS wss notes are based on the plugin’s verification record (Docs/iOS_WebSocket_wss_CA_Bundle_Notes.md in the ObjectDelivererV2 repository).

Troubleshooting

To narrow down the cause, you can also collect internal plugin logs with Logging in the Blueprint API.

Security checklist

Before using communication in a public or production environment, confirm the following.

• Use TLS (or wss) when the communication path must be encrypted
• You are not specifying Peer Verification Disabled
• The minimum TLS version is set to TLS 1.2 or higher
• You are not shipping a development or test self-signed certificate as the production server certificate
• Certificate and private key files are not included in screenshots, logs, or your repository
• Port numbers and shared memory names do not collide with unrelated processes