🚀 go-pugleaf

In article <116@infbsgr.infbs> hafer@infbsgr.UUCP (Udo Hafermann) writes:
>We have a transputer-based network connecting (at this time) seven STs
>to (at this time) two servers up and running for over a year now.  A
>short description follows:

[ Long description of network edited out ]

I did not mean to imply that networks were impossible on the ST.  I said
they were dificult and that I had seen many that were far from being real.

I have not seen the one described in the reference article.   But it does
back up my point that netwrosk are *non-trivial* on the ST.  It sounds
like this network has a lot of effort put into it and they may well have
done it right.  Some things in the descriprion imply that they had to
solve a few things:

>A server Atari cannot be used otherwise while the network is in
>operation. 

>...  A single file can be opened for reading by any
>number of users (if no-one has write access); however, a file can be
>opened for writing only if no other user is accessing it. 

>The user's computer gains network access by loading a resident program
>which redirects TOS requests for network drives.  All TOS calls are
>supported; BIOS calls for network drives are not possible (and
>protection mechanisms therfore cannot be by- passed).  A few new TOS
>calls for internal network purposes have been added.  Network access can
>be dynamically de-installed. 

All the above tells me they have done more homework than usual.  A centralized
dedicated server is the easiest approach to implement.

The third paragraph above, to me, implies that they may have done what
has to be done: re-implement all GEMDOS File I/O calls to handle the network.
But it can present compatibility problems.  The fact that BIOS calls are not
supportted, already means that some programs aren't going to work; and I believe
even the GEM Desktop uses the BIOS for some stuff, which means those Desktop
functions won't work.  It means a special Pexec handler must be written too,
which means either hacking into GEMDOS memory management, or taking over all
memory management from GEMDOS.  This can create even more compatibility 
problems - one hack to TOS always tends to cross-over into more parts
of TOS than expected.

They also used the cartridge port instead of the AHDI DMA port, which makes
it sound like it has more potential than anything I've seen yet because
you have a lot more hardware control here than the other I/O ports, but the
speed might be marginal.

I'm also wondering what's running on the server.  What about "too many files
open" problems if it's running regular TOS?   Normal TOS can't dish out too
many file handles at once.  And what if the server crashes? And since only
one user can open a file for writing, data-base applications will be very
restricted.  Most data-base applications assume you can lock records and/or
files at will.
-- 
David Beckemeyer (david@bdt.UUCP)	| "Lester Moore - Four slugs from a .44
Beckemeyer Development Tools		|  no Les, no more."
478 Santa Clara Ave. Oakland, CA 94610	|   - Headstone at Boot Hill
UUCP: {uunet,ucbvax}!unisoft!bdt!david	|     Tombstone, AZ