docs(bolt): Changes in examples of handshake.adoc #60
Conversation
- Modification in the example to display the inclusion of version 4.1 instead of version 4.0. - Adjustment in the example to accurately reflect the server's response with version 4.1.
| @@ -105,13 +105,13 @@ The range cannot span multiple major versions. | |||
|
|
|||
| .Example with versions 4.3 plus two previous minor versions, 4.2 and 4.1 | |||
| ---- | |||
| 00 02 03 04 | |||
| 01 02 03 04 | |||
There was a problem hiding this comment.
The first byte is reserved. It's recommended to send 0, but the server will likely ignore it either way.
| 01 02 03 04 | |
| 00 02 03 04 |
There was a problem hiding this comment.
Thank you for pointing that out. Although I don't recall reading that specification in the documentation, I think it's not relevant. However, I believe including the clarification about the first reserved byte could be useful for other developers. What do you think?"
There was a problem hiding this comment.
The fact that the first byte is reserved is documented right above this example
The value 00 is not documented other than in the example. The reason being that setting it to anything but 0, will likely cause no harm for servers following the version handshake scheme as described here. However, if we decide to make use of that byte, all code setting the byte to something else will have to be double-checked to not conflict with the future semantics.
It's not a rule set in stone to set it to 0, but we'll probably assume that it's 0 for legacy clients when/if we design some semantics. That's just because all official drivers set it to 0 and all the examples in the docs show it being 0 as well.
There was a problem hiding this comment.
Thank you very much for the response, it is clear now
| ---- | ||
|
|
||
| .Example where the client is aware of five Bolt versions; 3, 4.0, 4.1, 4.2 and 4.3, and the server responds with 4.1 | ||
| ---- | ||
| C: 60 60 B0 17 | ||
| C: 00 03 03 04 00 00 01 04 00 00 00 04 00 00 00 03 | ||
| C: 00 02 03 04 00 00 01 04 00 00 00 04 00 00 00 03 |
There was a problem hiding this comment.
This change would mean the client requests [4.3-4.1, 4.1, 4.0, 3.0], which is equivalent to the current [4.3-4.0, 4.1, 4.0, 3.0]. In fact
C: 00 01 03 04 00 00 01 04 00 00 00 04 00 00 00 03
would be another equivalent client request.
I don't see a reason to change it, though. Finally, if we change it, we must not forget to update the note below explaining the versions requested.
There was a problem hiding this comment.
Sorry for my clumsiness, but I can't understand why this "00 03 03 04" is equivalent to this: 4.3-4.1. Thank you very much.
There was a problem hiding this comment.
No worries. I might have expressed myself unclear. Let me try again.
As per the docs, a version request of the form
00 02 03 04
means Version 4.3 + the 2 consecutive versions before that, i.e., 4.1, 4.2, 4.3 = 4.1-4.3.
That's obviously not equivalent to
00 03 03 04
which means 4.3-4.0. However, with the following versions requested (the whole things reads):
C: 00 01 03 04 00 00 01 04 00 00 00 04 00 00 00 03
which translates to (parentheses to mark requested ranges): "server, please give me (4.3, 4.2), 4.1, 4.0 or 3.0 (in descending preference)".
Because of the overlap of the range with the explicitly requested versions, this is equivalent to
C: 00 03 03 04 00 00 01 04 00 00 00 04 00 00 00 03
which translates to: "server, please give me (4.3, 4.2, 4.1, 4.0), 4.1, 4.0 or 3.0 (in descending preference)".
There was a problem hiding this comment.
Now I understand, I don't know why I always thought it was one version per byte. Now I have it clear, thank you very much.
|
If you want, I can close the PR :) |
Modification in the example to display the inclusion of version 4.1 instead of version 4.0.
Adjustment in the example to accurately reflect the server's response with version 4.1.