PXE/TFTP (was Re: Bonded head nodes)

[Justin Moore]

> > I recently wrote both a TFTP client and server.  I initially did some
> > research on what already existed, and was surpised at high ratio of talk
> > vs. implementation of multicast TFTP.  "Interoperating with" isn't the
> > same as "currently implements".
> 
> Don,
> 
> Any chance that you could write up a little document about what can be
> done to TFTP clients and servers to make them more reliable? A while ago
> I found out, the hard way, that the standard Linux server and some random
> embedded board's client did not want to work when the server was my laptop
> with a (slow) PCMCIA ethernet card. I've also seen that it's easy for
> a server to get congested enough that clients give up.
> 
> As for multicast TFTP, it's a weird beast -- you have to synchronize
> all your nodes (so much for "ripple booting" to minimize the power
> surge), and if you have packet loss somewhere, it's usually the case
> that everyone gets hurt. Neither of these are optimal things to do.

   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).  The second timeout is inter-packet,
and tells the chip how long to wait between packets before giving up.  I
had tossed around the idea of building a SEDA-driven TFTP server to help
alleviate this problem.

   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.  This would help to limit the problems with 
current TFTP server implementations: clients, once they got through,
would be guaranteed quick and complete service.

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

-jdm

-- 
Department of Computer Science, Duke University, Durham, NC 27708-0129
Email:  justin at cs.duke.edu