From the logs, it looks like the client is sending the file in blocks of 256 bytes. It seems that in between download blocks, after receiving a download request and before sending a download response, there is a delay in the response, up to a few seconds. In this case, the client should update its beacon state to "Busy", instead of "Transport", to let the host know that it is processing the request. Otherwise, the host will continue to increase a "timeout", that after enough blocks, makes your download fail. Furthermore, this causes more issues when the host retries the request when the client is about to respond. One example of this is at time 123.672 on the Device0.txt log.
In short, if you are unable to respond to a download request right away (e.g. because you need to fetch data from the file system), set the beacon state to busy, so the host knows that the client did receive the request and is working on it.
