While running again a PLC with > 250 reads, we noticed that writes were being sent in parallel with the reads. This caused the buffer returned to _handleDataEvent to contain the response for both the read and write, however the parsing only ever parsed the first response in the header and threw away the other one. This change allows the remainder of the buffer to also be processed.
Aditionally, listeners are removed after failed calls and listeners are guranteed to be attached before the new write command is sent. This avoids possible race conditions in where a message could be recieved on the socket before the listener is set up.
An alternative solution to this would be to group read/write/groups in the same queue instead of individual queues so there is only ever 1 outstanding request.
How Has This Been Tested?
Tested against a PLC with > 250 reads and around 2 writes. When ever the writes would be would be executed, the subsequent read would always fail. I believe you can issue a write and read at the same time to reliably reproduce the error.
Screenshots (if appropriate):
Types of changes
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
Checklist:
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.
[ ] This is a work in progress, and I want some feedback (If yes, please mark it in the title -> e.g. [WIP] Some awesome PR title)
Multi Response (Read/Write) Packets
Description, Motivation, and Context
While running again a PLC with > 250 reads, we noticed that writes were being sent in parallel with the reads. This caused the buffer returned to _handleDataEvent to contain the response for both the read and write, however the parsing only ever parsed the first response in the header and threw away the other one. This change allows the remainder of the buffer to also be processed.
Aditionally, listeners are removed after failed calls and listeners are guranteed to be attached before the new write command is sent. This avoids possible race conditions in where a message could be recieved on the socket before the listener is set up.
An alternative solution to this would be to group read/write/groups in the same queue instead of individual queues so there is only ever 1 outstanding request.
How Has This Been Tested?
Tested against a PLC with > 250 reads and around 2 writes. When ever the writes would be would be executed, the subsequent read would always fail. I believe you can issue a write and read at the same time to reliably reproduce the error.
Screenshots (if appropriate):
Types of changes
Checklist:
[WIP] Some awesome PR title)Related Issue