One weird little quirk about being human is that we (as a group) tend to think things have been the way they currently are for a lot longer than they actually have been — and that they're not likely to change.
Even the most hard and well-backed-up science tends to change with the proverbial wind. Example: Cholesterol ... good or bad? See? Things (and ideas) change. Fast. And often we don't think they've changed at all.
Sometimes it's good to sit back and look at how things have already changed — to see how things might change in the future.
Let's apply that to servers. Computers serving up bits of data to other computers. What did those look like 10 years ago? 20? 50? In this article series, let's look over each major era and type of servers, in no particular order — I'll be bouncing around a bit as I tell the story of "Computer Servers."
Bulletin board system servers
Let's start with something that for many, might seem a little ... unusual. The dial-up bulletin board system (BBS).
You see, we didn't always have the ability to obtain always-available physical connections to a server.
During the 1980s and 1990s, one of the most common ways that average people connected "online" was to use a dial-up BBS. A modem on your computer would literally dial over an old-style analogue phone line (aka "a land line"), and another modem connected to another computer.
Fun fact: Modem stands for Modulator - Demodulator — Mo... Dem. It takes binary data and modulates it (making the most soothing sound on the planet for nerds in the 1980s), sends it over the phone line (analogue), and demodulates it on the other side.
These BBS-es were, in a very real way, servers. The biggest difference between those dial-up bulletin boards and servers of today is in the way people connect and (because of that) how many people could connect at once. You could almost think of each modem (and phone line) connected to a given BBS as a single socket that could support one connection at a time — 3 modems = 3 people connected at once.
The idea of having only a handful of people (or even just 1 person) able to connect to your server at a time is somewhat preposterous nowadays (at least in most environments). Yet that's the way it was back then. And when there were no more modems available? You'd get an honest-to-goodness busy signal — a noise that kids of today probably have never even heard.
What's more, the speeds were hard-limited on a per-connection basis. If you have a 14.4k modem, that's the maximum speed that data could be transmitted over that connection. You couldn't simply bring in a faster connection to increase speed for all users; you needed to upgrade each modem to accomplish that. And even then, the quality of the analogue lines between your BBS server and your connected client played a huge role in the actual speed. I suppose that last part is still true today, though most people don't notice it so much.
BBS servers vs. modern servers
That wasn't the only way (most) BBS-es differed from modern servers (web servers, etc.).
Most BBS-es in existence ran on operating systems such as DOS, CP/M, Apple ProDOS and other non-multitasking systems. That meant only one instance of the BBS server could be running on a single computer at a time.
One user. One computer.
Want to have a BBS that ran on, say, MS-DOS that could allow two people to connect at the same time? You'd need a second computer, and those two computers would need to be networked together, such as through an old Token Ring network, to share critical files with one another. (Wow — I haven't written the words Token Ring in a long, long time.) That way, for those two "dialed in" users, they would feel as if they were on the same system and be able to interact (chat, etc.) accordingly.
Imagine if that were the case with web servers. For every theoretical concurrent connection, you'd need to add another entire computer. Absolutely crazy to consider.
BBS servers and ‘Door’ programs
BBS servers also were interesting in the way that their functionality could be extended.
The most common method is via what were known as "Door" programs. When the user requested a specific "Door" program (be it an online game or some communication tool), the entire BBS shrunk out of memory. It just shut itself down and launched the requested application. (Remember, these were often running on operating systems that could not multitask.)
The BBS would first write the details of the connected user (what physical modem was in use, the users name, etc.) to a simple text file. Then the BBS would close down and run the requested "Door" application, which would know to load up that text file in order to continue using the modem — which was sitting connected and waiting that entire time.
BBS servers and email: Slower than postal mail
These BBS servers handled email that was not unlike email of today. The primary difference being that instant delivery of email occurred only on the local BBS system. If you sent an email to a user on a different BBS, that user wouldn't be able to read that email until the two BBS systems performed a regular (often once per night) connect to trade emails with each other.
Each such connection between two BBS server was considered a single "hop." Often, in order to get email delivered to a physical location that was very far away, multiple such hops were required. The email would be delivered to one BBS on the first night and then the next BBS in the line each night.
With this system (which was incredibly popular in the 1980s and into part of the 1990s), email was not an instantaneous thing. It was not unheard of for email delivery to actually take longer than postal mail. That's not a joke.
Still, millions of people used such services for email. At its peak, the most popular such network of BBS-es (known as FidoNet) consisted of over 39,000 dial-up, bulletin board systems across the world.
The inner workings of these systems was, likewise, rather unique. Most were run (especially in the 1980s) on non-multi-tasking systems. That means the concept of "concurrent user load" wasn't something that most system operators (Sysops) — what the Sys Admins of these systems were called — had to worry about. One user at a time meant performance load handling wasn't typically a big concern.
In fact, most BBS-es had very low-tech "databases" for storing user information — often either plain, structured text files or simple, home-grown binary file solutions. You definitely never heard about a sharded sql database.
Advantages of a BBS server
By almost every way you can imagine, the BBS server concept and structure is far inferior to anything we have today. And yet there are some unique advantages to such a BBS server.
Perhaps most notable: The barrier to entry was astoundingly low for hobbyists and amateur computer users to set up and run their own BBS. With a computer (with almost any operating system), a modem (of almost any speed), and a phone line (preferably with not too much line noise), you were good to go. Many BBS-es didn't even run on hard drives; a lot of the earlier ones ran on floppy disks.
Bulletin board systems still running today
Amazingly enough, many BBS-es still run today. I even run one (that people connect to via the Telnet protocol). Why? Mostly because I enjoy working with these older systems. It keeps me grounded and closer to the roots of computing.
My BBS reminds me — when I connect over my ultra-fast fibre connection to my multiple servers (hosted around the world), capable of server huge loads of concurrent users — that it wasn't always this way.
The protocols change. The connection type and speed (and frequency) change. The server capabilities and storage change. The way I administer it and the way that I use it — it all changes. None of it stays the same.
Oh, jeez. When I say it like that, it kinda makes me sad. Wistful for days of screeching modems and slow transfer speeds. But then again, it is rather nice being able to server a webpage to more than one person at a time.
So, you know — trade-offs.
>> Read next: History of computers, part 2 — TCP/IP owes a lot to Xerox PUP