Re: network booting

On Jan 15, 8:57 pm, ol...@xxxxxx (Oliver Schmidt) wrote:
Hi,

I see. So the client would need to tell on which offset into on of the
images it wants to read/write. This is however - as you surely noticed
yourself - the basic functionality of a network file system, isn't it?

Not exactly - in a network file system, all the knowledge about what
"blocks" (or sectors) make up a file exist in
the server. The client asks the server to open a specific file (by
name) and then to move around inside that file.

Doing that would actually require much more extensive changes on the
client side.i.e. it would essentially mean replacing the File Manager
component of DOS 3.3, as well as RWTS. What I propose is to have the
knowledge of what blocks make up a file (and what block contains VTOC
or equivalent) stay in the client, but just redirect requests for a
particular block to go over the network, not to the disk controller
card.

Having said that, for the C64 it's a slightly more complex, since in
the CBM protocol, the DOS resides inside the disk drive itself, and
code on the C64 can send commands (using a serial protocol called IEC)
to the drive at either the track/sector level OR the file level. So I
will need to have an additional layer (specific for the C64) that
takes an IEC request over UDP and passes it through to the block
device layer. I already have ruby code for interpreting the CBM DOS
file system, so shouldn't be too big a deal - although I don't intend
to support the IEC commands that let 6502 code be executed directly
inside the disk drive :-)


Most probably you've done that already but I've been looking around a
bit and found that NFSv2 is relatively simple and typically runs over
UDP:http://www.ietf.org/rfc/rfc1094.txt


I did look at NFS but ruled it out since I want something that works
at the block level not the file level.

Some of the other things I looked at before deciding to try my hand at
a new protocol was:

* "network block protocol" http://www.linuxjournal.com/article/3778 -
which is almost exactly what I want, except it's TCP not UDP and I
also needed to have an extension to query a server for the list of
volumes that it hosts.

* ADT's protocol - but it seems restricted to 35 track, 16 sector
images, there's no support for negotiating the number of tracks/
sectors. There is a facility to query the volumes on a host, but even
there I want to extend that, so in the query I can ask for "show me
only A2 images that are ProDos", also as well as the name, I want the
response to include the file system and size.

* something by sun called 'ND' that was apparantly a precursor to NFS
that operated at the block level, not file level, but apparant from
there being no docs around other than some source code, it was layered
directly on IP, hence would have been difficult to implement a cross-
platform server, since you'd need kernel level mods to extend the IP
stack.

* ATA over Ethernet - similar issues to ND - since layered directly on
etherent, not UDP, difficult to write a userland server.

ISCSI - TCP, plus too heavyweight.

Nevertheless I imagine that you're more into a specific solution. Do
you plan to be protocol compatible with the Final Replay network drive
server?:http://www.oxyron.de/html/netdrive01src.zip

I considered that as well, but from scratching around in the source
code (since there wasn't anything that described the protocol
specifically) it seems to be at the IEC/file level - so I will have
another look at it when I'm ready to do that layer.


I see. If you design your protocol on the level of standard 16-sector
sectors of 256 bytes, than it should be easy to be compatible to
ProDOS 8 140k images. As far as I understand it's "only" a question of
doing the sector skewing on the "right" side (server vs. client).

I'm actually proposing to have the bytes per sector, sectors per
track, and tracks per volume all be negotiated within the protocol
itself.


The full bootstrap then would be
1) DHCP to get IP address
2) TFTP to d/l and execute the patched DOS 3.3 image

This doesn't mean a DOS 3.3 formatted disk image, but an memory image
of DOS 3.3 - correct? I wasn't aware that this is possible as a single
BIN file, thinking of page 3 vectors and alike...


Yes, I did mean a memory image. Which may include a stub needed to do
any fixup prior to execution, e.g. setting of page vectors stuff
(alternatively, I could include page 3 in the memory image itself).

3) Patched DOS 3.3. pops up a menu from which one of the dsks served
from the netboot65 server can be selected
4) the HELLO from the selected dsk is executed (or if there is  no
HELLO, then a catalogue is displayed, and the user can RUN/BRUN as
necessary).

I see. Even if 2) wouldn't be possible with ProDOS 8 it would still be
cool to patch/extend ProDOS 8 to access your server, maybe replacing
the /RAM device. This would allow to use the whole AUX bank for the
IP65 and client code...

the bootstrap code I have at the moment (which is just the DHCP+TFTP
layer), all lives in the language card. I'm struggling a bit to know
where to stash everything, probably because I'm still a little fluffy
on my use cases. My initial goal for the Apple 2 side is to make it
trivial to run a server on a PC and point it at a bunch of dsks with
games on them (including pirate compilation disks), then boot up the
A2 (or emulator) and be able to select a disk, and then run a game on
it. Given ProDOS already supports layered device drivers, I figured if
I can get this system working with DOS 3.3, then it shouldn't be too
hard to get ProDOS working also.

The advantage of putting stuff in the language card is, it's
(slightly) more likely to be there than AUX is (i.e. you're not
restricting yourself just to 128Kb IIes). The disadvantage is, it's
more likely to get clobbered by the code that you d/l and execute. I
actually started with trying to put the code in the aux bank, and
changed my mind when I couldn't get it to work straight away :-) (this
is my first experience with bank switching). And as I said elsewhere,
what I really want is put this stuff in ROM.

I'm heading o/s on a business trip on Sunday - I won't be able to do
any A2 coding but hopefully can get the protocol spec into a state
that I can solicite feedback from any interested parties.

Thanks for the feedback to date!

Cheers

Jonno
.

Relevant Pages