jrodrig%mitre-gateway@sri-unix.UUCP (01/24/84)
From: jose rodriguez <jrodrig at mitre-gateway> Well, I can give you some info on LANs because we have installed several on DOD sites. Let me answer your questions: 1) Yes, TCP/IP can run on LANs (baseband or broadband -- it is immaterial to base/broad what layers you have above the datalink (I think). As a matter of fact some people are putting baseband nets into broadband channels through 10Mhz modems (a really neat idea) (you see, there is no standard for broadband datalink layer). As a matter of fact, I would say that the faster the LAN is, the less important the size of packets is (what really counts is the number of packets -- but this is an extremelly complex problem...). (If anyone has hard facts, please come forth.) 2) "If a LAN supports TCP/IP" actually is the nodes that support TCP/IP. You mentioned servers vs. terminals. Well, there is something in the middle: the user-side of protocols. All protocols have two sides: user (driven by the person) and server (waiting for connections across the net). The user side can be made considerably simpler (and in my opinion, better) which makes them feasible for pc's (the 8088 is slow, but not THAT slow...). There are other schemes to make implementations perform reasonably (for a single user) on PCs. Now "...have to support ...FTP,TN..." well why have TCP/IP, etc.? If you mean less powerful applications, that's a good idea. The CSG group at MIT have done such work, particularly they have a TFTP (T for trivial) which only needs one TCP channel. 3) "...expect...8088..." Well, if you design it right, why not? Look at it as a challenge. (We think it is feasible). "...single tasking..." I would rather have a monolithic program that takes over the pc than some scheduler coming around and bothering. I can implement my own multi-task OS for the pc more suitable for real time needs. You see, our Suns 1.0 have a performance far worse than pc's... think about that.... 3Com's Ethernet has a lot added to Ethernet (a remote procedure call protocol and a byte stream protocol based on the XNS (from Xerox) family of protocols). The same (or similar) functionality is provided by other PC vendors but the problem is they all are incompatible! "That's fine, you know, for our needs...", well what happens when your supplier goes under? Or if you want to add someone else's equipment (say a 68k workstation) not supported by your network vendor? Actually, I am being a little too hard on 3Coms equipment. As a matter of fact I think their protocols can easily coexist with Telnet, FTP, etc. (if it wasn't for their hardware, but that is a different story...). What does TCP/IP buy me? Well being able to hop to our LAN, go through a gateway, into the Arpanet, go through a MIT gateway and login to my old job's host machine. If you have any questions don't hesitate sending mail directly to me. Jose
v.cc2%UCLA-LOCUS@sri-unix.UUCP (01/25/84)
From: Computer Club SDC <v.cc2@UCLA-LOCUS> This is an editorial comment. I hate the general software available for the PC! This gripe has been on my mind for a while but it came to a head yesterday when I finally got fed up with Orchid PCnet trashing the FAT on my hard disk for about the fiftieth time. This is due to the fact that (I was told this by Orchid) "The system is designed to be used by a single user and share peripherals." What's the point?! That means that there is no mechanism in PCnet to lock the fat in any way. What happens is that each machine reads a copy of the fat into memory when it opens a file. After it didles with the file, puts it back, and writes the fat that it got when it opened the file, regardless of what other nodes on the net do. So if you are working on a file that has a FAT entry in the same FAT sector as another node, at the same time, the result is 1 trashed disk - every time. I figured, OK, someone else must realize that this has to be delt with. I tried Davong Multi-link. What complete junk, we won't even talk about it further. Suffice it to say that it does most everything wrong (just like everything else they make.) Then I tried Xcomp X-net. They swore up and down that they had the FAT problem solved. If you open a file with a filehandle open for write or with just a normal open, the file is locked until closed and they read the FAT BEFORE they rewrite it. Great, no more trashed hard disk 'cause it, in fact, does what they said, however, they also don't support standard input or output. None of the pipes or filters worked anymore. I was just about to hit the roof!! I have had just about enough of this trial and error hardware testing. Every- one seems to be using the public as a beta-test sight. Do any of you know of a net that works properly (I am leaning toward 3Com, all I need is a good word) with 3-6 users doing disk intensive stuff that supports IBM's documented features (no trade offs: No trashed disk but no stdin/stdout). I don't really care that much about speed as long as it works well. - Howard (cc2@ucla-locus)