So, the AIS protocol has messages that are each a string of bits. Sometimes there will be a selector number that's a few bits long which tells what fields make up the next block of however many bits of data. In some cases, that number is after the bits it describes. Which is fine, though I wished I had learned that before I started writing a parser, for a feature I was adding not long after I started there. Fine... as long as the described block is a fixed number of bits.
When we started adding transmit capability (this was several years later), there were some new types of messages we had to generate (actually sub-messages called "Application Specific Messages", but same principle). In the case of two of these message types, the thing that described which type it was came after the block, and the block was a different size depending on which type it was! And there was some other thing that made the whole message the same length. Which meant that whatever was parsing these kinds of messages would sometimes misinterpret them as the wrong type. So I ended up doing binary math to figure out that the way around this was that some auto-generated field (sequence number?) had to always skip number 48 or something like that.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
So, the AIS protocol has messages that are each a string of bits. Sometimes there will be a selector number that's a few bits long which tells what fields make up the next block of however many bits of data. In some cases, that number is after the bits it describes. Which is fine, though I wished I had learned that before I started writing a parser, for a feature I was adding not long after I started there. Fine... as long as the described block is a fixed number of bits.
When we started adding transmit capability (this was several years later), there were some new types of messages we had to generate (actually sub-messages called "Application Specific Messages", but same principle). In the case of two of these message types, the thing that described which type it was came after the block, and the block was a different size depending on which type it was! And there was some other thing that made the whole message the same length. Which meant that whatever was parsing these kinds of messages would sometimes misinterpret them as the wrong type. So I ended up doing binary math to figure out that the way around this was that some auto-generated field (sequence number?) had to always skip number 48 or something like that.