2021-10-30 02:06:06 +08:00
= RabbitMQ Streams Protocol Reference
2020-05-25 21:55:51 +08:00
2023-03-21 18:58:50 +08:00
This is the reference of the RabbitMQ Streams protocol.
2020-06-09 19:53:49 +08:00
2021-01-18 21:25:24 +08:00
The https://github.com/rabbitmq/rabbitmq-stream-java-client[RabbitMQ Stream Java client]
2020-06-09 19:53:49 +08:00
is currently the reference implementation.
2020-05-25 21:55:51 +08:00
== Types
int8, int16, int32, int64 - Signed integers (big endian order)
2020-09-29 17:29:56 +08:00
uint8, uint16, uint32, uint64 - Unsigned integers (big endian order)
2020-05-25 21:55:51 +08:00
bytes - int32 for the length followed by the bytes of content, length of -1 indicates null.
2022-02-17 23:13:40 +08:00
string - int16 for the length followed by the bytes of UTF8-encoded content, length of -1 indicates null.
2020-05-25 21:55:51 +08:00
arrays - int32 for the length followed by the repetition of the structure, notation uses [], e.g.
[int32] for an array of int32.
== Frame Structure
```
Frame => Size (Request | Response | Command)
2021-02-26 18:59:16 +08:00
Size => uint32 (size without the 4 bytes of the size element)
2020-05-25 21:55:51 +08:00
Request => Key Version (CorrelationId) Content
2021-02-26 18:59:16 +08:00
Key => uint16
Version => uint16
CorrelationId => uint32
2020-05-25 21:55:51 +08:00
Command => bytes // see command details below
Response => Key Version CorrelationId ResponseCode
2021-02-26 18:59:16 +08:00
Key => uint16
Version => uint16
CorrelationId => uint32
ResponseCode => uint16
2020-05-25 21:55:51 +08:00
Command => Key Version Content
2021-02-26 18:59:16 +08:00
Key => uint16
Version => uint16
2020-05-25 21:55:51 +08:00
Content => bytes // see command details below
```
Most commands are request/reply, but some commands (e.g. `Deliver`) are one-direction only and thus
2021-02-22 18:42:34 +08:00
does not contain a correlation ID.
Some responses may carry additional information than just the response code, this is specified in the command definition.
2020-05-25 21:55:51 +08:00
2021-02-26 18:59:16 +08:00
Keys are uint16, but the actual value is defined on the last 15 bits, the most significant bit being
2021-02-26 18:03:36 +08:00
used to make the difference between a request (0) and a response (1). Example for `subscribe`
(key is 6):
```
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
0x0006 => subscribe request
0x8006 => subscribe response
2021-02-26 18:03:36 +08:00
```
2021-01-18 21:25:24 +08:00
== Response Codes
.Stream Protocol Response Codes
|===
|Response|Code
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|OK|0x01
|Stream does not exist|0x02
|Subscription ID already exists|0x03
|Subscription ID does not exist|0x04
|Stream already exists|0x05
|Stream not available|0x06
|SASL mechanism not supported|0x07
|Authentication failure|0x08
|SASL error|0x09
|SASL challenge|0x0a
|SASL authentication failure loopback|0x0b
|Virtual host access failure|0x0c
|Unknown frame|0x0d
|Frame too large|0x0e
|Internal error|0x0f
|Access refused|0x10
|Precondition failed|0x11
|Publisher does not exist|0x12
2021-12-02 00:59:14 +08:00
|No offset|0x13
2021-01-18 21:25:24 +08:00
|===
2020-05-25 21:55:51 +08:00
== Commands
.Stream Protocol Commands
|===
|Command |From |Key | Expects response?
2021-02-22 22:19:58 +08:00
|<<declarepublisher>>
2020-05-25 21:55:51 +08:00
|Client
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x0001
2021-01-18 18:25:21 +08:00
|Yes
2020-05-25 21:55:51 +08:00
2021-01-18 18:25:21 +08:00
|<<publish>>
|Client
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x0002
2020-05-25 21:55:51 +08:00
|No
2020-05-25 23:02:43 +08:00
2021-01-18 18:25:21 +08:00
|<<publishconfirm>>
|Server
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x0003
2021-01-18 18:25:21 +08:00
|No
2020-05-25 23:02:43 +08:00
2021-01-18 18:25:21 +08:00
|<<publisherror>>
2020-05-25 23:02:43 +08:00
|Server
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x0004
2020-05-25 23:02:43 +08:00
|No
2021-01-18 18:25:21 +08:00
|<<querypublishersequence>>
2020-05-25 23:02:43 +08:00
|Client
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x0005
2021-01-18 18:25:21 +08:00
|Yes
2020-05-25 23:02:43 +08:00
2021-02-22 22:19:58 +08:00
|<<deletepublisher>>
2020-05-25 23:02:43 +08:00
|Client
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x0006
2020-05-25 23:02:43 +08:00
|Yes
2021-01-18 18:25:21 +08:00
|<<subscribe>>
|Client
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x0007
2021-01-18 18:25:21 +08:00
|Yes
2020-05-25 23:02:43 +08:00
2021-01-18 18:25:21 +08:00
|<<deliver>>
2020-05-25 23:02:43 +08:00
|Server
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x0008
2020-05-25 23:02:43 +08:00
|No
2021-01-18 18:25:21 +08:00
|<<credit>>
2020-05-25 23:02:43 +08:00
|Client
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x0009
2020-05-25 23:02:43 +08:00
|No
2021-07-08 16:32:04 +08:00
|<<storeoffset>>
2020-05-25 23:02:43 +08:00
|Client
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x000a
2021-01-18 18:25:21 +08:00
|No
2020-05-25 23:02:43 +08:00
2021-01-18 18:25:21 +08:00
|<<queryoffset>>
2020-05-25 23:02:43 +08:00
|Client
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x000b
2020-05-25 23:02:43 +08:00
|Yes
2021-01-18 18:25:21 +08:00
|<<unsubscribe>>
|Client
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x000c
2020-05-25 23:02:43 +08:00
|Yes
2021-01-18 18:25:21 +08:00
|<<create>>
|Client
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x000d
2020-05-25 23:02:43 +08:00
|Yes
2021-01-18 18:25:21 +08:00
|<<delete>>
|Client
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x000e
2020-05-25 23:02:43 +08:00
|Yes
2021-01-18 18:25:21 +08:00
|<<metadata>>
|Client
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x000f
2021-02-22 22:19:58 +08:00
|Yes
2020-05-25 23:02:43 +08:00
2021-01-18 18:25:21 +08:00
|<<metadataupdate>>
|Server
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x0010
2021-01-18 18:25:21 +08:00
|No
2020-06-10 16:42:29 +08:00
2021-01-18 18:25:21 +08:00
|<<peerproperties>>
2020-09-15 23:52:05 +08:00
|Client
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x0011
2021-01-18 18:25:21 +08:00
|Yes
2020-09-15 23:52:05 +08:00
2021-01-18 18:25:21 +08:00
|<<saslhandshake>>
2020-09-15 23:52:05 +08:00
|Client
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x0012
2020-09-15 23:52:05 +08:00
|Yes
2021-01-18 18:25:21 +08:00
|<<saslauthenticate>>
2020-11-20 18:43:04 +08:00
|Client
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x0013
2020-11-20 18:43:04 +08:00
|Yes
2021-01-18 18:25:21 +08:00
|<<tune>>
|Server
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x0014
2020-11-20 18:43:04 +08:00
|Yes
2021-01-18 18:25:21 +08:00
|<<open>>
2021-05-19 18:34:35 +08:00
|Client
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x0015
2020-11-26 17:02:13 +08:00
|Yes
2021-01-18 18:25:21 +08:00
|<<close>>
|Client & Server
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x0016
2020-05-25 23:02:43 +08:00
|Yes
2021-01-18 18:25:21 +08:00
|<<heartbeat>>
|Client & Server
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x0017
2021-01-18 18:25:21 +08:00
|No
2021-02-26 00:22:42 +08:00
2022-07-21 21:58:59 +08:00
|<<route>>
2021-02-26 00:22:42 +08:00
|Client
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x0018
2021-02-26 00:22:42 +08:00
|Yes
2022-07-21 21:58:59 +08:00
|<<partitions>>
2021-02-26 00:22:42 +08:00
|Client
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
|0x0019
2021-02-26 00:22:42 +08:00
|Yes
2021-11-18 00:28:52 +08:00
2022-07-21 21:58:59 +08:00
|<<consumerupdate>>
2021-11-18 00:28:52 +08:00
|Server
2022-07-22 15:40:45 +08:00
|0x001a
2021-11-18 00:28:52 +08:00
|Yes
2022-07-25 15:38:06 +08:00
|<<exchangecommandversions>>
|Client
|0x001b
|Yes
2022-08-09 00:02:51 +08:00
|<<streamstats>>
2022-08-03 20:38:45 +08:00
|Client
|0x001c
|Yes
2023-10-27 22:56:31 +08:00
|<<createsuperstream>>
|Client
|0x001d
|Yes
|<<deletesuperstream>>
|Client
|0x001e
|Yes
2020-05-25 21:55:51 +08:00
|===
2021-01-18 18:25:21 +08:00
=== DeclarePublisher
```
DeclarePublisherRequest => Key Version CorrelationId PublisherId [PublisherReference] Stream
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x0001
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
2021-01-18 18:25:21 +08:00
PublisherId => uint8
PublisherReference => string // max 256 characters
Stream => string
2021-10-29 00:53:22 +08:00
DeclarePublisherResponse => Key Version CorrelationId ResponseCode
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x8001
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
ResponseCode => uint16
2021-01-18 18:25:21 +08:00
```
2020-05-25 21:55:51 +08:00
=== Publish
2023-05-23 20:41:31 +08:00
Version 1
```
Publish => Key Version PublisherId PublishedMessages
Key => uint16 // 0x0002
Version => uint16
PublisherId => uint8
PublishedMessages => [PublishedMessage]
PublishedMessage => PublishingId Message
PublishingId => uint64
Message => bytes
```
Version 2
2020-05-25 21:55:51 +08:00
```
2021-07-21 16:13:55 +08:00
Publish => Key Version PublisherId PublishedMessages
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x0002
2021-02-26 18:59:16 +08:00
Version => uint16
2020-09-29 17:29:56 +08:00
PublisherId => uint8
2020-05-25 21:55:51 +08:00
PublishedMessages => [PublishedMessage]
PublishedMessage => PublishingId Message
2021-02-26 18:59:16 +08:00
PublishingId => uint64
2023-05-23 20:41:31 +08:00
FilterValue => string
2020-05-25 21:55:51 +08:00
Message => bytes
```
2024-05-27 05:25:46 +08:00
1. Use version 1 if there is no filter value.
2024-05-27 06:24:39 +08:00
2. Use version 2 if there is a filter value.
2024-05-27 05:25:46 +08:00
2020-05-25 21:55:51 +08:00
=== PublishConfirm
```
PublishConfirm => Key Version PublishingIds
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x0003
2021-02-26 18:59:16 +08:00
Version => uint16
2020-09-29 17:29:56 +08:00
PublisherId => uint8
2021-02-26 18:59:16 +08:00
PublishingIds => [uint64] // to correlate with the messages sent
2020-05-25 21:55:51 +08:00
```
2020-05-25 23:02:43 +08:00
2021-01-18 18:25:21 +08:00
=== PublishError
```
PublishError => Key Version [PublishingError]
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x0004
2021-02-26 18:59:16 +08:00
Version => uint16
2021-01-18 18:25:21 +08:00
PublisherId => uint8
PublishingError => PublishingId Code
2021-02-26 18:59:16 +08:00
PublishingId => uint64
Code => uint16 // code to identify the problem
2021-01-18 18:25:21 +08:00
```
=== QueryPublisherSequence
```
QueryPublisherRequest => Key Version CorrelationId PublisherReference Stream
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x0005
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
2021-01-18 18:25:21 +08:00
PublisherReference => string // max 256 characters
Stream => string
QueryPublisherResponse => Key Version CorrelationId ResponseCode Sequence
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x8005
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
ResponseCode => uint16
2021-01-18 18:25:21 +08:00
Sequence => uint64
```
=== DeletePublisher
```
DeletePublisherRequest => Key Version CorrelationId PublisherId
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x0006
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
2021-01-18 18:25:21 +08:00
PublisherId => uint8
DeletePublisherResponse => Key Version CorrelationId ResponseCode
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x8006
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
ResponseCode => uint16
2021-01-18 18:25:21 +08:00
```
2020-05-25 23:02:43 +08:00
=== Subscribe
```
2021-05-19 18:26:30 +08:00
Subscribe => Key Version CorrelationId SubscriptionId Stream OffsetSpecification Credit Properties
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x0007
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32 // correlation id to correlate the response
2020-09-29 17:29:56 +08:00
SubscriptionId => uint8 // client-supplied id to identify the subscription
2020-05-25 23:02:43 +08:00
Stream => string // the name of the stream
2020-06-02 22:35:00 +08:00
OffsetSpecification => OffsetType Offset
2021-02-26 18:59:16 +08:00
OffsetType => uint16 // 1 (first), 2 (last), 3 (next), 4 (offset), 5 (timestamp)
2020-06-02 22:35:00 +08:00
Offset => uint64 (for offset) | int64 (for timestamp)
2021-02-26 18:59:16 +08:00
Credit => uint16
2021-05-19 18:26:30 +08:00
Properties => [Property]
Property => Key Value
Key => string
Value => string
2020-05-25 23:02:43 +08:00
```
2021-11-25 02:26:25 +08:00
NB: Timestamp is https://www.erlang.org/doc/apps/erts/time_correction.html#Erlang_System_Time[Erlang system time],
milliseconds from epoch
2023-05-24 23:07:39 +08:00
Supported properties:
* `single-active-consumer`: set to `true` to enable https://blog.rabbitmq.com/posts/2022/07/rabbitmq-3-11-feature-preview-single-active-consumer-for-streams/[single active consumer] for this subscription.
* `super-stream`: set to the name of the super stream the subscribed is a partition of.
* `filter.` (e.g. `filter.0`, `filter.1`, etc): prefix to use to define filter values for the subscription.
* `match-unfiltered`: whether to return messages without any filter value or not.
2020-05-25 23:02:43 +08:00
=== Deliver
2022-07-26 17:37:46 +08:00
Version 1
2020-05-25 23:02:43 +08:00
```
Deliver => Key Version SubscriptionId OsirisChunk
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x0008
2021-11-14 22:51:35 +08:00
Version => uint16
2020-09-29 17:29:56 +08:00
SubscriptionId => uint8
2024-06-22 20:34:37 +08:00
OsirisChunk => MagicVersion ChunkType NumEntries NumRecords Timestamp Epoch ChunkFirstOffset ChunkCrc DataLength TrailerLength BloomSize Reserved Messages
2020-05-25 23:02:43 +08:00
MagicVersion => int8
2021-11-14 22:51:35 +08:00
ChunkType => int8 // 0: user, 1: tracking delta, 2: tracking snapshot
2020-05-25 23:02:43 +08:00
NumEntries => uint16
NumRecords => uint32
2021-11-25 02:26:25 +08:00
Timestamp => int64 // erlang system time in milliseconds, since epoch
2020-05-25 23:02:43 +08:00
Epoch => uint64
ChunkFirstOffset => uint64
ChunkCrc => int32
DataLength => uint32
2021-11-14 22:51:35 +08:00
TrailerLength => uint32
2024-06-22 20:34:37 +08:00
BloomSize => uint8 // size of bloom filter data, ignored at the moment
2024-05-27 06:26:12 +08:00
Reserved => uint24 // 24 bits reserved for future use
2024-05-27 06:21:26 +08:00
Messages => [Message] // a continous collection of messages, the size of the array is defined by NumEntries
2020-05-25 23:02:43 +08:00
Message => EntryTypeAndSize
Data => bytes
```
2022-07-26 17:37:46 +08:00
Version 2
```
Deliver => Key Version SubscriptionId CommittedOffset OsirisChunk
Key => uint16 // 0x0008
Version => uint16
SubscriptionId => uint8
2022-08-09 00:02:51 +08:00
CommittedChunkId => uint64
2024-06-22 20:34:37 +08:00
OsirisChunk => MagicVersion ChunkType NumEntries NumRecords Timestamp Epoch ChunkFirstOffset ChunkCrc DataLength TrailerLength BloomSize Reserved Messages
2022-07-26 17:37:46 +08:00
MagicVersion => int8
ChunkType => int8 // 0: user, 1: tracking delta, 2: tracking snapshot
NumEntries => uint16
NumRecords => uint32
Timestamp => int64 // erlang system time in milliseconds, since epoch
Epoch => uint64
ChunkFirstOffset => uint64
ChunkCrc => int32
DataLength => uint32
TrailerLength => uint32
2024-06-22 20:34:37 +08:00
BloomSize => uint8 // size of bloom filter data, ignored at the moment
2024-05-27 06:26:12 +08:00
Reserved => uint24 // 24 bits reserved for future use
2024-05-27 06:21:26 +08:00
Messages => [Message] // a continous collection of messages, the size of the array is defined by NumEntries
2022-07-26 17:37:46 +08:00
Message => EntryTypeAndSize
Data => bytes
```
2024-05-27 05:25:46 +08:00
NB: See the https://github.com/rabbitmq/osiris/blob/12a430b11be2c2be3f26ce4f2d7268954c7ec02b/src/osiris_log.erl#L126-L195[Osiris project]
2020-05-25 23:02:43 +08:00
for details on the structure of messages.
=== Credit
```
Credit => Key Version SubscriptionId Credit
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x0009
2021-02-26 18:59:16 +08:00
Version => uint16
SubscriptionId => uint8
Credit => uint16 // the number of chunks that can be sent
2020-06-19 21:27:46 +08:00
CreditResponse => Key Version ResponseCode SubscriptionId
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x8009
2021-02-26 18:59:16 +08:00
Version => uint16
ResponseCode => uint16
SubscriptionId => uint8
2020-05-25 23:02:43 +08:00
```
2020-06-19 21:27:46 +08:00
NB: the server sent a response only in case of problem, e.g. crediting an unknown subscription.
2021-07-08 16:32:04 +08:00
=== StoreOffset
2020-05-25 23:02:43 +08:00
```
2021-07-08 16:32:04 +08:00
StoreOffset => Key Version Reference Stream Offset
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x000a
2021-02-26 18:59:16 +08:00
Version => uint16
2021-01-18 18:25:21 +08:00
Reference => string // max 256 characters
2021-09-02 04:13:07 +08:00
Stream => string // the name of the stream
2021-02-26 18:59:16 +08:00
Offset => uint64
2020-05-25 23:02:43 +08:00
```
2021-01-18 18:25:21 +08:00
=== QueryOffset
2020-05-25 23:02:43 +08:00
```
2021-01-18 18:25:21 +08:00
QueryOffsetRequest => Key Version CorrelationId Reference Stream
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x000b
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
2021-01-18 18:25:21 +08:00
Reference => string // max 256 characters
Stream => string
2020-05-25 23:02:43 +08:00
2021-01-18 18:25:21 +08:00
QueryOffsetResponse => Key Version CorrelationId ResponseCode Offset
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x800b
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
ResponseCode => uint16
2021-01-18 18:25:21 +08:00
Offset => uint64
2020-05-25 23:02:43 +08:00
```
2021-01-18 18:25:21 +08:00
=== Unsubscribe
2020-05-25 23:02:43 +08:00
```
2021-01-18 18:25:21 +08:00
Unsubscribe => Key Version CorrelationId SubscriptionId
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x000c
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
SubscriptionId => uint8
2023-05-15 17:44:46 +08:00
UnsubscribeResponse => Key Version CorrelationId ResponseCode
Key => uint16 // 0x800c
Version => uint16
CorrelationId => uint32
ResponseCode => uint16
2020-05-25 23:02:43 +08:00
```
2021-01-18 18:25:21 +08:00
=== Create
2020-05-25 23:02:43 +08:00
```
2021-01-18 18:25:21 +08:00
Create => Key Version CorrelationId Stream Arguments
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x000d
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
2021-01-18 18:25:21 +08:00
Stream => string
Arguments => [Argument]
Argument => Key Value
Key => string
Value => string
```
2020-05-25 23:02:43 +08:00
2021-01-18 18:25:21 +08:00
=== Delete
```
Delete => Key Version CorrelationId Stream
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x000e
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
2021-01-18 18:25:21 +08:00
Stream => string
2020-05-25 23:02:43 +08:00
```
2021-01-18 18:25:21 +08:00
=== Metadata
2020-05-25 23:02:43 +08:00
```
2021-01-18 18:25:21 +08:00
MetadataQuery => Key Version CorrelationId [Stream]
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x000f
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
2021-01-18 18:25:21 +08:00
Stream => string
2020-05-25 23:02:43 +08:00
2021-01-18 18:25:21 +08:00
MetadataResponse => Key Version CorrelationId [Broker] [StreamMetadata]
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x800f
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
2021-01-18 18:25:21 +08:00
Broker => Reference Host Port
2021-02-26 18:59:16 +08:00
Reference => uint16
2021-01-18 18:25:21 +08:00
Host => string
2021-02-26 18:59:16 +08:00
Port => uint32
2022-05-17 08:15:40 +08:00
StreamMetadata => StreamName ResponseCode LeaderReference ReplicasReferences
2021-01-18 18:25:21 +08:00
StreamName => string
2021-02-26 18:59:16 +08:00
ResponseCode => uint16
LeaderReference => uint16
ReplicasReferences => [uint16]
2020-05-25 23:02:43 +08:00
```
2021-01-18 18:25:21 +08:00
=== MetadataUpdate
2020-05-25 23:02:43 +08:00
```
2021-01-18 18:25:21 +08:00
MetadataUpdate => Key Version MetadataInfo
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x0010
2021-02-26 18:59:16 +08:00
Version => uint16
2021-01-18 18:25:21 +08:00
MetadataInfo => Code Stream
2021-02-26 18:59:16 +08:00
Code => uint16 // code to identify the information
2021-01-18 18:25:21 +08:00
Stream => string // the stream implied
2020-05-25 23:02:43 +08:00
```
2020-06-10 16:42:29 +08:00
=== PeerProperties
```
PeerPropertiesRequest => Key Version PeerProperties
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x0011
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
2020-06-10 16:42:29 +08:00
PeerProperties => [PeerProperty]
PeerProperty => Key Value
Key => string
Value => string
2021-01-18 18:25:21 +08:00
PeerPropertiesResponse => Key Version CorrelationId ResponseCode PeerProperties
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x8011
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
ResponseCode => uint16
2020-06-10 16:42:29 +08:00
PeerProperties => [PeerProperty]
PeerProperty => Key Value
Key => string
Value => string
```
2021-01-18 18:25:21 +08:00
=== SaslHandshake
2020-09-15 23:52:05 +08:00
```
2021-01-18 18:25:21 +08:00
SaslHandshakeRequest => Key Version CorrelationId Mechanism
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x0012
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
2020-09-15 23:52:05 +08:00
2021-10-29 00:53:22 +08:00
SaslHandshakeResponse => Key Version CorrelationId ResponseCode [Mechanisms]
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x8012
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
ResponseCode => uint16
2021-10-29 00:53:22 +08:00
Mechanisms => [Mechanism]
2021-01-18 18:25:21 +08:00
Mechanism => string
2020-09-15 23:52:05 +08:00
```
2021-01-18 18:25:21 +08:00
=== SaslAuthenticate
2020-11-20 18:43:04 +08:00
```
2021-01-18 18:25:21 +08:00
SaslAuthenticateRequest => Key Version CorrelationId Mechanism SaslOpaqueData
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x0013
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
2021-01-18 18:25:21 +08:00
Mechanism => string
SaslOpaqueData => bytes
2020-11-20 18:43:04 +08:00
2021-01-18 18:25:21 +08:00
SaslAuthenticateResponse => Key Version CorrelationId ResponseCode SaslOpaqueData
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x8013
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
ResponseCode => uint16
2021-01-18 18:25:21 +08:00
SaslOpaqueData => bytes
2020-11-20 18:43:04 +08:00
```
2021-01-18 18:25:21 +08:00
=== Tune
2020-11-20 18:43:04 +08:00
```
2021-01-18 18:25:21 +08:00
TuneRequest => Key Version FrameMax Heartbeat
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x0014
2021-02-26 18:59:16 +08:00
Version => uint16
FrameMax => uint32 // in bytes, 0 means no limit
Heartbeat => uint32 // in seconds, 0 means no heartbeat
2020-11-20 18:43:04 +08:00
2021-01-18 18:25:21 +08:00
TuneResponse => TuneRequest
2020-11-20 18:43:04 +08:00
```
2021-01-18 18:25:21 +08:00
=== Open
2020-11-26 17:02:13 +08:00
```
2021-01-18 18:25:21 +08:00
OpenRequest => Key Version CorrelationId VirtualHost
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x0015
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
2021-01-18 18:25:21 +08:00
VirtualHost => string
2020-11-26 17:02:13 +08:00
2021-05-21 19:03:38 +08:00
OpenResponse => Key Version CorrelationId ResponseCode ConnectionProperties
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x8015
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
ResponseCode => uint16
2021-05-21 19:03:38 +08:00
ConnectionProperties => [ConnectionProperty]
ConnectionProperty => Key Value
Key => string
Value => string
2020-11-26 17:02:13 +08:00
```
2021-01-18 18:25:21 +08:00
=== Close
2020-05-25 23:02:43 +08:00
```
2021-01-18 18:25:21 +08:00
CloseRequest => Key Version CorrelationId ClosingCode ClosingReason
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x0016
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
ClosingCode => uint16
2021-01-18 18:25:21 +08:00
ClosingReason => string
CloseResponse => Key Version CorrelationId ResponseCode
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x8016
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
ResponseCode => uint16
2020-05-25 23:02:43 +08:00
```
2021-01-18 18:25:21 +08:00
=== Heartbeat
2020-05-25 23:02:43 +08:00
```
2021-01-18 18:25:21 +08:00
Heartbeat => Key Version
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x0017
2021-02-26 18:59:16 +08:00
Version => uint16
2020-05-25 23:02:43 +08:00
```
2020-05-25 23:53:34 +08:00
2021-02-26 18:03:36 +08:00
=== Route
2021-02-26 00:22:42 +08:00
```
RouteQuery => Key Version CorrelationId RoutingKey SuperStream
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x0018
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
2021-02-26 00:22:42 +08:00
RoutingKey => string
SuperStream => string
2021-11-18 00:28:52 +08:00
RouteResponse => Key Version CorrelationId ResponseCode [Stream]
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x8018
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
2021-11-18 00:28:52 +08:00
ResponseCode => uint16
2021-02-26 00:22:42 +08:00
Stream => string
```
2021-02-26 18:48:45 +08:00
=== Partitions
2021-02-26 00:22:42 +08:00
```
PartitionsQuery => Key Version CorrelationId SuperStream
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x0019
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
2021-02-26 00:22:42 +08:00
SuperStream => string
2021-11-18 00:28:52 +08:00
PartitionsResponse => Key Version CorrelationId ResponseCode [Stream]
Use hex values in RabbitMQ Streams protocol description
The protocol documentation uses decimal values for error and request key
codes.
Let's use hex values instead. This helps when looking at a request and
its response - 0x0006 and 0x8006 vs. 6 and 32774.
Also, when looking at output of protocol analysis tools like Wireshark,
a hexadecimal value will be printed, for example:
"Nov 1, 2021 23:05:19.395825508 GMT","60216,5552","00000009000600010000000701"
"Nov 1, 2021 23:05:19.396069528 GMT","5552,60216","0000000a80060001000000070001"
Above, we can visually identify delete publisher request and response
(0x0006 and 0x8006) and easily match them in the documentation of the
protocol.
Finally, above argument applies to logging as it is common to log
hex values, not decimal.
2021-11-03 02:31:30 +08:00
Key => uint16 // 0x8019
2021-02-26 18:59:16 +08:00
Version => uint16
CorrelationId => uint32
2021-11-18 00:28:52 +08:00
ResponseCode => uint16
2021-02-26 00:22:42 +08:00
Stream => string
```
2022-07-21 21:58:59 +08:00
=== ConsumerUpdate
2021-11-18 00:28:52 +08:00
```
ConsumerUpdateQuery => Key Version CorrelationId SubscriptionId Active
Key => uint16 // 0x001a
Version => uint16
CorrelationId => uint32
SubscriptionId => uint8
Active => uint8 (boolean, 0 = false, 1 = true)
ConsumerUpdateResponse => Key Version CorrelationId ResponseCode OffsetSpecification
Key => uint16 // 0x801a
Version => uint16
CorrelationId => uint32
ResponseCode => uint16
OffsetSpecification => OffsetType Offset
OffsetType => uint16 // 0 (none), 1 (first), 2 (last), 3 (next), 4 (offset), 5 (timestamp)
Offset => uint64 (for offset) | int64 (for timestamp)
```
2022-07-29 19:46:00 +08:00
=== ExchangeCommandVersions
2022-07-25 15:38:06 +08:00
```
CommandVersionsExchangeRequest => Key Version CorrelationId [Command]
Key => uint16 // 0x001b
Version => uint16
CorrelationId => uint32
Command => Key MinVersion MaxVersion
Key => uint16
MinVersion => uint16
MaxVersion => uint16
CommandVersionsExchangeResponse => Key Version CorrelationId ResponseCode [Command]
Key => uint16 // 0x801b
Version => uint16
CorrelationId => uint32
ResponseCode => uint16
Command => Key MinVersion MaxVersion
Key => uint16
MinVersion => uint16
MaxVersion => uint16
```
2022-08-09 00:02:51 +08:00
=== StreamStats
2022-08-03 20:38:45 +08:00
```
2022-08-09 00:02:51 +08:00
StreamStatsRequest => Key Version CorrelationId Stream
2022-08-03 20:38:45 +08:00
Key => uint16 // 0x001c
Version => uint16
CorrelationId => uint32
Stream => string
2022-08-09 00:02:51 +08:00
StreamStatsResponse => Key Version CorrelationId ResponseCode Stats
2022-08-03 20:38:45 +08:00
Key => uint16 // 0x801c
Version => uint16
CorrelationId => uint32
ResponseCode => uint16
2022-08-09 00:02:51 +08:00
Stats => [Statistic]
Statistic => Key Value
2022-08-03 20:38:45 +08:00
Key => string
2022-08-09 00:02:51 +08:00
Value => int64
2022-08-03 20:38:45 +08:00
```
2023-10-27 22:56:31 +08:00
=== CreateSuperStream
```
2023-11-13 21:54:45 +08:00
CreateSuperStream => Key Version CorrelationId Name [Partition] [BindingKey] Arguments
2023-10-27 22:56:31 +08:00
Key => uint16 // 0x001d
Version => uint16
CorrelationId => uint32
Name => string
Partition => string
2023-11-13 21:54:45 +08:00
BindingKey => string
2023-10-27 22:56:31 +08:00
Arguments => [Argument]
Argument => Key Value
Key => string
Value => string
```
=== DeleteSuperStream
```
Delete => Key Version CorrelationId Name
Key => uint16 // 0x001e
Version => uint16
CorrelationId => uint32
Name => string
```
2022-07-25 15:38:06 +08:00
2020-05-25 23:53:34 +08:00
== Authentication
Once a client is connected to the server, it initiates an authentication
sequence. The next figure shows the steps of the sequence:
[ditaa]
.Authentication Sequence
....
Client Server
+ +
2020-06-10 16:42:29 +08:00
| Peer Properties Exchange |
|-------------------------->|
|<--------------------------|
| |
2020-05-25 23:53:34 +08:00
| SASL Handshake |
|-------------------------->|
|<--------------------------|
| |
| SASL Authenticate |
|-------------------------->|
|<--------------------------|
| |
| Tune |
|<--------------------------|
|-------------------------->|
| |
| Open |
|-------------------------->|
|<--------------------------|
| |
+ +
....
* SaslHandshake: the client asks about the SASL mechanisms the server supports. It
can then pick one from the list the server returns.
* SaslAuthenticate: the client answers to the server's challenge(s), using the
SASL mechanism it picked. The server will send a `Tune` frame once it is satisfied
with the client authentication response.
2020-05-25 23:56:02 +08:00
* Tune: the server sends a `Tune` frame to suggest some settings (max frame size, heartbeat).
The client answers with a `Tune` frame with the settings he agrees on, possibly adjusted
from the server's suggestions.
* Open: the client sends an `Open` frame to pick a virtual host to connect to. The server
2021-02-22 18:42:34 +08:00
answers whether it accepts the access or not.
