Fix flow of ACKs to ensure we do not hang on final buf write #155
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Using Windows 10 and a pyboard, often times a file transfer hangs and the only solution is to unplug the board and kill
rshell
. I observe this behaviour with 9 out of 10 larger file transfers (4KiB). Smaller transfers do not seem affected.I'm not familiar enough with the specific mechanism of file transfer to describe the root cause here, but this behaviour appears to happen when
send_file_to_remote
has returned (no more data to send), butrecv_file_from_remote
is still executing, causingDevice.remote("recv_file_from_host", "send_file_to_remote" .. )
to hang indefinitely. Presumablyrecv
is waiting for more data that is never coming?It seems the current code would never send/receive the final packet's ack, as they are processed at the start of the
while
loop. It is therefore possible for a last-packet timeout to go unnoticed byrshell
. By ensuring acks are only sent after the remote has received and written the packet, and subsequently verified after local has sent a full packet to the remote we can make this more robust. This resolves my file transfer issues.