cURL / Mailing Lists / curl-users / Single Mail

curl-users

Re: Timeout Behavior for Curl TFTP

From: Chad Monroe <cmonroe_at_occamnetworks.com>
Date: Tue, 6 Jan 2009 11:46:55 -0800

On Jan 6, 2009, at 8:55 AM, Grant Erickson wrote:

> On 1/5/09 2:07 PM, Daniel Stenberg wrote:
>> On Mon, 5 Jan 2009, Grant Erickson wrote:
>>> I have noticed for TFTP that the connect-timeout, max-time and
>>> limit-rate
>>> options do not work as expected. Conducting the following on the
>>> host and
>>> target systems.
>>
>> [...]
>>
>>> Is this "as-designed" behavior for TFTP or is this in error and in
>>> need of a
>>> fix-up? For HTTP, these options behave correctly (or at least as I
>>> expect
>>> they would).
>>
>> I can't see any reasonable explanation to why it would work like
>> this. I think
>> these are plain bugs, and I think they are present primarily due to
>> two
>> reasons: TFTP is UDP and not a lot other stuff in libcurl is, and
>> the transfer
>> loop for TFTP is made outside of the regular transfer loop so it
>> has its own
>> set of flaws/logic.
>>
>> Hopefully Chad Monroe's work will adjust both areas, but I'm sure
>> your added
>> work and input will be useful as well!
>>
>>> While TFTP is not a connection-oriented (i.e. TCP) implementation
>>> making the
>>> connect-timeout option somewhat ambiguous, my expectation is that
>>> connect-timeout option would control the first sendto/recvfrom to/
>>> from the
>>> server and max-time would control the entire transaction. If there's
>>> agreement, I'll proceed with a patch.
>>
>> That sounds entirely reasonable to me. I think that the
>> documentation for the
>> connect time-out should get that little clarfication added once
>> this ges
>> fixed, as a connect time-out is indeed a weird concept for UDP.
>
> Chad:
>
> Any updates on where you're at with your changes? I'd like to
> coordinate my
> efforts with yours and avoid any unnecessary duplication of effort.
>
> Regards,
>
> Grant

Hi Grant,

When I started testing TFTP I ran into these issues as well. Here's my
current plan of action (due to other projects requiring my attention):

TFTP option negotiation: I have submitted a patch and received a
response. I plan to make the requested changes and re-submit probably
today.
Supporting asynchronous transfers using the multi interface: I plan to
start this around the beginning of next week.

Based on your comments above, I did in fact modify the sendto/recvfrom
lines for the option negotiation patch, but that's the only thing I
could think of that may conflict. I'll try my best to re-submit that
patch later this afternoon. At this point, I wouldn't worry about the
multi interface patch, this may take me a while and I have not started
yet.

--
Chad Monroe
-------------------------------------------------------------------
List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Received on 2009-01-06