[ipxe-devel] [External] Re: HTTP Transfer does not timeout when transfer interrupted..

Post, Donald L UTAS Donald.Post at utas.utc.com
Mon Oct 20 14:37:22 UTC 2014


I too am in favor of global setting. I prototype something that I will post later today but basically I created a xfer-idle-timeout setting that you can set in seconds and will then timeout the connection.

Thanks!

-Don

From: ipxe-devel-bounces at ipxe.org [mailto:ipxe-devel-bounces at ipxe.org] On Behalf Of Kevin Landreth
Sent: Monday, October 13, 2014 5:04 PM
To: ipxe-devel at ipxe.org
Subject: [External] Re: [ipxe-devel] HTTP Transfer does not timeout when transfer interrupted..

On Mon, Oct 13, 2014 at 7:51 AM, Christian Hesse <list at eworm.de<mailto:list at eworm.de>> wrote:
Michael Brown <mcb30 at ipxe.org<mailto:mcb30 at ipxe.org>> on Mon, 2014/10/13 13:30:
> On 06/10/14 05:12, Post, Donald L UTAS wrote:
> > In the following case it seems that an HTTP transfer does not time out
> > and basically hangs forever (well a really long time).
> >
> > ·iPXE client is set up to perform for an HTTP of a Linux system.
> >
> > ·The root file system is fairly large and thus takes a bit to down load
> > (say 15 seconds).
> >
> > ·If there is a loss of link during the transfer, the transfer does not
> > timeout but seems to hang
> >
> > ·Even if the cable is reconnected (after a period of time long enough
> > for the TCP connection to have timed out) the transfer does not continue.
> >
> > My questions are:
> >
> > 1.Is this the expected behavior?
> >
> > 2.If not, is there a setting I need to set to enable the timeout and
> > restart of the connection?
>
> The underlying problem is that the TCP connection is stable in this
> situation.  The client has nothing to send, so will not be retrying
> anything and will patiently wait forever until the server sends more data.
>
> There is an overall --timeout option to all of the image-fetching
> commands ("imgfetch", "chain", etc) which allows you to specify a
> timeout for the complete download operation (including DNS lookup, etc).
>   The timeout is an inactivity timeout: if the download fails to make
> forward progress (as defined by a call to job_progress()) within the
> specified time then the download job will be aborted.
>
> For backwards compatiblity, if no timeout is specified then iPXE will
> wait indefinitely.  We could potentially change this: what do people think?
I would vote for a default timeout.

Additionally... Is it possible to set a value that effects following fetch
commands? So instead of

imgfetch --timeout 5000 http://...

use something like

set timeout 5000
imgfetch http://...
--
main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Chris           get my mail address:    */=0;b=c[a++];)
putchar(b-1/(/*               gcc -o sig sig.c && ./sig    */b/42*2-3)*42);}

_______________________________________________
ipxe-devel mailing list
ipxe-devel at lists.ipxe.org<mailto:ipxe-devel at lists.ipxe.org>
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel

I too concur that there should be default timeout.  I would assume something reasonable (10 seconds?) would tell us that the connection/server is too unstable to actually boot from.  I personally would rather get an early failure than a 4 hour boot iPXE imgfetch.

- Kevin Landreth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20141020/a1b59a04/attachment.htm>


More information about the ipxe-devel mailing list