apratt@atari.UUCP (Allan Pratt) (12/30/88)
> Submitted-by: madsen@sask.usask.ca (Jorgen Madsen) > Posting-number: Volume 3, Issue 52 > Archive-name: mx2v230/part01 This multi-tasking system was submitted to comp.binaries.atari.st and comp.sources.atari.st... I have been looking at the program which gives one ST remote access to the other's disk drives. Until I look a little further, my advice is this: DO NOT USE THIS PROGRAM! I am talking about the network file system part of the MX distribution: the rest, for all I know, works fine. The problem with the networking part is this: it changes the contents of the disk without GEMDOS's knowledge. This can be disasterous if the program changes a disk block which GEMDOS has in memory. There is no (legal) way to know if GEMDOS has a block cached, and even less of a way to tell GEMDOS that a block is suddenly changed, and it's even WORSE when GEMDOS has a block cached AND HAS CHANGED THE CACHED IMAGE (that is, the cached block is "dirty"). If you use the networking for reading only, or if you are EXTREMELY careful about how you use it, you can succeed. By being careful, I mean that the person using the ST locally and the one using it remotely should never access the same logical drive. I don't mean not accessing it at the same time: I mean accessing it EVER. If you restrict both users to read-only access to a logical drive, you'll do okay. So if you both access drive E: for reading only, and one of you accesses drive D: for reading and writing, and the other one accesses drive F: for reading and writing, you should do OK. If you want a detailed disaster scenario, here it is: User L is local, user R is remote, and mx2net is running on both machines. User L begins editing D:\SRC\FILE1.C. GEMDOS caches part of the FAT from drive D:. User R begins D:\WORK\FILE2.C (that's D: on L's system). *His* GEMDOS also caches part of the FAT from drive D:. User L writes his edited file to disk. It got bigger, so a new cluster is allocated. The new FAT is written to disk. User R writes *his* edited file to disk. It got bigger, too, so a new cluster is allocated. But User R's GEMDOS uses the cached FAT from drive D: to allocate the new cluster, and allocates the same one! BAD NEWS. It can get worse, too. Notice that it doesn't matter that they aren't accessing the same folder, and it doesn't matter if they don't do it at the same time: the problem is that user R has an out-of-date local copy of a sector on drive D:, and his GEMDOS can't know it. But if all the drives they both use are read-only, then they can each use other drives for read/write and never get into trouble. This is not as much of a problem under TOS 1.0 or 1.2, because GEMDOS is really stupid about invalidating perfectly clean, cached sectors, but TOS 1.4 is *not* stupid about it, and it is really easy to get bitten by this. It's still possible under TOS 1.0 or 1.2, however. I applaud the effort which the author has clearly put into this. I have not tried, let alone analyzed, the multitasking part. I hope he has not fallen into the same local-copy-of-global-data trap. Has anyone out there had experience with the previous versions of this code? ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
david@bdt.UUCP (David Beckemeyer) (01/04/89)
Allan Pratt describes a fatal flaw in the above network software.
It seems very common that someone thinks a network for the ST is
easy and tries it. I have looked at several (at least five)
supposed "networks" for the ST. Some were supposed to eventually
be commercial products. I can't tell you how many times someone
has told me "Well Company X has a network for the ST - It will be
out in two weeks."
BEWARE! *NONE* of these networks have been even close to being real.
It is an extremely difficult task to make a useful general purpose
(i.e. remote file-system) network for the Atari ST. You can make
something look like it works, good enough for a trade show, with
little difficulty. You can also get special purpose networks running
like for transaction processing, or a controlled disk access (especially
read only), without too much work. But if someone tells you they have
a LAN-type network for the ST (or they're going to to have one real soon),
be *very* cautious.
The first one I saw was announced in 1985. It was never released. Since
that time I have seen many announcements of Networks for the Atari ST.
I have also seen many PD attempts. A lot of effort was put into everything
I saw, and I don't want to flame anybody who has tried it. This is just
a warning to would-be "believers" - be wary of ST network claims.
--
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, AZhafer@infbs (Udo Hafermann) (01/04/89)
In article <471@bdt.UUCP> david@bdt.UUCP (David Beckemeyer) writes: > >BEWARE! *NONE* of these networks have been even close to being real. > >[...] This is just >a warning to would-be "believers" - be wary of ST network claims. This puts me in a difficult position - but nevertheless: 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: Introduction ------------ The Atari network described here has been heavily used in our own projects for a year. It provides multi-user access to shared disk space using the familiar TOS interface. The network utilises Inmos transputers with their fast link connections. Work is currently being done to integrate IBM-compatible PCs into the network and to implement an interface to the inter-user communication facilities. Hardware -------- The network requires at least one server. A server is an Atari ST (512 Kbytes of RAM are sufficient) with a harddisk (although in principle any drive, including large RAM disks, could be used). It has the sole task of handling requests from the network, thus managing access to its disk data. A server Atari cannot be used otherwise while the network is in operation. There may be many servers in the network. All other network participants are called users. A user thus is an Atari with or without a local (non-server) harddisk, connected to the network via a so-called Adapter Box which plugs into the ROM port. An RS424 line connects the Adapter Box to a transputer. In this manner, the network can be extended to almost any size. Software -------- From a user's view, the network provides additional TOS drives, for which the drive specifiers P downto minimally G are used. Drive specifiers are assigned to disks or partitions of servers independently (and dynamically) for each user. The icon-driven desktop user interface is fully operational. 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. Programs can be loaded and run from network drives (although they are actually executed on the local computer). Hierarchical inheritance of I/O-redirection and current paths are implemented in the usual manner. If a user program crashes (bombs etc.), the network remains operational for other users. The crashed computer must simply be rebooted. It may however be necessary to explicitly close files which were opened on a server but not closed. Software support for this is provided. Two additional programs allow users to have temporary exclusive access to the printer connected to the Boot Server. All printer output via DOS calls is then redirected to the boot server's printer. --------- As said, the network is *operational* (and, incidentally, will be on display at the CeBiT Hannover Fair this year), and we are quite happy with it. Mail me for more details. Udo Hafermann Abteilung fuer Theoretische Informatik Bueltenweg 74/75 Techn. Univ. Braunschweig D-3300 Braunschweig W. Germany email: hafer@dbsinf6.bitnet (preferred) hafer@infbs.uucp
apratt@atari.UUCP (Allan Pratt) (01/06/89)
In article <116@infbsgr.infbs> hafer@infbsgr.UUCP (Udo Hafermann) writes: > 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. Your terminology confuses me. In Atari parlance, AES + VDI + GEMDOS + BIOS + XBIOS = TOS Therefore saying "All TOS calls are supported" but "BIOS calls are not possible" doesn't make sense. If you mean GEMDOS where you say TOS, it makes more sense, and it will work. The reason I said networks can't work is that GEMDOS will cache sectors which might then change on the media, without GEMDOS knowing that its cached sectors are out of date. If you reimplement GEMDOS it'll work fine. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
david@bdt.UUCP (David Beckemeyer) (01/07/89)
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