Some time ago, I posted a suggestion about handling of orphaned type 24 'a' or 'b' message processing in gpsd. Eric replied that there is a holding buffer for unmatched type 24 packets and he could increase the buffer size if needed. Unfortunately that won't work for us.
We've got a couple of gpsd instances running that each process just over 2 million AIS messages per day that are sourced from satellite and terrestrial networks.
gpsd handles this huge workload gracefully and reliably, with one exception.
type 24 messages almost never appear as output, even though thousand are presented. I believe that this is due to gpsd expecting that every type 24A message will be followed in reasonably short order by a matching type 24B. As I recall, there is a buffer somewhere that holds unmatched type 24A messages up to some defined number, then when 24B messages arrive it finds the matching 24A and combines the two into a complete type 24 message on the output.
This is fine when type 24 A and B messages arrive more or less as pairs. But the feed from the satellites don't produce that. I may see thousands of type 24A's before a 24B comes along, or (less often) the opposite. I suspect that this is because the satellite receivers are rate limited for messages that arrive with a fragment count and fragment number of 1 and 1. It appears that all type 24 messages arrive with a count and a fragment number of 1, whether they are type A or B.
Other multi-part messages (like Type 5) use the fragment count and number as intended (2,1 and 2,2) so they don't get dropped by the rate limiter.
Other than backward compatibility, I don't think there is any reason that type 24 A and B messages couldn't be handled as if they were different completely different, separate message types. Type A contains an mmsi and vessel name, type 4B contains an mmsi and other static info. There is no data overlap other than mmsi.