Path: utzoo!utgpu!attcan!uunet!unisoft!bdt!david From: david@bdt.UUCP (David Beckemeyer) Newsgroups: comp.sys.atari.st Subject: Re: mx2v230 (in comp.binaries/sources.atari.st) Keywords: Atari ST Networks Message-ID: <473@bdt.UUCP> Date: 6 Jan 89 20:48:52 GMT References: <5860@saturn.ucsc.edu> <1280@atari.UUCP> <471@bdt.UUCP> <116@infbsgr.infbs> Reply-To: david@bdt.UUCP (David Beckemeyer) Organization: Beckemeyer Development Tools, Oakland, CA Lines: 60 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