21 Oct
2006
21 Oct
'06
3:54 a.m.
Philip Pemberton wrote:
You send a packet to the broadcast address.
Say your client is 10.0.0.1, and the target device is 10.0.0.2, and
the subnet mask is 255.0.0.0. That means your broadcast address is
10.255.255.255. Sending a packet to the broadcast address means any
device on that subnet will receive the packet. So the target listens
on whatever port it's using, the source machine sends out a broadcast,
and the target responds by sending a unicast packet (e.g. 10.0.0.2 to
10.0.0.1) back to the source to advertise its presence.
As far as protocols go, UDP is nice and simple, but doesn't offer any
form of guarantee that a sent packet will arrive, so you'd probably
need to hack together some form of
send/acknowledge/repeat-if-scrambled/repeat type system.
Keep it simple and open.
Use protocols and code that already exist.
HTTP, FTP, Samba and NFS servers come to mind. Use Linux or some sort
of BSD. All the code is already built in. And yes, you can use DHCP
with those. Reuse some older PC like a P2. Otherwise, you'll spend
lots of time engineering the hardware AND the software. It'll be
difficult enough just to write the software to get it to do the core
task of imaging the disks in the first place. Don't make it more
complex than it has to be.
Don't be afraid of requiring a generic VGA monitor and a normal USB/AT
keyboard for configuration. It greatly simplifies things to have them,
and everyone has them already or they wouldn't be trying to image
floppies in the first place.
If you go with a custom black box design that lacks them, you'll wind up
re-engineering lots and lots of kludges just to hide the fact that this
is a computer. Treat it like a normal computer and slap some easy to
use UI on top of it. Hell, use Firefox and a web server to drive the
software. There are lots of wonderful tiny Linux distros that are well
suited for this sort of thing.
Keeping it as simple as possible and using what's already out there will
save lots of time, effort, and headaches. If you try to invent your own
protocols, you'll be working on the other stuff for half a year and
still not be able to build something that's as robust and as flexible as
reusing existing OS code.