Mailing List Archive

omri wrote:
> I had a feature suggestion in mind.

This is a frequently suggested feature, but it's technologically tricky.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

On 6/6/07, H. Peter Anvin <hpa@zytor.com> wrote:
> This is a frequently suggested feature, but it's technologically tricky.

Can you explain some more? I was thinking about writing a simple tftpd
to do this. Why is this tricky?

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Check the mailing lists, I believe it's been explained already, however
it comes down to if the cgi program on the tftp server takes too long to
execute the client side will timeout and you'll be dead in the water.
What would need to be done is some sort of transfer that would cause
something akin to a keep alive that would inform the client to stall and
then retry.

- John

On Thu, 2007-06-07 at 01:44 +0300, omri wrote:
> On 6/6/07, H. Peter Anvin <hpa@zytor.com> wrote:
> > This is a frequently suggested feature, but it's technologically tricky.
>
> Can you explain some more? I was thinking about writing a simple tftpd
> to do this. Why is this tricky?
>
> _______________________________________________
> SYSLINUX mailing list
> Submissions to SYSLINUX@zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

On 6/7/07, J.H. <warthog19@eaglescrag.net> wrote:
> Check the mailing lists, I believe it's been explained already, however
> it comes down to if the cgi program on the tftp server takes too long to
> execute the client side will timeout and you'll be dead in the water.
> What would need to be done is some sort of transfer that would cause
> something akin to a keep alive that would inform the client to stall and
> then retry.
>
> - John

I'm not fimilar with the tftp protocol, all I know is that it uses UDP.
Maybe there's a checksum attached to each packet being sent?
how about sending a packet with the wrong checksum or something similar
that would cause the client to wait for the packet to be re-sent or just request
the file again?...

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

omri wrote:
> On 6/6/07, H. Peter Anvin <hpa@zytor.com> wrote:
>> This is a frequently suggested feature, but it's technologically tricky.
>
> Can you explain some more? I was thinking about writing a simple tftpd
> to do this. Why is this tricky?
>

Because the TFTP protocol doesn't guarantee that you can distingush
between an incoming request and a retransmission of an old request.
There is no way to tell the other end to wait (I have sketched on a
protocol extension to do that.) The end result is that you can get a
load storm on the server, especially since a lot of TFTP clients don't
properly implement backoff.

Additionally, some TFTP clients -- including virtually all PXE clients
-- do multiple transfers and get unhappy if they get different results
(plus the additional server load.)

One suggestion on this mailing list was to restrict the generator in
such a way that each query has to be idempotent (same input -> same
output.) That would allow the query results to be cached, and therefore
avoid the load storm problem (you would not spawn a second generator for
the same contents, but just hold the request.)

I have somewhere on my list to implement that, but tftp-hpa is a bad
codebase for it, so I'm planning to do it as a ground-up rewrite using
modern Unix features, unlike tftp-hpa which is intended to run on
anything vaguely Unix in order to increase the least common denominator.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

I asked the same question a while back. :)

hpa's response;

http://syslinux.zytor.com/archives/2007-March/008233.html

Read the rest of the thread, there is some good discussion.

One possible workaround was to use a dynamic filesystem such as FUSE.
Unfortunately, that is more involved than I want right now. I have done
an "out of band" system where the files are created by another process.
Not truly dynamic, but it works for my specific application.... at
least, for now.

I too would love to see dynamic tftp content, but I appreciate the
technical difficulties.


omri wrote:
> On 6/6/07, H. Peter Anvin <hpa@zytor.com> wrote:
>> This is a frequently suggested feature, but it's technologically tricky.
>
> Can you explain some more? I was thinking about writing a simple tftpd
> to do this. Why is this tricky?
>
> _______________________________________________
> SYSLINUX mailing list
> Submissions to SYSLINUX@zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>
>
>

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

I asked the same question a while back. :)

hpa's response;

http://syslinux.zytor.com/archives/2007-March/008233.html

Read the rest of the thread, there is some good discussion.

One possible workaround was to use a dynamic filesystem such as FUSE.
Unfortunately, that is more involved than I want right now. I have done
an "out of band" system where the files are created by another process.
Not truly dynamic, but it works for my specific application.... at
least, for now.

I too would love to see dynamic tftp content, but I appreciate the
technical difficulties.


omri wrote:
> On 6/6/07, H. Peter Anvin <hpa@zytor.com> wrote:
>> This is a frequently suggested feature, but it's technologically tricky.
>
> Can you explain some more? I was thinking about writing a simple tftpd
> to do this. Why is this tricky?
>
> _______________________________________________
> SYSLINUX mailing list
> Submissions to SYSLINUX@zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>
>
>

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

omri wrote:
>
> I'm not fimilar with the tftp protocol, all I know is that it uses UDP.
> Maybe there's a checksum attached to each packet being sent?
> how about sending a packet with the wrong checksum or something similar
> that would cause the client to wait for the packet to be re-sent or just request
> the file again?...
>

The file gets requested again, and again, and again. If you spawn a
process on the server each time, you will have catastrophic overload.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

On 6/7/07, H. Peter Anvin <hpa@zytor.com> wrote:
> The file gets requested again, and again, and again. If you spawn a
> process on the server each time, you will have catastrophic overload.

Well, the server could ignore the requests from the same client for
the same file untill the execution is done. Once it's done. it'll be
delivered to the next request (or to the current active one).

One more thing, isn't the boot.txt file being requested by pxelinux?
doesn't that mean that the tftp client implementation is yours (or you
have the source for it)?
If you do, can't you make pxelinux wait enough for the file to be
generated and deliverer?

Another idea is to implement another protocol (http perhaps?), but I
guess that's too much hassle.

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

omri wrote:
> On 6/7/07, H. Peter Anvin <hpa@zytor.com> wrote:
>
>> The file gets requested again, and again, and again. If you spawn a
>> process on the server each time, you will have catastrophic overload.
>>
>
> Well, the server could ignore the requests from the same client for
> the same file untill the execution is done. Once it's done. it'll be
> delivered to the next request (or to the current active one).
>
> One more thing, isn't the boot.txt file being requested by pxelinux?
> doesn't that mean that the tftp client implementation is yours (or you
> have the source for it)?
> If you do, can't you make pxelinux wait enough for the file to be
> generated and deliverer?
>
> Another idea is to implement another protocol (http perhaps?), but I
> guess that's too much hassle.
>

http://wiki.freebsd.org/http_support_for_PXE

Possibly unrelated, but possibly worth keeping an eye on as well.

-A

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.