This project has moved and is read-only. For the latest updates, please go here.

Elegant in its simplicity

Nov 30, 2015 at 8:52 PM
Thanks for publishing, much appreciated!

On an aside, should you decide to extend this library in the future, I would consider implementing a safe path to disposing the server. As it stands, I occasionally hit race conditions when a user stops the server fractions of a second after a new client connection is initiated, which 'bricks' the the client device, which in my case is hardware trying to download a new firmware version.

Again, thanks for a great piece of work

SLR-
Dec 30, 2015 at 11:03 AM
Hi SLR,

thanks for your feedback! I'd happily include that safe path. However, I am not sure if I grasp the problem yet.
Basically, I believe you can Stop the server (and all transfers) at any time and it should be fine - at least tftp-protocol wise.

Do you want to wait for all transfers to finish before shutting down the server?

Best regards, Callisto
Dec 30, 2015 at 11:53 PM
Hey Callisto,

Thanks for the response! My use case involves a tftp client in the bootloader of a particular hardware device. In the case of this device, the bootloader upgrades the devices firmware over tftp. This operation is not buffered, but written 'in place'; that is to say, as soon as a block is returned from the tftp server it is written over the first block of the existing firmware image. The edge case I hit is that a user closes the tftp server just as a client connects and starts being served blocks. The server stops cleanly, and the client honors the protocol and continues to ask for the next block, indefinitely. But in the end, the device is bricked, due to a corrupt firmware image.

Waiting for all transfers to complete would likely solve the case I described. Maybe stop servicing new client requests and complete any current transfers?
Im not sure I articulated that well. Did that make any sense at all? :/

SLR-