20 Oct
2006
20 Oct
'06
12:56 p.m.
Doc Shipley wrote:
cclist at sydex.com wrote:
Hmmm, I wouldn't think that the device being the client and the 'attached'
computer being the server is a good idea; given that we'd likely want to
support more than one OS, it opens up problems of file naming and the like
(which aren't an issue the other way around, as it's the OS-specific bit of
software running on the attached machine which prompts the user for a filename)
Some sort of server on the device *might* be an option depending on
architecture and what tools are out there; HTTP and FTP protocols aren't
rocket science.
Personally I'd like to treat this as though a single attached computer talks
to a single 'remote floppy' device for the purpose of transferring a single
disk image only at this stage - just to keep things as simple as possible and
hopefully speed up development times. Later on there might be scope for having
the device able to store more than one image at once or other fun things...
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. 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.
Yep. I am concerned that OS support for sending raw Ethernet packets from any
kind of user-space app just isn't there in most modern OSes, though. I really
think it'd have to be IP-based to make the 'client' software do-able (and to
prevent problems with any intermediate network devices), even if that means
more complexity at the device end.
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.
If the device is the 'server', what's to set up? Plug it in, give it an IP
address (method to be determined), fire up the client software and talk to it.
4) Same concept concerning host platforms. I vote for
$FreeOS as the
initial supporting platform, but if DOS works better, so be it.
I'm of the same mind there. I expect nearly everyone who will want this can
easily rustle up a DOS / Unix / OSX / whatever system, but Windows is more
problematic for some of us.
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.
That was the reason for my question about DHCP; I've almost exclusively used
static IP addresses for anything I've ever set up (mainly because most of the
time they've been servers), so my knowledge of DHCP is lacking.
I can't think of an easy way of doing that initial device configuration in an
Ethernet world, though; DIP switches and the like requires a lot of them, but
any other configuration seems to require some other form of interface to 'kick
start' the initial config.
6) Git 'er dun.
For sure...
I'd love for someone to Just Do This. Providing it's cheap I don't really mind
how it's implemented either; I'd rather have something than nothing. What I
don't want to do is pay 'too much' for something that doesn't do
what's needed
though, or is completely inflexible.
It's probably worth exploring ideas for a couple of weeks, though, just to
see what comes of it. After that, hopefully someone can just get on with it :)
--
If you've ever wondered how you get triangles from a cow
You need buttermilk and cheese, and an equilateral chainsaw