EmbeddedRPC
FramedTransport::Header not serialized?!
Why is not the erpc header (FramedTransport::Header) serialized? E.g. do htons on the 16 bit members m_messageSize and m_crc.
I experienced problems due to lack of serialized header, and added some code to framed transport class to serialize header. I can share the code on request.
Maybe you can raise a PR so that it can be included in master branch of erpc? I don't want to maintain a fix on my own.
Hi, Could you explain why you need serialize framedTransport header? Currently it is send to other side before serialized message as it contains extra data in compare with other possible transports.
Hi @Hadatko , using the term serialize may be wrong here. Sometimes the transferred header may be corrupted due to lack of frame and CRC. So I have to add an extra frame and CRC to check header integrity into header.
So the issue is related to sending receiving message size. As second receive call is using size from first call. Sounds reasonable to me to have crc of header.
Yes, it is related to message size. The second side wait for message with incorrect size. So the transfer is aborted if there is a timeout for the transfer. In our particular situation, the content of message were coded as ASCII and added framing characters. May be the measures other than CRC are not needed.
@Hadatko Why is it not needed to serialize and deserialize header? Representing header in network byte order would be the only way to let little-endian and big-endian exchange header before receiving the payload.
So we have two issues here. Serializing header and validate header. If you can create PR for both of them it should be great ;) Thank you guys.
Didn't it solved enough at #276 ? If someone want he can use htons as implementation of the endiannes agnostic defines. Maybe we can consider add such implementation.
https://github.com/EmbeddedRPC/erpc/blob/b3951d834d446b87e6e9a3b47dca71c36f5b37cf/erpc_c/infra/erpc_framed_transport.cpp#L128
@amgross :D That is crc of next message (serialized data). But there is no check if sended header data are correct. From what i understand here we need add crcHeader into Header struct. This one will be computed from header crc and length. Other side then need firstly check header crc and then receive body and check body crc. This way you know that length and crc in header struct was received correctly
The first message here talked about 'E.g. do htons on the 16 bit members m_messageSize and m_crc', so I thought we are talking on endianness issue
I think @infn-ke (which opened the issue) talked here on endianness and @ierturk talked about length issue (which I also faced once)