* * *
To Be Continued
So You Want to Build the Internet:
IP Communicatons in 1633
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 telegaph 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:
10BaseT wiring tutorial
http://www.netspec.com/helpdesk/wiredoc.html
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
Grantville Police Departme
nt
by John Zeek
In 2000, the Grantville Police Department was a typical small town police department. It consisted of a chief and five patrolmen, and a sworn juvenile officer. A study of the books 1632 and 1633 and a visit to the Grid reveals their names and ages.
Police:
Dan Frost (47; chief of police)
Ralph Onofrio, Jr. (42; police officer)
Marvin Tipton (49; police officer)
Delores (Agnew) Francisco (29; police officer)
Ricky McCabe (23; police officer)
Preston Richards (34; police officer)
Bernadette Adducci (44; juvenile officer)
Unlike many small town departments, Grantville has its own dispatchers. Most departments depend on the county sheriff's office. But Grantville was once a larger town than it was in 2000, so the radio system is a leftover from the glory days. There is also an office file clerk. Again, a trip to the Grid shows us the names and ages of the dispatchers and clerk.
Dispatchers and Clerk:
Mimi (Rowland) Carson (26; dispatcher)
Angela Baker, (27; dispatcher)
Jill (Duvall) McConnell (28; dispatcher)
Jim Watteville (28; dispatcher)
Vera Mae (Markins) Sanderlin (65; files and records management)
The Ring of Fire trapped two county officers who lived in Grantville, so they were added to the force and to the newly established court system. Again from the grid:
Julie Anne (Abruzzo) Drahuta, Child Protection Officer)
Fred Jordan (33; Deputy Sheriff) Assigned to liaison with other law enforcement.
As well, Maureen (Burns) Grady (35; VA social worker) joined the force as a child protection officer before moving to Magdeburg.
As soon as Grantville started to attract new down-time residents, the department was forced to expand by adding officers. Six were mentioned in 1632, none by name, but later stories in the Grantville Gazette have added nine names to the official canon.