Once Upon a Time in the 1632verse
A long time ago (ok, so, 18 years or so. It just feels like a long time) I hung out in the forum that generated much of the 1632 universe for Eric Flint. He wrote the core stories, but we figured out the rich tapestry.
That was where I found out that writing fiction wasn't my gift. Figuring out the crazy things you could do? Sure, that's easy. But writing a _story_? Just seems not to have been my thing.
So the 1632 universe wound up creating the Grantville Gazette, as a place to showcase the technical articles and short stories that kept being developed. Herewith is one of mine - where we figured out how to build the internet using old PCs and telegraph line in the middle of the 17th century.
And, before you ask, yes we did steal from RFC 2549: IP over Avian Carriers with Quality of Service and Ethernet over Barbed Wire.
------------------------------------------------------------------------
Grantville Gazette Online, issue 12.
IP Communications in 1633
Written by Charles Prael
The internet, as we all know, is a complex beast. It depends on a wide variety of technologies to deliver a wide variety of information over a large number of different computing devices. So, how feasible is it to build an internet in the 1632 Universe? Less difficult than you might think, depending on what you're after. To make those decisions, we need to look at what resources are available on several fronts. Before going too far into this, you might also want to review "So You Want To Do Telecommunications In 1633?" in Grantville Gazette, Volume 2.
Resources
Computers
In 2003, a number of folks worked to put together a computer resource survey for Grantville, to provide some definition of what kind of computational resources might be available to the residents of Grantville who had been cast into the past. That survey can be found here: http://homepage.mac.com/msb/163x/faqs/computers.html
Several assumptions (at least one of which proved to be too conservative) were made governing how many and what types of computers might be available. A few starting points can, however, be noted. First, don't expect to see anything introduced after February of 2000. That allows a couple of months for just-released technology to reach Grantville (which, you should note, is not necessarily going to have the latest and greatest hardware, either—historically West Virginia lags behind the rest of the country in tech adoption). Second, expect to see a lot of hand-me-down computers—older models, such as 386s, 486s, Pentium Is—that kind of thing. The one assumption that was, in fact, too conservative was that the Mannington schools had made a concerted effort, in the late 90s, to provide up-to-date computing hardware for the teachers to use with their students. As a result, there were more then-modern computers than expected—mostly Celerons and Pentium IIs, with a mix of Pentium IIIs.
Also worth noting is that there were more, older "scrap" computers than expected. Hold onto that thought, because we'll be getting back to it.
Routers
One of the big issues in building a network is routing capacity. In that sense, Grantville was sorely lacking. A grand total of 2 T-1s (with associated CSU/DSU hardware) have been identified within the radius of the ROF. By authorial fiat, a total of 4 early-model 802.11b wireless routers are also present—and no, these don't have the firmware that allows them to be used as long-distance bridges.
But, if you think back a few years to the early days of the Internet, you'll find that "routers" were not much more powerful than then-extant computers. Which means, if you think about it, that you're talking about something with the horsepower of a 386 or a 486. Hold that thought as well, because we'll be getting back to this issue.
Backbone
This is where you wind up with a real problem. Because, except for the in-town cable, and the 7 miles of fiber optic running under the CSX rail line, there just isn't anything useful—you'll have to make it all, using existing resources. Except, you don't. The groundwork has already been laid for you, if you know where to look. A few data points to consider:
- A few years ago, just to prove that they could, a datacomm company who shall remain nameless decided to demonstrate the robustness of their product by running an Ethernet networking connection over 8 strands of barbed wire. Just to finish proving the point, someone later ran an Ethernet link over a one mile section of barbed wire.
- At about the same time, a group in Norway actually implemented what had been henceforth a joke: IP over carrier pigeon. Using a printer, a scanner, and a carrier pigeon, they successfully established a network link between two computers, including a network segment delivered solely by carrier pigeon. The latency was, as you might expect, atrocious. Nonetheless, they were able to pass network data across the link.
- Ham radio operators routinely operate IP networks over high-frequency radio networks, worldwide.
- Most modern telephone service is delivered over a two-wire pair—what's known in the industry as unshielded twisted pair (UTP). If you look at a modern phone wire, however, you will find that it normally has two pairs of wires. What's interesting about this is that 1990s-era 10Megabit Ethernet (10BaseT, in industry parlance), will run quite nicely using two pairs of wire.
So, what does all this mean? Well, for starters, it means that if you are (a) willing to be a little unconventional in your methods, and (b) willing to accept reduced capability, you can build quite a bit of network with materials ready to hand. In fact, if you want, you can build out most of a small town with the equivalent of a 1990s office network. Getting outside of the town will be much more of a challenge, however.
Building the Network: Routers
Once you've decided to build the network, you need to have some form of router. A router is, really, just a computer that plays the role of traffic cop—it directs network traffic hither, thither, and yon. It's worth noting that Linux distributions since the 1990s all contain core routing software within the operating system and within the packages that are distributed. It's simply a matter of setting it up. It's also worth noting that a fully-fledged Linux router, using a stripped-down version of the operating system, will run in as little as 8 MB of memory space. Remember those 386s and 486s I mentioned? Well, a well-equipped 386 might have a whopping 8 MB of memory. Just about enough to act as a router, if needed. All we'd need was the right individuals, and some time to configure and program a router package, which could then be duplicated. So, that's one problem solved. But. . . now that we have routers, what network do we route traffic on?
Building the Network: the Backbone
If you did your homework, and read Rick Boatright's excellent article in Grantville Gazette, Volume 2, you'd realize that there will, very quickly, be quite a lot of telegraph wire being generated, and pulled around the countryside. What, then, is telegraph wire? Well, it's either iron or copper wire, with repeaters. A telegraph is really just a device that sends an analog signal of dots and dashes separated by blank space across that wire. Hmmm. Dots and dashes you say? Sounds an awful lot like 0s and 1s - binary bits. So, why not find a way to take advantage of all this iron wire being put up around Europe—and push IP network data across it instead of manually-driven telegraph key data?
In addition, you might have noticed the comment above about radio data communications. Since most of the radio traffic in the 1632 universe is Morse code (also known as CW — continuous wave), you run into the same objections to sending computer data via radio as you do to sending that computer data via telegraph line. Solve the problem of how to connect a computer to a telegraph line, and you can use that same solution to connect computers via radio = at least so long as you can establish radio communications. Which bring us to our next problem.
Building the Network: A Telegraph Modem
A modem (modulator-demodulator) is, at this point, a handy term for any device that interfaces between a computer and an outside network. The reality, of course, is that a modem is a fairly specific device term—if you're a techie.
In our case, however, what we need to build is a device that allows a computer to talk across a telegraph line. Fortunately, it's actually not all that hard to build such a device, or to control it from a computer. Using a simple combination of the computer's serial or parallel port, some custom programming, a solenoid, and an otherwise-standard telegraphy key, you can get the computer to "talk" to the telegraph line. In reality, automated telegraphs were commonly available by the end of the 19th century. In our case, the only difference is how we choose to control it. Of course, once we have a design for a telegraph modem that works on a telegraph line, that we can build using 1630s-available materials, we also are only one step away from having the ability to send data over a radio link, using exactly the same implementation. Only the transmission medium differs.
After hammering this particular design out over a period of time, it appears that a telegraph "modem" capable of about 60 bits per second is possible by the early 1634. Further, it appears that multiple telegraph modems can be controlled from a single computer, up to a maximum of about 6. Using multiplexing technologies, and assuming that only 4 channels are used, a rough equivalent to a 300 baud modem can be implemented. Combined with modern data compression algorithms (everyone remember .zip files?), we can get an effective network speed of close to 1 kilobit for highly-compressible data (like those text-file emails we mentioned) over the main trunks, and about 200 bits/second over a single-line side connection. This gets us a networking/email capability approximating what you would see in the early 1980s.
Network Architecture
Now that we know what kind of potential capabilities we have, we can start working on what kind of network to build.
Metropolitan Networks
We know at this point that, using regular telephone wire and existing computers, we can build a 10 Megabit network covering a small town—for example Grantville, Magdeburg, or downtown Prague. Since most of Grantville is wired for telephone, it would be entirely possible to connect the bulk of the town into a single large-size Ethernet network. Not great, not perfect, and certainly something that would give the IEEE fits—but it's entirely possible. Any other town that's wired using similar capabilities will wind up being capable of running a similar network. Further, we can go a bit further out using modern modems over telephone wire—that only gets us 56 Kilobit networks, but that's a lot better than the alternative.
Regional Networks
Outside of these towns, we'll be forced to fall back to slower networking capabilities, either using modern modems or using the telegraph modems we discussed above. This also means that connecting between the various cities will be rather slower—in that range of 60-300 bps that we discussed above.
So, What Does the Internet Probably Look Like in 1634?
Based on all this, there are three "classes" of internet by 1634.
The best network (Class A) is going to be the network that exists in a small, defined area like Grantville. There, the Internet will look and act a lot like in our world, in the year 2000. Perhaps not all the bells and whistles—no popup advertising, for example—and the content might be a little more limited. But it will still be there, and it will be roughly as fast as any office network of the 1990s.
The next best network (Class B) will be those computers a bit too far out from the central network core to run any form of Ethernet communications, but still close enough to reach the network using a regular telephone modem. They'll be able to get a dialup connection. For these users, network speed will vary depending on distance of the telephone connection. Anecdotally, however, I've been told that the residents of Skagway, Alaska can get 14 Kilobit connections, dialing out over 40 miles of 1940s-era telephone cable to Anchorage.
Finally, we come to the Class C network. This is going to be dependent on the IP-over-telegraph connection. It may not be fast (certainly not at 300 baud), but it will work, and it will move data around. Slowly, perhaps, but it will still work.
Great! What Can You Do With It?
The first, and most important thing to realize, is that at best, the Internet in 1634 will have capabilities that don't even measure up well to those available in the early 1970s. In terms of computing hardware, the systems available to Grantville are actually much more capable than the 1970s mainframes. But the network? There, you're looking at something that's less capable. That being said, you'll be handling less traffic—less business—than 1970s networks were dealing with.
Which means, once all is said and done, that a fairly large number of 1970s approaches will make a great deal of sense as applied to Grantville's Internet. Here's a few examples:
Email: Since email is a relatively low-impact communication form, it will be readily available and adaptable to the network we're discussing.
Batch data processing: There are a huge number of operations where you would send in a set of data for computation to a "mainframe," then work from the results. Bank account processing, construction engineering number crunching, even fluid dynamic calculations for airplane and ship designs (the equivalent of a wind tunnel or water tank test).
EDI: An early form of ecommerce, Electronic Data Interchange used text message files to accomplish a huge amount of electronic commerce traffic—mostly business-to-business or business-to-government. But there's a fair amount of this kind of thing that will be of use in the USE's government, and in dealings with and between the various larger commercial entities.
What won't you have? Well, you might have webservers in each city, but you certainly won't be connecting to them across those trunks—downloading a single web page would swamp the connection.
Similarly, moving large files across the network will probably be relegated to "on a disk, with a courier" rather than going out online. You might note that this echoes something done by a group of guys working at Terraserver recently. Rather than paying for several T-3 (45 Mbit) connections, they started shipping 2 Terabyte servers around through Federal Express—sneakerneting, to use an old industry term. It turned out that this solution was much cheaper, as well as being much quicker. In our case, we'll have to use something other than Federal Express—a railroad courier, perhaps, or a plane from the USE Air Force—and a rather smaller disk—perhaps a 100Mbit ZIP disk.
So, How Fast Is This?
One question that's been asked is, how fast is this system going to be, in real terms? Allow me to illustrate.
Let's say that Mr. A, in Grantville, wants to send email with a 8kb text document (about 3 pages, single-spaced) to 4 people in the USE using this system. Mr. B is also in Grantville. Mr. C is in Rudolstadt, on the other side of a telephone modem. General D is in Magdeburg, on the other side of the four-telegraph-line trunk. And Herr Doktor E. is in Jena, on a single-line telegraph connection.
Expected Transmission times:
- Mr. A to Mr. B (Grantville-Grantville, 10Mbit ethernet): less than a second
- Mr. A to Mr. C (Grantville-Rudolstadt, 14Kbit dialup): about 6 seconds
- Mr. A to General D (Grantville-Magdeburg, 300 bit trunk with compression): about 45 seconds
- Mr. A to Doktor E (Grantville-Jena, 60 bit branch with compression): about 4 minutes
Wait! What About the Old Computers?
Remember all those old computers we mentioned, that were essentially scrap? It turns out they're still useful. At one level, they're useful in the "something is better than nothing" realm—even a 1980 TRS-80 is still vastly more powerful than a notepad and pencil for calculation work.
But there's another realm where they also have a useful life—as access terminals to high-end computers. The simple reality is that a single, circa 2000 Pentium 3 Xeon server has as much or more computational horsepower as a circa 1990 Cray C90 supercomputer. That same 1980 TRS-80 would provide a useful front-end terminal to that Xeon server, allowing additional users to get their work done, and providing them with access to a much more powerful machine than the TRS-80 would be by itself.
References:
Building a router with a low-end PC: http://www.enterprisenetworkingplanet.com/netos/article.php/1107911
http://www.enterprisenetworkingplanet.com/netos/article.php/1141271
Ethernet over barbed wire: http://slashdot.org/articles/02/01/03/2039218.shtml
http://www.isp-planet.com/cplanet/business/0009piscitello.html
IP via carrier pigeon: http://www.blug.linux.no/rfc1149/
2 Terabyte Sneakernet: http://taint.org/tag/ups
Batch Data Processing: http://en.wikipedia.org/wiki/Transaction_Processing_System
History of EDI: http://www.123edi.com/edi-101.asp
Comments
Post a Comment