A simple protocol I often use is a header/data system like:
//header uint8_t flag; //number that is start of packet uint8_t version; //protocol version number or type of packet uint32_t bytes; //number of bytes in data packet uint32_t headerCRC; //CRC of the header //Data packet uint8_t data[]; uint32_t dataCRC; A Packet is a header followed by a the data This allows me to scan for the flag and then check for valid header using CRC if found then I parse data. If header is not valid I scan for flag until I find a valid header. Depending on what you need you can adjust the number of bits per field as needed. I usually leave the CRC as last field in header/data such that the CRC can be calculated as data is sent (while streaming). The version number is important, too often people change protocol versions (use checksum, or use different field bit sizes) by having version you can support multiple versions as needed, so always include a version number. Sometimes if I am tight on space I will skip the flag byte and then just check every byte for valid header. This all depends on what you need.... I have seen people try to optimize packet sizes, for example in the above if you need to send 4 bytes of data the over head is huge relative speaking. However in my experience every time someone has "optimized" their protocol they end up regretting it, especially if they did not include a version number. With TCP/IP however the data is guaranteed to be delivered with no errors. Thus even sending ASCII strings where the NULL char is the separator will work just fine. Thus for TCP/IP I often stick with ASIC and JSON as it is easy to parse and debug. On Sat, Dec 21, 2019 at 11:41 AM Rod Boyce <r...@teamboyce.co.uk> wrote: > > On 21/12/2019 08:53, goldsimon wrote: > > > > Urvi wrote: > >> [..] > >> > >> But when I send 1 data packet of size=6 bytes (call tcp_write() and > >> then > >> tcp_output()) and next packet of size=45 bytes (call tcp_write() and > >> then > >> tcp_output()), then at server side it receives as a one single data > >> packet > >> of size=51 bytes; due to this my complete data packet becomes garbage > >> and I > >> got failure in communication. (this is just one packet example, but it > >> happens often). > >> > >> > >> How to solve this issue? > > That's expected TCP behaviour, not an lwIP issue. Of you need datagrams > strictly separated, use UDP. > > > > Regards, > > Simon > > > > _______________________________________________ > > lwip-users mailing list > > lwip-users@nongnu.org > > https://lists.nongnu.org/mailman/listinfo/lwip-users > > > TCP is a streaming protocol this means that packets can be joined > together either at the sender or the receiver. > > UDP will keep the packets separate but sending a 6 byte packet is very > inefficient over Ethernet. > > The minimum Ethernet packet size is 64-bytes, if you are the protocol > owner I would suggest some sort of packet ageration to merge smaller > packets and make for a more efficient transfer over Ethernet. > > > Rod > > > > _______________________________________________ > lwip-users mailing list > lwip-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
