64ko message size limit
steux opened this issue · comments
Hi,
Following your last update to master, I've made a test to test fragmentation, and apparently it works OK now, BUT messages of size > 64ko are still discarded.
To test this, you can use this:
cargo run -- -r foobar to launch a reader
cargo run -- -w foobar -s 65000 works correctly. The reader gets the message.
cargo run -- -w foobar -s 66000 fails. The reader doesn't get any message.
This is probably not directly linked to fragmentation, since fragmentation occurs starting from size 1024, according to tcpdump and the source code :
src/dds/writer.rs:253 : data_max_size_serialized: 1024,
src/dds/writer.rs:414 : let fragmentation_needed = ddsdata.payload_size() > self.data_max_size_serialized;
This is something else. Would you have any idea ?
Best regards.
A good find.
This seems to be caused by retransmits that are made in response to ACKNACK from Reader, in handle_repair_data_send_worker. The problem is that fragmented send is just not implemented there, like it is in process_writer_command.
It may take some time before I can get to fixing this, but you are welcome to submit a PR if you are able to.
OK. What I understand now is that there are actually two bugs:
- The first one is that all fragmented data (whatever the size > 1KB) are rejected (causing NACK).
- The second one is that these fragmented data are re-emitted without fragmentation (causing the 64kb limit issue)
This explains why I never had any debugger entering the processing of fragmented data on the client side AND the timing issues (big delay) while transmitting. It's getting clearer now. I'll go deeper into the code and try if I can find out what actually gets wrong...
Best regards.
B. Steux
Yes, I agree that the second bug is as you describe.
But how does the first one occur?
Hi,
I think I've found why the first one occurs. I've corrected it and sent you a PR. Now packets over 64kb of size are correctly transmitted. Still have to correct the second bug.
Regards. B. Steux