We can, and do, suspend a TFTP transfer simply by delaying the ACK packet as necessary. On September 29, 2015 7:45:27 PM PDT, Patrick Masotta <masottaus at yahoo.com> wrote:>>>> >On 09/26/2015 10:36 AM, Patrick Masotta via Syslinux wrote: >> >> About PXEbc Peter has recently said: >>> The problem with the pxebc is that it only supports one concurrent >TFTP >>> connection, and Syslinux expects to be able to keep multiple files >open >>> at the same time. >>> http://www.syslinux.org/archives/2015-August/024025.html >> >> I wonder why should syslinux.efi ever need to TFTP transfer more than >one file simultaneously? >> > >Consider the case of INCLUDEd configuration files, for example. > > >??? -hpa<<< >I do not understand.Are we parsing a configuration file and potentially >starting new TFTP transfers while downloading it? How can we do this on >a single thread?We cannot stop/resume a TFTP transfer then I cannot >imagine how to detect an INCLUDE during TFTP transfer N to launch TFTP >transfer N+1 if TFTP transfer N is not finished yet, all in a single >thread and with none of the TFTP transfers timing out. > >I might be wrong but I think syslinux TFTP transfers are "atomic" (they >transfer the whole configuration file) later the parsing action on the >received file defines if other/s TFTP+parsing actions are required in >case the INCLUDE command was previously found. If this is correct then >there is never more than one TFTP file transfer at any given time (and >we could use PXEbc). >Please let me know if I'm wrong. Thanks. > >Best,Patrick-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>> >I do not understand.Are we parsing a configuration file and potentially>starting new TFTP transfers while downloading it? How can we do this on >a single thread?We cannot stop/resume a TFTP transfer then I cannot >imagine how to detect an INCLUDE during TFTP transfer N to launch TFTP >transfer N+1 if TFTP transfer N is not finished yet, all in a single >thread and with none of the TFTP transfers timing out. > >I might be wrong but I think syslinux TFTP transfers are "atomic" (they >transfer the whole configuration file) later the parsing action on the >received file defines if other/s TFTP+parsing actions are required in >case the INCLUDE command was previously found. If this is correct then >there is never more than one TFTP file transfer at any given time (and >we could use PXEbc). >Please let me know if I'm wrong. Thanks. > >Best,PatrickWe can, and do, suspend a TFTP transfer simply by delaying the ACK packet as necessary. -hpa <<< I humbly think this is not a good approach. What happens when the transfers are made using i.e. HTTP instead?I see the costs of this strategy without seeing the benefits; was this done to marginally "simplify" thethe required editing/insertion process when the INCLUDE command is found? Do you see anything wrong on the alternative approach that i.e. would loop around "Parsing / Downloading the whole file / Editing" starting with the line "INCLUDE /pxelinux.cfg/default" ? Sorry for bothering you with this; I'd love to avoid the dependency on simultaneous transfers (specially under EFI); please forgive me if I'm wrong. Best,Patrick
I humbly thinks it has worked just fine for 15 years. TCP works the same way, and flow control to the input buffers is an explicit design criterion for both TCP and TFTP. On September 30, 2015 6:27:04 AM PDT, Patrick Masotta <masottaus at yahoo.com> wrote:>>>> >>I do not understand.Are we parsing a configuration file and >potentially>starting new TFTP transfers while downloading it? How can >we do this on >>a single thread?We cannot stop/resume a TFTP transfer then I cannot >>imagine how to detect an INCLUDE during TFTP transfer N to launch TFTP >>transfer N+1 if TFTP transfer N is not finished yet, all in a single >>thread and with none of the TFTP transfers timing out. >> >>I might be wrong but I think syslinux TFTP transfers are "atomic" >(they >>transfer the whole configuration file) later the parsing action on the >>received file defines if other/s TFTP+parsing actions are required in >>case the INCLUDE command was previously found. If this is correct then >>there is never more than one TFTP file transfer at any given time (and >>we could use PXEbc). >>Please let me know if I'm wrong. Thanks. >> >>Best,Patrick >We can, and do, suspend a TFTP transfer simply by delaying the ACK >packet as necessary. >-hpa > ><<< >I humbly think this is not a good approach. What happens when the >transfers are made using i.e. HTTP instead?I see the costs of this >strategy without seeing the benefits; was this done to marginally >"simplify" thethe required editing/insertion process when the INCLUDE >command is found? >Do you see anything wrong on the alternative approach that i.e. would >loop around >"Parsing / Downloading the whole file / Editing" >starting with the line "INCLUDE /pxelinux.cfg/default" ? >Sorry for bothering you with this; I'd love to avoid the dependency on >simultaneous transfers (specially under EFI); >please forgive me if I'm wrong. > >Best,Patrick > > > > > > > > > > >-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
> On September 29, 2015 7:45:27 PM PDT, Patrick Masotta <masottaus at yahoo.com> wrote: >>>>> >>On 09/26/2015 10:36 AM, Patrick Masotta via Syslinux wrote: >>> >>> About PXEbc Peter has recently said: >>>> The problem with the pxebc is that it only supports one concurrent >>TFTP >>>> connection, and Syslinux expects to be able to keep multiple files >>open >>>> at the same time. >>>> http://www.syslinux.org/archives/2015-August/024025.html >>> >>> I wonder why should syslinux.efi ever need to TFTP transfer more than >>one file simultaneously? >>> >> >>Consider the case of INCLUDEd configuration files, for example. >> >> >> -hpa<<< >>I do not understand.Are we parsing a configuration file and potentially >>starting new TFTP transfers while downloading it? How can we do this on >>a single thread?We cannot stop/resume a TFTP transfer then I cannot >>imagine how to detect an INCLUDE during TFTP transfer N to launch TFTP >>transfer N+1 if TFTP transfer N is not finished yet, all in a single >>thread and with none of the TFTP transfers timing out. >> >>I might be wrong but I think syslinux TFTP transfers are "atomic" (they >>transfer the whole configuration file) later the parsing action on the >>received file defines if other/s TFTP+parsing actions are required in >>case the INCLUDE command was previously found. If this is correct then >>there is never more than one TFTP file transfer at any given time (and >>we could use PXEbc). >>Please let me know if I'm wrong. Thanks. >> >>Best,PatrickOn Wed, Sep 30, 2015 at 1:42 AM, H. Peter Anvin <hpa at zytor.com> wrote:> We can, and do, suspend a TFTP transfer simply by delaying the ACK packet as necessary.Observing this behavior appears to be all about buffer sizing. I had a 19 kiB config, first line a SAY, second line an INCLUDE and it loaded 13 data blocks (0-12) before delaying the ACK, loading the next file completely (0-6), and resuming the first with the ACK and loading the remaining blocks (13-15). It still appears to be the same IO rate. Aside from potentially needing smaller buffers for config files before parsing (which seems trivial and unnecessary), what other benefits are there to this strategy? -- -Gene
>>>>>I do not understand.Are we parsing a configuration file and potentially >>starting new TFTP transfers while downloading it? How can we do this on >>a single thread?We cannot stop/resume a TFTP transfer then I cannot >>imagine how to detect an INCLUDE during TFTP transfer N to launch TFTP >>transfer N+1 if TFTP transfer N is not finished yet, all in a single >>thread and with none of the TFTP transfers timing out. >> >>I might be wrong but I think syslinux TFTP transfers are "atomic" (they >>transfer the whole configuration file) later the parsing action on the >>received file defines if other/s TFTP+parsing actions are required in >>case the INCLUDE command was previously found. If this is correct then >>there is never more than one TFTP file transfer at any given time (and >>we could use PXEbc). >>Please let me know if I'm wrong. Thanks. >> >>Best,PatrickOn Wed, Sep 30, 2015 at 1:42 AM, H. Peter Anvin <hpa at zytor.com> wrote:> > We can, and do, suspend a TFTP transfer simply by delaying the ACK packet as necessary.Observing this behavior appears to be all about buffer sizing.? I had a 19 kiB config, first line a SAY, second line an INCLUDE and it loaded 13 data blocks (0-12) before delaying the ACK, loading the next file completely (0-6), and resuming the first with the ACK and loading the remaining blocks (13-15).? It still appears to be the same IO rate. Aside from potentially needing smaller buffers for config files before parsing (which seems trivial and unnecessary), what other benefits are there to this strategy? -- -Gene<<< Considering any editing/buffering benefits are only marginal (AFAIK) there are not benefits with the current approach.On the other hand the list of potential problems includes: 1) We cannot use the ubiquitous EFI PXEbc protocol forcing us to rely on the (not always present) EFI Binding Services. 2) We cannot implement i.e. TFTP windowsize option (RFC 7440)3) Linked timeouts; a timeout situation while downloading a nested file impacts the whole download chain. I wonder how many times this schema was responsible for random non-recoverable TFTP errors while loading conf files (specially on congested networks) leading to client reboot.4) etc. If there is not some hidden constrain (please Peter let us know) we should probably think of replacing this schema. Best,Patrick