I read bytes from a socket. The data consists only of two types of structures:struct A{    unsigned char type_id;        //0x01    unsigned char sequence_id;    //Incremented in successive packets.    //Some other fields    unsigned char checksum;};struct B{    unsigned char type_id;        //0x02    unsigned char sequence_id;    //Incremented in successive packets. This sequence is independent from A's sequence_ids.    //Some different fields    unsigned char checksum;};These structures are written on the wire with no particular pattern to how they occur. These are the only data that I receive. I can read the data.I am trying to figure out how best to identify these packets in the unsigned char* array I read. Right now I'm iterating until I find the bytes 0x01 or 0x02 and then based on the size of the relevant struct, try to get the next struct. Once I establish that I've found a packet boundary, I just keep on offsetting by sizeof(A) or sizeof(B) accordingly and just hope I'm fine.My problem is that if there's a 0x01 or 0x02 value in a field inside a struct itself when I'm first checking for the beginning of a struct, this method would return invalid structures.Unfortunately I cannot touch the server side. It's quite an old system.One other point is that I join as a client mid-way, that is, the server side always keeps sending data - this means that the first byte I read most of the time is not the beginning of a packet.What can I do to identify structures robustly?
What is the best method to identify objects in a byte array?
c++
Any valid type_id is a possible packet start, but you have two additional fields that can test whether this is the case:For all except the first packet, you can compare the sequence number. If it doesn't match, you got it wrong and should continue to search for the next possible packet start. This would require you to buffer until at least the second packet while establishing a client connection.Once you've read a packet, you can compare the checksum. If it doesn't match, discard the packet and look for the next possible start.Of course this becomes less useful the more type ids there are, because the start symbols might be very frequent. This doesn't make the above approach impossible, just more expensive as you have to test for a packet start more often.Depending on the size of data and on the checksum algorithm, an 8 bit checksum is also extremely slim. E.g. if bytes are just XORed with each other, I'd expect too many false positives for this to be feasible.If you are indeed using sockets as in TCP sockets, the data is guaranteed to arrive uncorrupted, which means the checksum can never be invalid and can be relied on for detecting package boundaries. But in that case, it would also be impossible to receive half a packet.If you are actually listening to a broadcast over a public medium (e.g. radio), there are usually protocols in force that allow synchronization, e.g. a carrier frequency. For data transmission, a start symbol (syncword, sync character, preamble) that cannot occur in the message itself can also be used. For example, Ethernet has a Start Frame Delimiter. In general, taking a look at data link layer protocols might be enlightening to see how these synchronization problems are solved in practice, though many protocols like Ethernet must also handle the problem of multiple senders which doesn't apply in your case.