It does too much things. Currently, it does the following:
Act as a funnel, taking multiple requests and sending them one by one (or a few at a time, see #3)
Builds the MBAP message (includes buffer creation and writing the message using MbapMessage::build_message).
Handle sending the received data to the parser and reseting it when something goes wrong.
Handle timer management for the request that was sent.
Handle transaction id increment (although this is a small responsibility).
The copying of IRequest in ChannelTcp::send_request is horrible. The temporary shared_ptr to pass it to the lambda feels wrong.
The behaviour of the object after it was shutdown is undefined. I think it can revive the connection even if the asio threads are joined. I also think this issue affects opendnp3 btw.
A first avenue would be to separate the funneling from the message build/parser submission. It would clarify the code (I hope...)
There are multiple issues to me in this class:
MbapMessage::build_message
).IRequest
inChannelTcp::send_request
is horrible. The temporaryshared_ptr
to pass it to the lambda feels wrong.A first avenue would be to separate the funneling from the message build/parser submission. It would clarify the code (I hope...)