Re: NadaNet file server coming soon...

On Mar 22, 5:22 pm, "Michael J. Mahon" <mjma...@xxxxxxx> 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).

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.

Regards,

Matt

.

Relevant Pages

  • Re: Terminal Server Performance
    ... I will have to look at the disk queue on Monday. ... We are using switches and the server has a 1 gbps card in it connecting it ... for the percentage in the network utilization?... ... "Jeff Pitsch" wrote: ...
    (microsoft.public.windows.terminal_services)
  • Re: DHCP for multiple subnets (was: Re: Routing and bandwidth problem)
    ... >> The DHCP server shouldn't care what interface the request came in on, ... >> rather it looks at the source network of the request. ... > for the DHCP server? ...
    (Fedora)
  • Re: Terminal Server Performance
    ... we are finding the disk queue is in fact building up ... I have run network tests ... I will have to analyze the data when the server starts going slow again. ... the hard drives to see if commands are lining up during peak ...
    (microsoft.public.windows.terminal_services)
  • Re: Brother MFC 8840DM Spurious Failed To Print Message
    ... We have a Brother MFC 8840DN attached ... >>>directly to our network which has a Linux server at the heart of it. ... >Another problem may be the queue size on the printer, ...
    (comp.periphs.printers)
  • Re: NadaNet file server coming soon...
    ... and uses a message server to queue the requests. ... forgoes queueing (since one client can't have more than one request ... idles in a &SERVEloop polling the result code after each network ...
    (comp.sys.apple2)