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

Some protocol improvements #35

Open
mincequi opened this issue Nov 29, 2021 · 0 comments
Open

Some protocol improvements #35

mincequi opened this issue Nov 29, 2021 · 0 comments
Labels
Feature request New feature or request Help wanted Extra attention is needed Question

Comments

@mincequi
Copy link
Contributor

Hi again,

since i am dealing with CayenneLPP quite a bit, i see some serious downsides:
any Change/Extension for another IPSO Object/Property will render any decoder that does not understand the changes unusable.
If the appropriate decoder does not know about each single object that had been sent, i will fail, since it also does not know about the size of the unsupported object.

To circumvent this, i have a suggestion (among others) to improve this protocol:

  1. Do we need 256 Channels? Otherwise, we could limit that to 16 Channels and use other 4 bit for size information. I was thinking about this: 0 - 11 encodes the size if the data object directly. 12 could mean boolean false, 13 boolean true, 14 flags (a flag byte will follow after the type byte, see BIPSO spec), 15 size (a size byte will follow after the type byte). For flags we might define a fixed size for values (e.g. 16 bit value) so the decoder knows how far it shall advance within the byte buffer, if the appropriate object is not understood.
  2. To support extended/more types we could reserve types values starting from 240 (or 248) to indicate, that an extType byte will follow after the type byte (or the size/flags byte if indicated). This would allow another 16 * 256 types (or 8 * 256).

These two changes would perfectly allow anything that comes up in the future and also allows encoders to be backwards compatible with previous protocol versions.
Additionally, boolean data can be encoded directly without spending another byte.
The downside: we would be limited to 16 channels (which is probably enough) if not adding another byte to the payload.

What do you think?

@mincequi mincequi changed the title Some protocol impreovements Some protocol improvements Nov 29, 2021
@sabas1080 sabas1080 added Help wanted Extra attention is needed Question labels Jan 6, 2022
@stale stale bot added the General Information General information is requested label Sep 30, 2022
@xpeqex xpeqex added Bug Something isn't working and removed General Information General information is requested labels Sep 30, 2022
@ElectronicCats ElectronicCats deleted a comment from stale bot Sep 30, 2022
@sabas1080 sabas1080 removed the Bug Something isn't working label Oct 2, 2022
@xpeqex xpeqex added the Feature request New feature or request label Oct 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature request New feature or request Help wanted Extra attention is needed Question
Projects
None yet
Development

No branches or pull requests

3 participants