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

Control protocol version frame #42

Open
BenediktBurger opened this issue Feb 8, 2023 · 5 comments
Open

Control protocol version frame #42

BenediktBurger opened this issue Feb 8, 2023 · 5 comments
Labels
discussion-needed A solution still needs to be determined messages Concerns the message format

Comments

@BenediktBurger
Copy link
Member

How do we encode the version in the control protocol version frame?

We could use an ever increasing binary number, using the whole frame.
In python it would be simple:

version = int.from_bytes(version_frame, byteorder="big")

A universal implementation would be:

version = 0
for byte in version_frame:
    version << 8
    version += byte
@BenediktBurger BenediktBurger added discussion-needed A solution still needs to be determined messages Concerns the message format labels Feb 8, 2023
@bklebel
Copy link
Collaborator

bklebel commented Feb 8, 2023

I have to admit I am puzzled - can't we just utf8-encode an ascii typical version number, like 0.1.0?

version = "0.1.0".encode("utf-8")

and similarly

version = version_frame.decode("utf-8")

Or does utf-8 produce so much overhead? or just go with .encode("ascii")?
I will always vote for the simplest, almost laziest way to do simple things. utf-8 might not seem simpler than pure binary, but it has super simple decoding-encoding methods in python....I am not sure about other languages though. Manual bit operations always seemed just so cumbersome to me, as if that wasn't the simplest thing one could implement in a convenience function at the very least.

@BenediktBurger
Copy link
Member Author

BenediktBurger commented Feb 8, 2023

I would use ASCII encoding, which should be easily available in virtually every language.

I thought about encoding, but forgot to write it...

@bklebel
Copy link
Collaborator

bklebel commented Feb 8, 2023

Ok, sounds reasonable. Would we then also make the same restriction on the Recipient and Sender Names, and Namespaces, that it needs to go with ascii encoding? Or do we want to allow anyone to use almost any symbols for their Component Names, with utf-8?

@BenediktBurger
Copy link
Member Author

In the PR, I required a bytes sequence, except byte value 46, which corresponds to a period in ASCII.

For the Routing it does not matter, how the names are formatted and whether they are formatted at all, as long as they do not contain a byte with value 46.
So the users can use ASCII, maybe utf-8 (I do not know, whether multi-byte characters could have a byte with value 46).
Or they can use their own, funny numbering scheme...

@bilderbuchi
Copy link
Member

bilderbuchi commented Feb 8, 2023

I would have said an unsigned integer made of 1 byte (255 versions), or maybe 2 bytes (major+minor version). I would not have encoded strings into the version at all - why go to the complexity (and need to specify the encoding, then)?
COAP uses 2 bits; Avro uses 2 bytes, of which one identifies that the protocol is Avro; ZMTP uses 2 bytes (major/minor version), also interesting: https://rfc.zeromq.org/spec/23/#version-negotiation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion-needed A solution still needs to be determined messages Concerns the message format
Projects
None yet
Development

No branches or pull requests

3 participants