Does this library support streaming / window?

[isaiahtaylor]

Does this library support the ability to negotiate a window for UDP streaming (ignoring acks)?

[mpetazzoni]

Hmm, I'm not sure what you mean. To my knowledge there is no windowing mechanism in UDP. But to be honest that's not something I've looked at in a very long time. Could you elaborate on what you're looking for?

[isaiahtaylor]

@mpetazzoni thank you for the quick response.

There are some specifications of TFTP that allow for streaming; the server that replies with a file will simply stream the file, sending data packets without waiting for ACKs. However, so that the client doesn't get overloaded, there is a protocol to negotiate a window of time where a certain amount of packets may be received. See this: https://www.compuphase.com/tftp.htm and search on the page for the header "Unreliable data streaming"

[isaiahtaylor]

The question is whether anything like that is implemented in either the server or the client.

[isaiahtaylor]

See this RFC specification, https://tools.ietf.org/rfc/rfc7440.txt, and which depends on the option extension: https://tools.ietf.org/html/rfc2347

[mpetazzoni]

Interesting! Looks like that RFC is more recent than ptftpd, which probably explains why I didn't look at it when I initially worked on this project 😄

One of the design principles of ptftpd is support all the TFTP-related standards (and to follow the RFCs very precisely), and to do so in a clean, well-documented way in the code. Sadly I don't think I would have time to work on it these days, but if you're interested in implementing support for it, I'd welcome the contribution!

[mpetazzoni]

(I may also get bored on day on a flight and decide to do it, but it's hard to say when that would be -- maybe in a couple of months?)

[mpetazzoni]

Hey @iptaylortechnical, I've implemented support for RFC7440. It's available in master, and I'm also about to push version 1.3 to PyPI. Let me know if you get a chance to test it!

[isaiahtaylor]

@mpetazzoni wow! Thank you so much! I really appreciate this work! I will take a look at the code and PR any improvements I can find.

[mpetazzoni]

My only gripe with it is that it probably no longer works on Windows now because the server needs to identify the maximum UDP datagram size via sysctl to confirm that the requested blocksize and windowsize will fit in the UDP send buffer, and potentially adjust the windowsize accordingly to fit.

I haven't found a good way to determine this programmatically, so if you have any ideas, I'm all ears!

[isaiahtaylor]

@mpetazzoni I will give that some thought.

A quick question: is there a reason that you use datetime.today() to take timestamps rather than time.time()? The reason I'm asking is that the system I'm on may not have access to the datetime object but will have access to the time object. Is that a vital difference? The only instances I see in the code use it as a timestamp only for measuring a time 1 and time 2. Is that accurate, and would it be an issue if I had to modify it straight across to time.time()?

Related, would a PR for that be appreciated? Guessing not as it works as is. It is interesting to note, however, that datetime.today() is equivalent to date.fromtimestamp(time.time()) as shown here. So basically just wrapping time.time() as something human readable. If I'm not mistaken, the wrapping could just be removed.

Let me know whether I've understood the purpose, and whether a PR would be helpful.

[mpetazzoni]

Yup, I wrote this a long time ago when I was not nearly as good in Python (it was a good learning exercise!). time.time() will work just as well, feel free to send a PR.

[isaiahtaylor]

@mpetazzoni as for the Windows datagram size, it seems windows has the upper bound of 65507 bytes for a datagram packet. That of course says nothing about what the network can handle. But you could just hardcode that in case of a windows system.