Chris Findley wrote a series of articles in this magazine on how network your several home computers. You do have multiple computers at home, don't you? Well, some people must, because people at work kept bugging me about when Chris's next article would be out, and what it would be about.
I never really know just who the audience for this magazine is. I suspect that it is wide and varied. Generally, I try to talk about home computing, but every now and then I get an urge to put on my coat and one tie and be a business guy. (Several years ago, I actually did wear a suit and tie to work. It was Halloween.) Today I want to talk about how a middling to large organization does networking, just so some of you who do not get a chance to work with a million bucks worth of equipment can have some idea about what you can really do with some speedy bits.
I transferred to my present location within the World Wide Widgets family only nine years ago. The computer group I belong to which now numbers about 15 people was just getting started, and I was the first full time member of that group on our site. While I had worked for WWW for 20 years prior to that, I had never before had my own PC on my desk. The project we were about to start working on had not yet decided to use Unix as its foundation. Networking for us was still what you did at lunch.
The facility started to grow, and we hired some full time employees and part time contractors, and added workstations for program development, decided to use Xenix (the word Server was not much in use then) for our product. But we were still stuck in dumb terminal mode, with the Unix host connected to a multiport serial adapter, to which our workstations were connected (as 9600 baud serial devices) in Wyse 60 or VT 100 terminal emulation mode. Over time, we got some packages that let us upload and download program files from our workstations to the host, but only over those same serial lines.
A couple of years on, we got our first Novell (2.x) server, and we did start to create a network. The good news was, we finally had email, if only within our own office suite. It would take another five years before we could reach out and touch the rest of the plant, let alone the rest of WWW, something that is only now starting to get accomplished.
The bad news was, the Novell system used a protocol called IPX/SPX, while Xenix used something called TCP/IP. It really doesn't matter what these letters stand for or really how they work, these are network protocols that allow multiple machines to communicate between themselves if they are all wired together on some common backbone, generally ethernet. But they are different network protocols, and they did not coexist well within our workstations. We spent months trying to find what was then known as a protocol stack to sit first on our DOS workstations, and then later on our Windows 3.0 and 3.1 workstations, that would let at least that workstation talk to both the Novell and the Unix host, even if the hosts themselves would not talk together. Over time we upgraded from Xenix to Unix, primarily because Unix provided far better networking tools (to other Unix boxes at least) than Xenix did (even if Unix and Novell still would not talk to each other).
By the time Windows 95 became commonly available, with its own set of protocol stacks for both Novell and Unix, we were pretty much in fat city. Email had reached beyond our immediate building, even though the pipe was a 56Kb leased line, later to be T1, still later on fiber at full ethernet speeds, and it started to become almost a no brainer to expect your workstation to be able to communicate to not only your local LAN, and your local Unix boxes, but to the LAN in another WWW facility in Seattle, and to the multiple servers that had grown up in the rest of the local facility a mile away from our immediate building. For political rather than technical reasons, we still cannot talk to another WWW facility 20 miles away in this same city.
Every day at work, it is generally the case that I will see on my workstation screen windows from maybe five other computers at the same time: one or two Novell (4.x) servers, file servers, modem servers, fax servers, print servers, several Unix boxes in our building, a couple over in the plant a mile away, more Novell and Unix servers at Seattle, and using dialup techniques, the World Wide Web, and customer Unix boxes maybe two thousand miles away. It is easy to forget the long struggle from when I first walked into my new office nine years ago to find my first very own PC and as yet nothing to connect it to.
The Novell facility we have allows us to access shared disk drives on our local server and on other servers all over the facility as if they were directly hung off our own workstations. And if the particular workstations permit it, I can even access the local disk drive of somebody else's workstation, anywhere else in our facility.
The Unix boxes all talk to each other on the same set of Ethernet cables, but because they use their own protocol separate from what Novell uses, nobody bangs into anybody else. So all the Unix boxes have access to all the other Unix boxes, and with a little TCP magic, you can logically mount a disk drive from Unix box A onto Unix box B so seamlessly that it takes a significant skill to even determine that this second disk drive is not locally connected to what you think is your local host. The downside of this is, a single point of failure can potentially collapse this whole interconnected scheme.
Another problem that we have found twice now, is that a computer on your network that has nothing to do with your system, can accidently affect your system. Unix has something called a time server, a central box that synchronizes all the clocks of all the other Unix boxes on the network. Our problem was, we develop software for companies all over the world. And in their final checkout, we set that system for the time zone of the customer site. And if one of them happens to think he is a time server, all of a sudden a half dozen other Unix boxes in two cities are running six hours fast or 12 hours slow, because their clocks got reset by our time server.
This whole network is so seamless, that we have accidentally tested programs on what we thought was our local Unix box, but found that the Seattle box started answering up to our test requests, because he was sitting there listening on the network line for anybody that wanted to talk to him. We were saying something he liked, and he jumped right into the conversation.
Ethernet was invented maybe 20 years ago by, well you hear various genesises, maybe by Xerox Parc, maybe by Bob Metcalf (at least he made some money off of it, even if Xerox did not). It was originally a coax cable that would carry bits around at the rather amazing speed of 10 million bits per second. Later developments let the coax go away, at least for short distances, to be replaced by Plain Old Telephone Wire (preferably Cat 5, but the old stuff will do). And later developments yet upped the speed to 100 Mb/sec, which appears to be common today. Here in Spokane, we hear continuously of a company named Packet Engines, which is one of several companies developing 1000 Mb/sec ethernet, or as they call it, gigabit ethernet.
So, why would anybody need all this bandwidth? Essentially no one machine, even a super server, is capable of dealing with a continuous data stream at 12 (or 120) Mega Bytes per second. But a network is a hose with dozens or hundreds of attached machines all pumping data into this data hose, and all sucking data out of this same data hose. At some point of complexity, you do not have any one machine being the bottleneck of your network, or at least you hope you do not. You have dozens of machines sending data back and forth between themselves, but all on this same etherhose.
And that is the genius of the ethernet mechanism. RS232 serial cables really cannot do anything more than connect two machine (printers, crts, computers, whatever) together. It gets really complicated to connect three or more things together. In the old days (10 years ago) we would have huge cabinets of RS232 serial cable connectors, feeding data into one host machine from a dozen peripherals and CRTs. Today it is a single ethernet connection. Ethernet allows dozens and hundreds of machines to talk on the same piece of wire, because of at least two characteristics. First, it is very fast, and the allowed packets are relatively small (about 1500 bytes maximum). Thus, no one computer will tie up the etherhose for very long, at least not on any one packet. About one millisecond, or less at 10Mb. Second, the technology allows for Carrier Sense and Collision Detect, which essentially means that somebody who wants to transmit onto the etherhose can first put its ear on the rail to see if there is any traffic there now, and if not, while it is transmitting, it can detect if somebody else also started transmitting (creating a collision), and back off for a few milliseconds and attempt the transmission all over again. This works very well as long as you are not using more than about 75% of the available bandwidth.
The physical medium alone is not the total answer. There is a lot of sophistication involved in the protocols (the TCP and IPX stuff) to really ring the most out of a network, and to allow heterogeneous machines to all sit on the network, even if they do not understand what half of the other machines are doing. It seems quite easy from the point of view of the user to start up a telnet session to a computer a mile away, but an awful lot of software sophistication went into making that simple thing happen. The World Wide Web is chock full of very sophisticated software technology to make it all so simple to work with.
The downside of this sophisticated technology, is just like programs expand to fill the memory available on a modern computer, so does network traffic expand to fill the capacity available. Give a machine a method of delivering a few thousand packets quickly and cheaply, and all of a sudden you will find people who would have been quite happy sending just text messages back and forth now sending multimegabyte CAD files, TIFF graphics, waveforms, television signals, internet phone conversations ... The founder of one company was quoted to say "find a need and fill it", but today that slogan might be find some bandwidth and fill it.