search

altugbakan / rs-tftpd

TFTP Server Daemon implemented in Rust
https://crates.io/crates/tftpd
MIT License
51 stars 14 forks source link

Wait 1 millisecond between duplicate packets #7

Closed lupyuen closed 11 months ago

lupyuen commented 11 months ago

Hi: Thanks for adding the option for Duplicate Packets. Based on my testing, we need to insert 1 millisecond delay between the Duplicate Packets. (Should this be another option?)

Without Delay: U-Boot JH7110 boots slower (5.7 Mbps), with 2 TFTP Timeouts

Filename 'initrd'.
Loading: 711.9 KiB/s
Bytes transferred = 8100864 (7b9c00 hex)

With Delay (1 millisecond): U-Boot JH7110 boots faster (8.8 Mbps), with No TFTP Timeouts

Filename 'initrd'.
Loading: 1.1 MiB/s
Bytes transferred = 8100864 (7b9c00 hex)

This was tested on macOS over Wired Ethernet. Thanks :-)

cd ~/rs-tftpd
sudo cargo run -- \
  --duplicate-packets 2 \
  -i 0.0.0.0 \
  -p 69 \
  -d "$HOME/tftproot"
stappersg commented 11 months ago

... is the intended effect putting the delay only between the packets, or before each packet?

That question trigger this question:

What if a duplicated packet is actual a delayed packet?

Longer version:

What if a duplicated packet transmitted by TFTP server is for the TFTP client a packet is could catch on time?

Anyway: I suggest that in addition to "--delay-time-between-duplicates" for an option like "--delayed-response-time". That option is indepented from --duplicate_packets. What it does is give a TFTP client time to get ready to recieve packet after it did request for a packet. ( I imagine an immature network driver available in the U-BOOT environment. )

Groeten Geert Stappers -- Silence is hard to parse

stappersg commented 11 months ago

Edits (sorry the previous hasty version)

On Sun, Oct 08, 2023 at 07:11:25AM -0700, Geert Stappers wrote:

That question trigger this question:

That question did trigger this question:

What if a duplicated packet is actual a delayed packet?

Longer version:

What if a duplicated packet transmitted by TFTP server is for the TFTP client a packet is could catch on time?

What if a duplicated packet transmitted by the TFTP server is for the TFTP client a packet it could catch on time?

Anyway: I suggest that in addition to "--delay-time-between-duplicates" for an option like "--delayed-response-time". That option is indepented from --duplicate_packets. What it does is give a TFTP client time to get ready to recieve packet after it did request for a packet. ( I imagine an immature network driver available in the U-BOOT environment. )

Groeten Geert Stappers -- Silence is hard to parse

lupyuen commented 11 months ago

Hi @stappersg: I hope I understood your question correctly, suppose our tftpd sends this sequence of packets to the client:

  1. Original Packet #1
  2. Delay 1 millisecond
  3. Duplicate Packet #1
  4. Original Packet #2
  5. Delay 1 millisecond
  6. Duplicate Packet #2

Our question: If the client correctly receives Original Packet #1, will it handle Duplicate Packet #1 correctly?

Yes the TFTP Client should drop Duplicate Packet #1, because the Block Number is encoded inside the packet. We see this behaviour in curl:

$ curl -v --output initrd tftp://192.168.31.10/initrd
* Received last DATA packet block 1 again.
* Received last DATA packet block 2 again.

(Source)

Apparently U-Boot will drop Duplicate Packets too, because otherwise our Kernel Image would have been corrupted over TFTP and our device will fail to boot. (So far I haven't seen any boot failures due to corrupted Kernel Image)

Which leads to another question: Why don't we throttle the Original Packets and omit the Duplicate Packets?

  1. Original Packet #1
  2. Delay 2 milliseconds
  3. Original Packet #2
  4. Delay 2 milliseconds

We tried throttling tftpd to do the above, but it doesn't fix the TFTP Timeouts. (Details here)

So I agree with you, there seems to be a problem with the Network Drivers in some ports of U-Boot. (Maybe it's not responding to I/O Interrupts quick enough? Or it has run out of Network Buffers?)

stappersg commented 11 months ago

On Sun, Oct 08, 2023 at 11:12:02PM -0700, Lup Yuen Lee wrote:

Stappers

What if a duplicated packet transmitted by the TFTP server is for the TFTP client a packet it could catch on time? ....

  1. Original Packet #1
  2. Delay 2 milliseconds
  3. Original Packet #2
  4. Delay 2 milliseconds

We tried throttling tftpd to do the above, but it doesn't fix the TFTP Timeouts. (Details here)

So I agree with you, there seems to be a problem with the Network Drivers in some ports of U-Boot. (Maybe it's not responding to I/O Interrupts quick enough? Or it has run out of Network Buffers?)

What I think what could work

  1. client sends request for packet #1

  2. server gets request for packet #1

  3. server waits (meanwhile client switches to recieve mode)

  4. server sends packet #1

  5. client processes packet #1

  6. client sends request for packet #2

  7. server gets request for packet #2

  8. server waits (meanwhile client switches to recieve mode)

  9. server sends packet #2

  10. client processes packet #2

Who it is made working with "duplicates":

  1. client sends request for packet #1

  2. server gets request for packet #1

  3. server sends packet #1 (meanwhile client switches to recieve mode)

  4. server sends duplicate of packet #1

  5. client processes packet #1

  6. client sends request for packet #2

  7. server gets request for packet #2

  8. server sends packet #2 (meanwhile client switches to recieve mode)

  9. server sends duplicate of packet #2

  10. client processes packet #2

Answer of problem might be finding out time for steps 03 and 08.

Groeten Geert Stappers -- Silence is hard to parse