I think the message decoding in MessageControl#data is fault-intolerance or a bug.

[duzen]

So why is it so designed.

[Terry Packer]

@duzean we will need a lot more information to help you out. Please provide an example of your problem so we can reproduce it and test.

[duzen]

@terrypacker Sorry for my sentence.I implement my InputStreamEPollWrapper for RtuMaster, and the actual slave sometimes return some bad bytes not suit modbus protocol. I assume the message decoder is fault-tolerance in this situation.But when a bad response is appear, the MessageControl#data is never work right again.

[duzen]

But when I filter the bad bytes that not suit for modbus protocol, everything is ok. So I assume it is a bug.

[duzen]

@terrypacker Because when a bad response appear, it is go wrong, even though every continue response is right. Do you need some actual response bytes?

[Terry Packer]

@duzean it would help to see the message that is causing the failure. That way I can write a test to replicate it exactly. Thanks.

[duzen]

Here is the request and response, hope that helps.
send: 04040014000CB05E
recv: 040418000403E7004D004F000000000000FA2A000003441CA205152AAB
send: 0404004F0006418A
recv: 04040C00160022002F00BC00C8004BD48D
send: 04040014000CB05E
recv: 04 // after this point every read action throw ModbusTransportException but the slave give right response
send: 04040014000CB05E
recv: 040418000403E700510053000000000000FA2A000003441CA2051535FF
send: 04040014000CB05E
recv: 040418000403E700510052000000000000FA2B000003441CA10514583F
send: 04040014000CB05E
recv: 040418000403E700500052000000000000FA2B000003441CA1051465C3

[duzen]

@terrypacker I think when checkCRC failure or get a wrong functionCode, it is necessary reset the mark and skip one byte for another parse. And before send request, clear the dataBuffer.