20 Oct
2006
20 Oct
'06
11:52 a.m.
cclist at sydex.com wrote:
I *like* the idea of ethernet myself. Hardly
anything, save for some very vintage gear that
doesn't understand it. I wonder if you could use one of the standard services, such
as ftp, to
nearly avoid having to write anything for the host system...
Hrrm. TFTP would be a natural for this, at least if you limit the
host to Unix/Linux systems. I have no idea how you'd fare for a TFTP
daemon in WinWorld.
Normally TFTP services are read-only or allow only modification to
existing files, but the daemon can be told to allow file creation. The
client code - appliance end - is necessarily tiny, it's lightweight, and
most current clients and daemons support RFC1783 negotiation for
large-file transfers. The appliance could then boot from the host, too,
but that seems like overkill to me.
I have a couple of thoughts to offer about this basic concept.
1) I like the idea of using something like ARM processors With
everything built into the chip, you'd not only get a much smaller
component count, but it seems to me that most of the layout and basic
code would likely be already out there. All that spells a lower
long-run cost in general, and more universal accessibility.
2) RS232/RS422 serial is getting harder to support, and will continue to
get worse. USB is simply not an option for some of us. Anyone with a
PDP-11 or a C64 can support an ethernet connection, and almost (?)
everything needed for implementation for both host and appliance is
already there. Plus, the standards for ethernet transactions are not as
"widely interpreted" as those for USB or serial.
3) It might be well to stipulate and design this as a tool for advanced
users only, at least to start. I'd happily settle for something simple
and raw with 8 pages of install instructions. As an example of what I
mean and why, if TFTP is used, having that set up by hand makes it more
likely that the user understands the security implications and will
handle that.
4) Same concept concerning host platforms. I vote for $FreeOS as the
initial supporting platform, but if DOS works better, so be it. Get it
out the door and running, and somebody else will write support for the
other platforms.
5) For anyone not a network geek, DHCP is a right pain to manage, as is
broadcast TFTP. Again as a short-term implementation, how about
stipulating a dedicated interface, with the IP preprogrammed and
programmable? If can't leave it dedicated, I could set the host IP to
talk to the appliance and reprogram the appliance IP and TFTP target to
match my subnet. That should actually reduce the amount of setup on the
host side.
6) Git 'er dun. I'd like to point at The Great Universal Archive Format
Project of a couple of years ago. Trying to anticipate and solve every
possible permutation killed that deader than hell. Design in some room
to grow, cover the basic common disk formats, and expect v1.0 to suck.
I don't have any design skills to offer, but I'd throw some dollars
in the pot and such free time as I have for testing. This is a tool
that I'd very much like to have.
Doc