Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

docs(bolt): Changes in examples of handshake.adoc #60

Closed
wants to merge 1 commit into from
Closed

docs(bolt): Changes in examples of handshake.adoc #60

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions modules/ROOT/pages/bolt/handshake.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first byte is reserved. It's recommended to send 0, but the server will likely ignore it either way.

Suggested change
01 02 03 04
00 02 03 04

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?"

Copy link
Member

@robsdedude robsdedude Jan 15, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fact that the first byte is reserved is documented right above this example

docs-bolt/modules/ROOT/pages/bolt/handshake.adoc

Line 98 in d4576b0

The first 8 bits are reserved.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@robsdedude robsdedude Jan 15, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)".

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

S: 00 00 01 04
----

Expand Down
Loading