PXE/TFTP (was Re: Bonded head nodes)

[Donald Becker]

On 8 Nov 2002, Justin Moore wrote:
>    During my fiddling with PXE/TFTP, I've discovered that PXE chips
> usually has two internal timeouts.  The first timeout is for the first
> packet to come back from the TFTP server, and is usually relatively high
> (on the order of several seconds).

That timeout is not configurable in any way.
The RFP doesn't even provide a suggestion.

> The second timeout is inter-packet, and tells the chip how long to
> wait between packets before giving up.

This is the parameter that can be changed with the "timeout" option.
But of course if the client is clever enough to implement it, it could
also implement a not-as-stupid dynamic fall-back.
  "The server typically responds in 2msec, but it's been 20msec."
  "I've been missing a bunch of packets.  I'll give the server some
     extra time before giving up."

But does this happen...nooooo.

>    SEDA is a Staged, Event-Driven Architecture (by Matt Welsh), at
> http://www.cs.berkeley.edu/~mdw/proj/sandstorm/
> 
>    The basic idea is behind my SEDA-TFTP is that there are two queues,
> one for incoming connections, and one for current connections.  The TFTP
> server only services a set number of connections, and will hold off
> sending the first packet to a new connection until it has completed one
> of the old connections.

Good idea -- I didn't know about Matt's PhD project.  A complexity is
that you cannot hold off making the TFTP connection for too long.  If a
PXE client times out on the request it usually does Something Pointless,
like giving up and not rebooting.

> This would help to limit the problems with 
> current TFTP server implementations: clients, once they got through,
> would be guaranteed quick and complete service.

A better approach is detecting overload and round-robin servicing the
clients.  But I haven't figured out what "detecting overload" means,
especially when there are no RFC-suggested timeout values.

Hmmm, but SEDA could play a role here: if your round-robin gets close to
the per-packet timeout, you want to give up on new connections.

There is also the issue of monotonic progress: if you start losing clients
to timeouts, you might want to throw away fairness to make certain that
some clients succeed, while letting others stay just under the timeout
limit. 

>    If no one else writes such a beast (*nudge**nudge*) I plan to, but
> only in my Copious Free Time. :)

Great!
But there is a very low reward.
Even around here I get "why write another TFTP program?"
These things often take more time than you expect.  Writing a simple
server is simple.  Creating a test setup that causes failures in way
that you can figure out what went wrong is Really Very Difficult. 

-- 
Donald Becker				becker at scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Scyld Beowulf cluster system
Annapolis MD 21403			410-990-9993