When pb_next_action() is processing a file broadcast or file fill request then it calls pb_broadcast_next_file_chunk() to send the data. That returns the number of bytes that were sent or 0 if there is an error. If zero is returned then it is considered a fatal error and the request is removed. This stops us getting stuck in a loop where we keep sending zero bytes.
However, we have the case where the file and request is fine but the TX Queue is full. In that case we curiously return TRUE, i.e. 1. That is a bug. It will advance the file pointer by 1 byte. Instead we want an error code that simply skips this attempt to add a packet to the queue. It will try again next time pb_next_action() looks at the stations request.
Right now we have the queues very small (5 frames). We may be able to make these much larger in flight. For now it is good to keep them tight for testing.
When pb_next_action() is processing a file broadcast or file fill request then it calls pb_broadcast_next_file_chunk() to send the data. That returns the number of bytes that were sent or 0 if there is an error. If zero is returned then it is considered a fatal error and the request is removed. This stops us getting stuck in a loop where we keep sending zero bytes.
However, we have the case where the file and request is fine but the TX Queue is full. In that case we curiously return TRUE, i.e. 1. That is a bug. It will advance the file pointer by 1 byte. Instead we want an error code that simply skips this attempt to add a packet to the queue. It will try again next time pb_next_action() looks at the stations request.
Right now we have the queues very small (5 frames). We may be able to make these much larger in flight. For now it is good to keep them tight for testing.