Client Protocols

Clients establish long-lived connections through Gateway TCP or WebSocket listeners. The WKProto baseline covers negotiation, send, receive acknowledgement and heartbeat. MQTT uses a separate MQTT 5 TCP entry while sharing IM users, channels and messages.

A protocol is not an HTTP API

TCP binary frames and WebSocket messages do not belong in OpenAPI. This section records wire and Gateway behavior without inventing HTTP paths.

Connection Lifecycle

CONNECT-first behavior, CONNACK, active sessions, idle close, and recovery.

Packet Types

FrameType values 0–12, directions, and current publication scope.

TCP Binary Protocol

Fixed header, Remaining Length, field order, and version boundaries.

Encryption & Security

X25519, AES-CBC, msg_key, and security limits.

EasySDK JSON-RPC

Core online path, four-client wire compatibility, and experimental boundaries.

MQTT (development preview)

MQTT 5 TCP, authentication, topics, persistent sessions, Wills and interop.

Current boundary

The public core contains CONNECT/CONNACK, SEND/SENDACK, RECV/RECVACK, PING/PONG, and outbound server stream.* EVENT.
WKProto DISCONNECT, SUB, and SUBACK are currently codec contracts, not published product Gateway entry points.
The server can deliver public streaming message events through EVENT. Arbitrary client EVENT ingress remains unsupported; ingress accepts only benchmark terminal-fence tooling requests.
WebSocket can carry WKProto bytes. The JSON-RPC bridge supports the pinned EasySDK core online path; the matrix marks every other method experimental or missing.

See Shared Dictionaries for numeric meanings and Authentication & Security for the production trust boundary.