sat: packet: accept any payload length up to the max#238
Conversation
Callers had to size satellite payloads to one of the exact wire sizes (0, 4, 9, 13) or the call was rejected, pushing padding decisions onto every caller. Round the length up to the next supported size and zero-pad instead, so callers can pass their data as-is. The supported sizes and their derived symbol/ECC counts now live in a single table rather than three parallel lookups that had to stay in sync. Signed-off-by: Paul Buckley <paul@hubble.com>
|
I believe we discussed this before, and the problem is that we don't know if the customer could be using 0 to indicate something. So if they send 3 bytes for example, does the backend returns 4 bytes as decoded, including the 0 padded? Or does the backend stripped all the 0s? The latter case won't work, and the former case cause confusion. They will need to handle the padded 0s anyway. The argument here is that they know the number of payload they handed in from the application, versus us doing the rounding. So they have to figure out which size if the right one. But I don't make the call on these, so we can definitely change if this is intended / works better than allow fixed size payload. |
|
Yeah, we have discussed it. Padding introduce ambiguity and unless we have a way to avoid it is better to have this protocol requirement explicitly. |
ceolin
left a comment
ceolin
left a comment
There was a problem hiding this comment.
Putting -1 to avoid it getting mistakenly merged.
3 participants
Callers had to size satellite payloads to one of the exact wire sizes (0, 4, 9, 13) or the call was rejected, pushing padding decisions onto every caller. Round the length up to the next supported size and zero-pad instead, so callers can pass their data as-is. The supported sizes and their derived symbol/ECC counts now live in a single table rather than three parallel lookups that had to stay in sync.