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.

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

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

wants to merge 1 commit into from

Conversation

sagastume
Copy link

  • 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.

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

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

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

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.

@sagastume
Copy link
Author

If you want, I can close the PR :)
Thank you very much for the responses.

@robsdedude robsdedude closed this Jan 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants