Re: NadaNet file server coming soon...

["Michael J. Mahon" <mjmahon@aol.com>]

On Mar 22, 8:29 pm, "mdj" <mdj....@gmail.com> wrote:
> On Mar 22, 5:22 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
>
>
>
>
> > The current implementation is geared to a network of more than two
> > machines, and uses a message server to queue the requests.  The server
> > and client code are easily modified for a two-machine network that
> > forgoes queueing (since one client can't have more than one request
> > in the queue at a time anyway) and so doesn't need the message server.
>
> > The client machine queues a request (prefixed with its machine ID)
> > by doing a &PUTMSG to the predetermined file server queue number, then
> > idles in a &SERVE() loop polling the result code after each network
> > transaction handled by the client.  When it finds a result, it returns
> > from the GOSUB and continues execution.
>
> > The file server idles polling its input queue with a &GETMSG, and, when
> > it finds a request, it parses it, sets up any required parameters that
> > were not supplied, and executes the command on the local file system.
>
> > If a data transfer is required, it is &PEEKed and BSAVEd or BLOADed and
> > &POKEd in chunks up to some maximum (like 4KB, to keep network latency
> > reasonable).  When the command is complete, the result code, and any
> > address and EOF information, is &POKEd to the requester, and the server
> > goes on to the next request in its queue.
>
> > Performance seems to be quite good, limited primarily by device latency
> > and/or network bandwidth (>10KB/sec).
>
> Hi Michael,
>
> Interesting approach. I had expected a block-level implementation,
> although that precludes serving data to multiple machines (Unless your
> server can pull off some pretty amazing locking intelligence).

Exactly, which is one reason I rejected that approach.

> While it's probably inappropriate to start talking about extensions to
> unreleased products, I'll do it anyway :-) One idea would be to modify
> the client to use the ProDOS Filing Interface hook, which would enable
> it to function transparently for *any* ProDOS application. It begs the
> question "where to put it", but I assume disconnecting /RAM and
> stuffing it into ALTLC would work just nicely. It's about time
> somebody discovered just how 'friendly' developers were to Apple when
> respecting the reserved memory areas :-)
>
> Anyway, just a thought, and a way to significantly increase the
> utility of the network.

One fact I didn't mention is that ProDOS on the client side is not
used
at all--in fact the client may be a DOS program or a program running
on a "bare" machine, like a 'Crate machine.

In my experience, there is little additional utility in adding support
for
other ProDOS programs besides instant compatibility.  I practically
never use text file I/O, choosing instead to manage all file types
using
binary I/O, so it fits my needs perfectly.

Since the server is currently "stateless", it would be much more
trouble
to handle "open" files for a list of clients.  This way, all file
operations
remain atomic.

-michael