Get desktop application:
View/edit binary Protocol Buffers messages
Messages for authentication protocol between a sender and a receiver.
Used in:
Used in:
Used in:
The underlying connection is not TLS
Used in:
Used in:
source and destination ids identify the origin and destination of the message. They are used to route messages between endpoints that share a device-to-device channel. For messages between applications: - The sender application id is a unique identifier generated on behalf of the sender application. - The receiver id is always the the session id for the application. For messages to or from the sender or receiver platform, the special ids 'sender-0' and 'receiver-0' can be used. For messages intended for all endpoints using a given channel, the wildcard destination_id '*' can be used.
This is the core multiplexing key. All messages are sent on a namespace and endpoints sharing a channel listen on one or more namespaces. The namespace defines the protocol and semantics of the message.
Depending on payload_type, exactly one of the following optional fields will always be set.
--- Begin new 1.1 fields. Flag indicating whether there are more chunks to follow for this message. If the flag is false or is not present, then this is the last (or only) chunk of the message.
If this is a chunk of a larger message, and the remaining length of the message payload (the sum of the lengths of the payloads of the remaining chunks) is known, this field will indicate that length. For a given chunked message, this field should either be present in all of the chunks, or in none of them.
What type of data do we have in this message.
Used in:
Always pass a version of the protocol for future compatibility requirements.
Used in:
message chunking support (deprecated).
reworked message chunking.
binary payload over utf8.
Request fields
Response fields
Used in:
,Used in:
,