Skip to content
This repository has been archived by the owner on May 4, 2023. It is now read-only.

Break down the layered approach of handling package into something linear #1

Open
Pommaq opened this issue Aug 29, 2021 · 2 comments
Open
Assignees
Labels
enhancement New feature or request question Further information is requested

Comments

@Pommaq
Copy link
Owner

Pommaq commented Aug 29, 2021

The current design requires us to know whether or not a package is broken or not before grabbing the next one (since it skips any byte that are part of a good message) by passing the packet up the layers before continuing. This needs to be broken apart but there is a design decision that needs to be done:
Since we won't know if a packet is good or not (or rather, if broken ones are fixable) when grabbing data, should we always assume a packet is good and skip the next bytes that belong to it, or always assume its bad and find "subpackets"?

@Pommaq Pommaq self-assigned this Aug 29, 2021
@Pommaq Pommaq added enhancement New feature or request question Further information is requested labels Aug 29, 2021
@Pommaq Pommaq added this to To do in Performance Optimization via automation Aug 29, 2021
@Pommaq
Copy link
Owner Author

Pommaq commented Aug 30, 2021

Portions of data that may be "interleaving" can be inserted into a vector or "bucket", once all of these has had an attempt at being fixed or all are Ok we can make the decision of which will be used. as such we should assume the packet is bad whenever the crc is bad.

@Pommaq
Copy link
Owner Author

Pommaq commented Sep 2, 2021

Additionally the class "ModeSMessage" should be split into multiple classes for each stage.
One for when we first find it and simply wish to parse its crc status etc and one for when its fixed. This gives a more natural look into what a function expects from a message and cleans up the program structure.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request question Further information is requested
Development

No branches or pull requests

1 participant