COMM525/Comparative study of Fidonet and USENET

From Driscollwiki

Jump to: navigation, search


Driscoll, K. (2009). "A comparative study of Fidonet and USENET". COMM525

Contents

Abstract

Fidonet and USENET represent separate and simultaneous efforts to implement decentralized messaging services among two largely distinct classes of computer users. This study considers each project as a platform for machine-machine communication, a subject as rhetorical as it is technological. Comparative analysis indicates that computing platforms and networking protocols, like rhetoric, reproduce the social and cultural contexts within which they were developed.

Routing: A comparative study of Fidonet and USENET

In 1983, two distinct groups of computer programmers began to develop systems for exchanging mail messages and news articles among geographically-dispersed users and machines (McCarthy, 2001; Scott, 2005). Although their parallel solutions, Fidonet and USENET, each achieved widespread adoption by the end of the 1980s, historical accounts of the internet routinely exclude the people, culture, and technology of Fidonet while conducting comprehensive historicization of USENET. Comparative analysis of the two messaging platforms reveals rich detail concerning the social, cultural, and economic circumstances of their development. In short, participation in USENET required access to a large industrial, military, or university computing facility while Fidonet was operated out of the homes of volunteers using affordable microcomputers. The findings of this study indicate that many narrative histories of the internet marginalize the pioneering work of hobbyist users by focusing exclusively on the activities of a comparatively small group of industrial, military, and academic researchers.

Platform

Distributed messaging systems such as Fidonet and USENET are not discrete technological objects but social/technological abstractions that represent the multi-faceted interactions of people, programs, machines, and protocols. The stacked "platform studies" model proposed by Montfort and Bogost structures analyses of digital media according to five interrelated layers bound together by a shared cultural and historical context (2009). (See Figure 1). At the top of the stack, the "reception/operation" and "interface" layers welcome analyses of users' experience of a given phenomenon. The next two layers, "form/function" and "code", concern the design and implementation of a media system or text. The final, "lowest" layer is "platform", an "abstraction beneath code" the characteristics of which determines the fundamental affordances and constraints of the entire system (Montfort & Bogost, 2009). Though the present study engages each level of Montfort and Bogost's model, special attention is paid to Fidonet and USENET as unique "platforms" for distributing messages among geographically-dispersed users.

levels.gif Figure 1

Of the five layers, platform most strongly demands examples to illustrate its meaning. In Montfort and Bogost's analysis of the Atari VCS, "platform" refers to the hardware components of the gaming console (2009). As the lowest layer in the stack, platform changes radiate upward through each of the higher layers. Platforms are not rigidly bounded and may overlap, subsume, or combine with other platforms. For example, both Fidonet and USENET rely on pre-existing communication technologies to send, receive, store, sort, and route their messages. Many of these components could be studied as platforms independent of each other. Considering them as a single entity enables the study of their interrelationships.

Protocol

For Fidonet and USENET to work, developers needed a reliable mechanism by which two machines could reliably exchange messages. Beyond the basic hardware requirements (cables, radios, etc.) a standardized protocol had to be found or developed to govern all machine-machine interaction. A protocol, in this scenario, is a strict set of rules by which two machines conduct a transaction. Machines enact the protocol based on code written by a programmer but the protocol exists independently of the code used to express it. Heterogeneous computing environments underline this distinction as the same protocol must be coded repeatedly to account for the differences in hardware and software among various computing platforms.

In Protocol, Galloway uses the strict uniformity of networking protocols to challenge critics who read decentralized media systems like the Internet as sites of liberation (318). Galloway cautions that rather than break down hierarchies of power, decentralized networks create "new robust structures for organization and control" (318). By requiring the use of rigid protocols to participate, networks such as the Internet offer their users no alternative to the "society of control" first theorized by Deleuze (319). Interaction, presumably a prerequisite for technologically-aided liberation, is thus "co-opted" as strict protocols permit invasive surveillance by traditionally dominant institutions (319).

This study proceeds from a similar assumption as Galloway; protocol and platform are not inert artifacts. Media systems such as Fidonet and USENET are encoded by and tend to reproduce characteristics of the social and cultural context within which they were developed. Galloway argues that the window of emancipatory opportunity for decentralized networks has passed (318). In response, he calls for critical investigation into "protological control" as well as the development of "counter-protological practices" (319).

The present study notably departs from Galloway's critique in its subject matter. Galloway appears primarily concerned with the most common protocols of the Internet (TCP/IP, HTTP, FTP), each of which was developed within the same confluence of industrial, military, and academic funding and control as USENET (Hafner & Lyon, 1996). By contrast, Fidonet was initiated from within a community of hobbyist computer users by a self-described anarchist (Boorsook, 1996). To what extent might other popular computing practices be obscured by a dominant narrative of internet history that focuses exclusively on the protocological products of military-funded academic research?

Rhetorical criticism as moral action

As much as protocols govern the flow of "bits and atoms" through distributed networks (Galloway, 319), they also constitute the terms of a machine-machine rhetoric. Acknowledging interpenetration between rhetoric and the social order (Klumpp & Hollihan, 1989) this study extends the moral imperative of rhetorical analysis to the critique of machine discourse. Protocological control is not only a disciplining of the human/user but of the machine itself. Machines for which no implementation of a protocol has been written are not able to engage with the network. Similarly, protocols may be constructed in such a way as to exclude whole classes of machines, and by extension, the human/users who surround them. To engage with the rhetoric of machines may be to locate a morality among them.

Galloway decries the extent to which everyday life is "captured" by a mandatory participation in decentralized networks, be they internet-based, mobile phone, or otherwise (319). This study seeks to ameliorate the potential alientation of network-bound living by peering around the wizard's curtain at some of the protocols governing network activity. Humanistic readings of technological artifacts can serve as interpretive guides into the imperfect processes through which protocols are developed; a literacy project for challenging the implied passivity of Galloway's critique.

Historical context

Montfort and Bogost insist on the consideration of platform in analyses of media phenomena (2009). Their construction of platform as a fundamental governing abstraction is supported by Galloway's definition of protocol as a technology of "organization and control" (2004). The platforms discussed below, both of which include a variety of protocols, are as much rhetorical as technological phenomena. They are encoded with the social and cultural circumstances of their construction and should thus be subject to a socially-bound rhetorical critique (Klumpp & Hollihan, 1989).

This study concerns a variety of technological circumstances which are bound to be unfamiliar to many readers. One important distinction to keep in mind is between mini- and micro-computers. The minicomputer is "mini" only in the context of mainframe computers that might occupy an entire room. By 1983, a minicomputer might have sat on a sturdy desk or in a small cabinet (See Figure 2), but it was rarely purchased by individuals and was most likely found in the computing facilities of a large corporation, university, or government institution. Microcomputers on the other hand, were comparatively affordable, less powerful home machines. In the years leading up to this era, micros were as often built from kits as purchased pre-assembled. Though the success of the Apple II foreshadowed its eventual popularization, home computing in 1983 was still a rather niche hobby (Levy, 1984).

pdp11-23.jpg Figure 2

Most early computer systems were not designed to communicate with each other. Moving data between systems, regardless of their similarity, typically involved some kind of intermediate storage: floppy diskette, magnetic tape, or a box of punch cards. Neither UNIX nor CP/M, the most popular mini- and microcomputer operating systems of the time included communication software "out of the box" (Kelty, 2008, 139).

This is not to say that direct machine-machine communication was technically infeasible or uncommon in 1983. To the contrary, the military-funded ARPAnet connected labs at UCLA, Stanford, UC Santa Barbara, and the University of Utah as early as 1969, the workstations in Xerox PARC's offices had been connected locally via high-speed Ethernet since 1973, and Ward Christensen's homemade bulletin board system was serving data over telephone lines in 1977 (Scott, 2005; Waldrop, 2001). Indeed, the capacity for widespread, geographically-dispersed computer communication existed. It was simply yet to be broadly implemented.

Written in C, highly-portable, and well-documented, UNIX was the preferred operating system of many university Computer Science departments (Lucent Technologies, 2002). Microcomputers of the time were not powerful enough to handle the demanding time-sharing software but compatible versions of UNIX were available for all of the popular minicomputer platforms. From the start, UNIX, a "time-sharing" operating system, supported resource sharing among multiple simultaneous users but it was not until version 7 that it began to include tools for communicating with other UNIX systems.

USENET

Tom Truscott, a graduate student at Duke University, was one of an emerging generation of young UNIX fanatics. During his 1979 summer break, he worked at AT&T Bell Labs alongside UNIX architects Ken Thompson and Dennis Ritchie, an environment he described as "the very root of UNIX itself" (Hauben, 1998). Truscott was not only exposed to cutting-edge research but to the hacker's culture of late nights, joyful problem-solving, and the pursuit of algorithmic elegance. Upon returning to Duke, he was eager to stay in touch with this community and arranged for a nightly email transfer between Duke and Bell Labs (Hauben, 1998).

The initial development of USENET began in the fall of 1979 as a conversation between Tom Truscott and Jim Ellis, a fellow Duke graduate student. The pair were frustrated at the infrequency with which the UNIX community was able to gather in person. They imagined a system for file-sharing outside of the small, tightly-controlled ARPAnet (McCarthy, 2001). Such a project might galvanize the UNIX community by enabling asynchronous collaboration and communication among geographically-dispersed institutions.

After a few brainstorming sessions to determine the characteristics of this new protocol, Steven Bellovin, a graduate student from the University of North Carolina, Chapel Hill, wrote the first implementation that would eventually become USENET. By bootstrapping existing UNIX utilities for transferring files and making system-wide announcements, Bellovin's program enabled users to exchange mail messages and publicly-viewable news articles between the two campuses. Jim Ellis announced the project at a UNIX user's conference in Winter and more sites were added to the growing USENET. Shortly after, Steve Daniel, another Duke graduate student, determined a structure for grouping messages according to subject and implemented "A-news", the first widely distributed USENET software (Hauben, 1998).

USENET grew out of a collaborative project among graduate students at Duke and the University of North Carolina, Chapel Hill. The cost of development was indirectly borne by the departments supporting each of the graduate students. Fred Brooks, then a computer science professor at UNC, provided funding for a leased line connection between the two campuses (Hauben, 1998). As the software was designed for use on costly UNIX systems, nearly all of the early users were similarly affiliated with large institutions.

Fidonet

In 1982, Tom Jennings, a self-taught engineer, learned systems programming for microcomputers on the job at Phoenix Software Associates. His primary challenge was to write very low-level software to enable the installation of MS-DOS on a diverse array of home computing architectures (Jennings, 2006). With this background, he wrote Fido, a portable bulletin board system for microcomputers running MS-DOS. A year later, Jennings began to conceive of a "bulletin board to bulletin board message thing" in which files and messages could be shared among many geographically-dispersed Fido BBSes (Scott, 2005).

The typical BBS system consists of a microcomputer, modem, and dedicated telephone line. Remote users dial into the system to asynchronously exchange messages and files with one another. The first bulletin board system, or BBS, was implemented during a blizzard in 1978 by Ward Christensen. He intended to use it as a distribution platform for the local computer club's newsletters (Scott, 2005). Many, if not most, BBSs were similarly run out of the homes of microcomputer hobbyists.

Like the pre-UNIX mainframe and minicomputer environments, the early microcomputer ecology was largely unstandardized. Software written for one platform could not necessarily run on another. The popularity of BBSing reflected a desire for platform independence among home computer users. Through the implementation of publicly available protocols such as XMODEM, BBS users could communicate and share files across micro architectures.

Instead of being divided by hardware or operating system as they were in the software market, BBS users were geographically segmented by the prohibitive cost of long-distance calls. Callers to distant BBSs frequently scheduled their usage around the local telephone company's pricing structure; calling late at night to avoid peak-time charges. A developer like Jennings, however, routinely called long-distance BBSs running his software to socialize, deliver updates, and troubleshoot bugs (Scott, 2005).

In the early 1980s, most BBSs were run not-for-profit by people like Christensen, computer hobbyists with a desire to communicate. Some BBSs solicited donations or subscription fees, but these measures appear to have been most often used merely to defray or redistribute maintenance costs. As a result, cost was the principle design constraint for the construction of Fidonet. Jennings makes this clear from his very earliest writing about the project, "If an ingenius way of paying for it doesn't exist, then it all falls flat" (Jennings, 1984).

Case study

In the early 1980s, Jennings and Truscott faced a similar challenge: to devise a messaging system that enabled communication among a large group of geographically-dispersed users. The solutions they developed reflect the differences between their technological, cultural, and economic circumstances. While Truscott could assume a degree of institutional financial support and platform uniformity, Jennings' solution had to cost nearly nothing and function reliably across countless incompatible systems. By analyzing the development of Fidonet and USENET at the levels of platform and code, this study investigates the operationalization of priviledge at the same time as it celebrates the realization of user-centric computer-mediated communication systems.

The artifacts considered in this study include technologies, protocols, technical specifications, and interviews with the developers. In both cases, the platforms were designed to accomodate a variety of interface implementations so this study avoids discussing the features of specific client software. It also does not cover the content of messages in either Fidonet or USENET, nor does it discuss the emergence of specific forum hierarchies. As these artifacts were gathered, it became increasingly apparent that there exists a tremendous research opportunity in the various governance strategies that were implemented as the networks grew to include 100s and 1000s of nodes.

The development of USENET was documented through the publication of RFC (Request for Comment) papers. Originally circulated in hardcopy, RFCs are the primary reference materials for technical details of the protocols governing Internet communciation (Kelty, 2008). This study draws heavily on RFC 850, "Standard for Interchange of USENET Messages" and RFC 977, "Network News Transfer Protocol" (Horton, 1983; Kantor, 1986). Each document provides a description of the platform with sufficient detail to enable a curious reader to implement compatible software.

RFC 850 is based on the "B-news" implementation of USENET, a complete rewrite of Steven Daniels' "A-news" program by Matt Glickman and Mark Horton (the author of this RFC). It explains that, unlike some of the other Internet technologies, news transmission is not an entirely standardized protocol. Instead, the process is flexible to accomodate implementations on a variety of configurations (Horton, 1983). For example, hosts without persistent network connections might "batch" groups of USENET messages rather than send them individually as they are written. 

Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
From: jerry@eagle.uucp (Jerry Schwarz)
Newsgroups: net.general
Subject: Usenet Etiquette -- Please Read
Message-ID: <642@eagle.UUCP>
Date: Friday, 19-Nov-82 16:14:55 EST
Followup-To: net.news
Expires: Saturday, 1-Jan-83 00:00:00 EST
Date-Received: Friday, 19-Nov-82 16:59:30 EST
Organization: Bell Labs, Murray Hill

The body of the article comes here, after a blank line.

Figure 3. A sample USENET news article (Horton, 1983).

The format for USENET news articles defined in RFC 850 (See Figure 3) reflects the core purpose of the USENET project: to bring together a geographically-dispersed UNIX community. Rather than design a new format, the USENET article simply extends the existing format of ARPAnet mail messages defined in RFC 822 (Horton, 1983). Extending the ARPAnet format was a strategic design decision with both technological and social implications. By building on an established data model, tools for reading and writing ARPAnet messages could be quickly adapted to also handle USENET articles thus easing the adoption process among UNIX users.

The emphasis on the UNIX community is also evident in the assumption that most USENET implementations will use UUCP to transmit files between machines (Horton, 1983). UUCP ("Unix-to-Unix Copy"), first included in UNIX Version 7, was a program capable of transferring data according to several different protocols (Taylor, 2000). This assumption was another contributing factor to the rapid adoption of USENET. As long as both the sending and receiving machines were running UNIX version 7 or later, they would be able to exchange USENET news via UUCP. Of course, while was an advantage for bringing UNIX systems onto the network, it also prevented users of non-UNIX systems from being able to participate.

With UUCP governing the transfer of news from one machine to the next, the first few years of USENET employed a "store and forward" networking design (Anderson, 2005). During this period, users would check the latest news and compose responses periodically throughout the day. Each response, formatted according to RFC 850, was collected into a single file containing the day's news. Periodically, the machine would either call or receive a call from a neighbor on the network. The calling machine would offer its batch of new mail and request any new mail stored on the answering machine.

This type of "store and forward" network is "extremely resilient to disconnection" and thus well-suited to environments in which there is no persistent data connection between machines (Anderson, 2005). As most of the participants in USENET were initially connecting to one another using conventional telephone lines, occasional transfer failure was to be expected. The primary disadvantage to this system is that propagation of individual messages through the network could be quite slow, especially to and from systems that only exchanged their news batches once or twice per day.

The exchange between neighboring machines was governed by the "ihave/sendme" protocol laid out in RFC 850 (Horton, 1983). This protocol was designed to speed up the propagation of individual messages by limiting the overall volume of redundancy. After an initial "handshake" sequence in which each machine is identified, the calling machine would prompt the answering machine with "ihave" followed by one or more unique message IDs from its batch. The answering machine would look up each ID in a table of message IDs it had previously seen and respond with "sendme" followed by the IDs of any unread messages. Only after receiving the "sendme" message would the calling machine transfer any message data. Unfortunately, the process of exchanging and looking up IDs was often as slow or slower than blindly transferring the entire batch and sorting it out on the receiving end (Horton, 1983).

After more than five years of operation, the number of systems running "B-news" was quite large and UUCP was becoming the primary bottleneck to scaling USENET further. To address this weakness, Brian Kantor and Phil Lapsley published RFC 977, the "Network News Transfer Protocol", or NNTP, in 1986. NNTP was a "stream-based" protocol for transmitting USENET news using the fast, persistant, and reliable Internet connections that were now in place at many sites. Although NNTP no longer limited USENET to UNIX systems, Kantor and Lapsley were still not imagining home computer users joining the network. Instead, RFC 977 described mixed environments of multi-user workstations connected to a central server as might have been found in a "university or large industrial environment" (Kantor, 1986).

The implementation of NNTP replaced the once-per-day, store-and-forward network characteristic of UUCP with a resident, always-on interactive exchange. NNTP was frequently run as a background process on the central server; exchanging news regularly day and night. In a typical internet-based arrangement, the TCP port 119 was dedicated to the transfer of USENET news. The improvements of NNTP reflected not only a general increase in networking capacity among USENET users but also the social value that those users had invested in USENET. In other words, the transition from UUCP to NNTP was as much a cultural shift as a technological one. The publication of RFC 977 and assignment of a dedicated TCP port placed USENET among the high canon of Internet services: FTP (ports 20 and 21), telnet (23), SMTP (port 25), HTTP (80), etc.

From the start, Tom Jennings developed Fidonet a transparent, public manner by regularly posting draft design ideas and soliciting feedback from the users of his Fido BBS software (Jennings, 1984). Though a committee was eventually formed to publish the Fidonet Technical Standards (FTS), the early development process was documented by informal archivists along the way. Many more ephemeral artifacts of the Fidonet development process survived compared with USENET. Whereas USENET was developed by geographically-proximate graduate students meeting in person, the details of the Fidonet design were debated through electronic messages posted to public BBSs (Scott, 2005).

Jennings' initial Fidonet design was based on a couple of technological assumptions. First, he imagined that that all nodes would be run on similar hardware as his Fido BBS software; 8-bit microcomputers connected via modems to dedicated phone lines. On top of this basic architecture, they would be running a non-real-time operating system like CP/M or MS-DOS (Jennings, 1984b). Unlike the time-sharing UNIX operating systems which could continue to serve users' needs while they exchanged messages, Fidonet nodes could not handle any other tasks while exchanging messages.

Beyond the technical constraints of microcomputer architectures, Jennings' primary concern was cost (Jennings, 1984). He observed that most BBSs were run independently by hobbyists. Not only did they very few BBS operators earn money from their hobby, most system operators (or "sysops") spent money out of their own pockets to maintain their bulletin boards. If Fidonet were difficult to setup or costly to maintain, Jennings reasoned, it would fail.

Minimizing cost became the organizing principle for the design of Fidonet (Bush, 1992) and the primary cost of running a Fidonet node came in the form of long-distance charges. Should the machine need to exchange messages with a distant BBS, its sysop would be charged for each minute that it stayed on the line transferring messages. In order to avoid hefty phone bills, the transactions between machines had to be "extremely short" (Jennings, 1984b).

In 1983, the most common protocol for exchanging files among microcomputers was XMODEM. Authored by Ward Christensen, founder of the first BBS, XMODEM was not terribly different from some of the protocols included in UUCP (Jordan, 1983). It included a simple mechanism for detecting the kinds of transmission errors that regularly occured when transferring data across noisy telephone wires. Jennings early writing suggests that even this minimal error-checking might be too costly (Jennings, 1984). He hoped that all data processing could happen off-line to minimize the amount of time spent idle on the call.

Ultimately, XMODEM was implemented as the default protocol for Fidonet file-transfer for the same reason the the USENET team choose UUCP. As the "de facto" file-transfer protocol, XMODEM's portability and accessibility overwhelmed the disadvantage of its relative inefficiency (Jennings, 1983). Christensen cites three reasons for XMODEM's success: early development, simplicity of design, and placement in the public domain (Forsberg, 1985). Furthermore, XMODEM was easy to implement on microcomputer platforms because its error-detecting "checksum" algorithm could be expressed in BASIC on machines with very little memory.

Unlike the leased lines that connected university computers at Duke and the University of North Carolina, Chapel Hill, the telephone lines leading out of Christensen's house were noisy and data was frequently lost or distorted in transfer. To address this problem, Christensen implemented a simple asynchronous parity error detection algorithm and a protocol that would repeatedly resend missing data in the event of a transmission error. Chuck Forsberg later improved upon XMODEM by adding a more robust error detection algorithm and support for newer communications hardware (Forsberg, 1985). In the tradition of Christensen's XMODEM, Forsberg released his revised protocol into the public domain as YMODEM. 

        XMODEM Protocol File Transfer


Receiving                                      Transmitting
Computer                                         Computer
Ready to                                         Ready to
Receive                                          Transmit
   |                                                |
   |                                                |
   |---------------------\NAK\--------------------->|
   |                                                |
   |<------/SOH/Blk #1/Blk #1/Good Data/CkSum/------|
   |                                                |
   |---------------------\ACK\--------------------->|
   |                                                |
   |<------/SOH/Blk #2/Blk #2/Good Data/CkSum/------|
   |                                                |
   |---------------------\ACK\--------------------->|
   |                                                |
   |<------/SOH/Blk #3/Blk #3/Garbled Data/CkSum/---|
   |                                                |
   |---------------------\NAK\--------------------->|
   |                                                |
   |<------/SOH/Blk #3/Blk #3/Good Data/CkSum/------|
   |                                                |
   |---------------------\ACK\--------------------->|
   |                                                |
   |<--------------------/EOT/----------------------|
   |                                                |
   |---------------------\ACK\--------------------->|
   |                                                |
   V                                                V

  File                                             File
Receipt                                          Transmit
  Ends                                             Ends

Figure 4. ASCII illustration of a typical XMODEM transfer session (Jordan, 1983).

Not only was the XMODEM protocol easy to express in the preferred programming language of microcomputer hobbyists, its output was downright legible. By using short strings of three-letter abbreviations in ASCII rather than a numeric code, the record of two machines communicating with XMODEM reads like the transcript of an uneventful exchange between telegraph operators <rel>Chuck Forsberg, like many of the early BBS operators and microcomputer hobbyists, was a licensed amateur radio operator and would have been conversant in Morse code.</rel> (See Figure 4.) What follows is a narrative description of a typical XMODEM file-transfer session adapted from an article by Larry Jordan (1983). Assume that the two machines have already connected.

When it is ready to accept data, the Receiving computer begins to transmit NAK (meaning, "Negative Acknowledgement") every 10 seconds until the Sending computer initiates a transfer. If, after 9 tries, no transfer is initiated, the Reciever assumes that the line is dead and disconnects. To initiate a transfer, the Sender transmits SOH ("Start of Header") followed by two block numbers, a 128-byte block of data, and a "checksum." [1] The Receiver calculates its own checksum based on the data it has received and compares it to the expected checksum. If they are equal, the Receiver assumes that the transfer was successful and begins to transmit ACK ("Acknowledge"). If they are not equal, the data block is discarded and the Receiver transmits NAK instead. Once again, the Receiver waits 9 cycles before disconnecting. Depending on the result of the previous trasmission, the Sender either transmits the next data block or re-transmits the previous block. If there are no more data to send, the Sender transmits an EOT character and both machines disconnect.

The decision to implement XMODEM was politically significant above and beyond its technological affordances. Unlike most of the other available communication protocols, XMODEM was developed outside of the dominant computing research institutions. The human-readable syntax is an anomaly among functionally comparable software such as the UUCP 'g' protocol. Christensen was not only a fellow microcomputer hobbyist but the first BBS sysop. To select his XMODEM protocol for the transfer of Fidonet data was to choose the product of a peer over the output of an inaccessible institution. While this decision may have extended the protocological embargo dividing Fidonet and USENET, it may also have strengthened the sense of investment and pride that long-time BBS operators felt for the network.

Jennings distributed the first working build of Fidonet and a preliminary list of nodes along with an update for the MS-DOS version of Fido BBS (Bush, 1992). At this stage, the basic Fidonet functionality was in place and messages could be exchanged between users of different BBSs. Fidonet employed a similar store-and-forward design as the UUCP implementation of USENET. Messages accumulated during the course of the day were dispatched during a single, automated call in the middle of the night.

In Jennings' initial configuation, Fidonet distributed private user-to-user messages from one BBS to another but did not distribute the contents of public discussions the way that USENET handled "news." As with USENET, further development of the platform was taken up by members of the user community. Fidonet "news" functionality was added in 1986 by Jeff Rush, the sysop of a Dallas-based Fido node (Bush, 1992). Soon, the volume of these messages was making the long-distance charges of the nightly transfer prohibitively expensive, a violation of Fidonet's low-cost design principle. To address this problem, Thom Henderson, another sysop, implemented a compression algorithm to reduce the size of the files being transferred (Hartman, 1986).

By 1986, USENET and Fidonet were functionally comparable: users of both systems could exchange messages from geographically-dispersed computers. In both cases, maintanence and future development of the platform had left the sole proprietorship of a single author or team and been taken up by passionate members of the community. Yet, for all of their similarities, the two platforms maintained some important distinctions. Fidonet, run by hobbyists and organized according to the principle of minimizing costs, was accessible to nearly anyone with a computer, a modem, and a telephone line. USENET, on the other hand, was becoming more isolated from the growing computing public as the adoption of NNTP asserted a protological barrier between the users of affordable home computer systems and those with access to expensive institutional computing facilities.

Scalability issues plagued the two messaging platforms because of similar flaws in their routing, addressing, and scheduling designs. The nature of these flaws, and the solutions chosen to correct them, offer revealing details about the social circumstances in which the networks were deployed. USENET/UUCP addresses initially took the form of sender-relative, end-to-end "bang-paths" (e.g. "hosta!hostb!hostc!receiver") that described the exact route a message should take to travel from sender to receiver (Anderson, 2005). This scheme assumed that, at any given time, users would have access to an accurate picture of the topological state of the entire network (Taylor, 2000). (See Figure 5.) Embedded in this assumption is a sense that USENET would always be a tight-knit service shared among a small number of familiar sites. To expand USENET beyond the initial few sites, manual bang-path routing and addressing had to be replaced by dynamic routing software and Internet-style "pathaliases" (e.g. "host!user"). 

  UUCP/USENET Logical Map  -   June 1, 1981 / mods by S. McGeady 11/19/81

            (ucbvax)
+=+===================================+==+
| |                                   |  |
| |                wivax              |  |
| |                  |                |  |
| |         microsoft| uiucdcs        |  |
| |  genradbo      | | |  |           |  |           (Tektronix)
| |     |          | | |  | purdue    |  |
| decvax+===+=+====+=+=+  | |         |  |
|       |   | |      |    | | pur-phy |  |                        tekmdp
|       |   | |      |    | |     |   |  |                           |
+@@@@@@cca  | |      |    | |     |   |  |                           |
|       |   | |  +=pur-ee=+=+=====+===+  |                           |
|    csin   | |  |   |                   |                           |
|           | +==o===+===================+==+========+=======+====teklabs=+
|           |    |                                                        |
|           |    |                    pdp phs   grumpy  wolfvax           |
|           |    |                     |   |      |        |              |
|           | cincy                unc=+===+======+========+              |
|           |   |        bio       |                                      |
|           |   |  (Misc) |        |            (Misc)                    |
|           |   | sii  reed        |    dukgeri duke34  utzoo             |
|           |   |  |    |          |         |   |       |                |
|      +====+=+=+==+====++======+==++===duke=+===+=======+==+=========+   |
|      |      |    |     |      |   |                       |         |   | u110
|    bmd70  ucf-cs ucf   | andiron  |                       |         |   |   |
|                        |          |                       |         |   |   |
|                  red   |          |                       |         |   | pyux
|                   |    |          |     zeppo             |         |   |   |
|       psupdp---psuvax  |          |       |               |         |   |   |
|                   |    |          | alice |   whuxlb      | utah-cs |   | houx
|                allegra |          | |     |     |         |   |     |   |   |
|                     |  |          | |     |     |         |   |  +--chico---+
|                 +===+=mhtsa====research   |   /=+=======harpo=+==+     |    |
|                 |   |  |  |               |  /            |            |    |
|               hocsr |  |  +=+=============+=/           cbosg---+      |    |
|    ucbopt           |  |    |                             |     |   esquire |
|       :             |  |    |                           cbosgd  |           |
|       :             |  |    |                                   |           |
|    ucbcory          |  | eagle==+=====+=====+======+=====+      |           |
|       :             |  |  |     |     |     |      |     |      |  +-uwvax--+
|       :             |  |  |   mhuxa mhuxh mhuxj mhuxm mhuxv     |  |
|       :             |  |  |                                     |  |
|       :             |  |  |        +----------------------------o--+
|       :             |  |  |        |                            |
|    ucbcad           |  |  |      ihpss    mh135a                |
|       :             |  |  |        |         |                  |
|       :             \--o--o------ihnss----vax135----cornell     |
|       :                |  |        |         |                  |
+=+==ucbvax==========+===+==+=+======+=======+=+========+=========+
  (UCB) :            |        |              |          | (Silicon valley)
     ucbarpa      cmevax      |              |        menlo70--hao
        :                     |              |        |    |
     ucbonyx                  |              |        |   sri-unix
                              |           ucsfcg1     |
                              |              |        |
Legend:                       |              |      sytek====+========+
-------                       |              |               |        |
- | / \ + + Uucp           sdcsvax=+=======+=+======+     intelga   zehntel
=           "Bus"                  |       |        |
o           jumps               sdcarl  phonlab  sdcattb
:           Berknet
@           Arpanet

Figure 5. An illustrated map of the UUCP network, 1981. Retrieved from: http://www.uucp.org/history/uucp-map-1981.html

Fidonet addressing and routing faced a different scalability weakness. From the start, BBSs connecting to Fidonet were assigned a unique Node ID. Tom Jennings managed a master list of Node IDs by hand and periodically sent out new nodelists to the various Fido BBSs. For the first year of its operation, Fidonet had no routing mechanism and a "topography [...] with as little organization as possible" (Jennings, 1984). Messages were batched according to their destination nodes and multiple direct connections would be made each evening. The nodelist quickly grew in number and geographic reach and the direct-dialing approach began to violate the low-cost principle. Depending on the intended destinations of the messages queued to be sent, a Fido BBSs might make multiple long-distance calls every night. In April of 1985, as the nodelist approached 500 entries, its maintainer, Ken Kaplan, called for a moratorium on new nodes (Scott, 2005).

To solve this problem, several Fidonet node operators "took off work" and gathered at the home of Ken Kaplan in St. Louis in August, 1985 (Scott, 2005). Using the NCAA conference map as a guide, they split the U.S. into several regions and developed a geographically-hierachical naming scheme that remains in use today. The new Fidonet naming scheme gave every user a unique ID on the system in the form of: Zone:Net/Node.Point (e.g. 1:516/66.3) (Anderson, 2005). The new addressing scheme enabled the Fidonet software to dynamically batch and route messages in such a way that only one node in a given network would be required to make a long-distance call (Anderson, 2005). This design dramatically reduced the total cost of operating a Fidonet node without compromising its global reach.

One feature of the initial Fidonet design that did not change was the maintainence of a master nodelist. Although this decision introduced some administrative complexity, it also protected Fidonet against top-down control. With a local copy of the master nodelist, sysops could elect to ignore the Zone:Net schema altogether and direct-dial only those BBSs with which it wished to transfer data. This capability reflected Jennings' self-professed anarchist political views (Bush, 1992). Any individual node or group of nodes could break off from Fidonet and operate autonomously outside the original structure. That this was not the case with the UUCP network may be due to the fact that no autonomous UNIX facilities existed or could be imagined at the start of the 1980s. [2]

The meeting of Fidonet sysops in Ken Kaplan's home provides rich historical detail to the process of engineering a scalable addressing solution. In Ben Baker's telling, he recalls that each sysop "took off work" to attend the meeting (Scott, 2005). This off-hand remark emphasizes the cultural grounding of the Fidonet project within a hobbyist community. While the USENET project depended on the structural support of military, industrial, and academic institutions, Fidonet represented the radical potential of loosely-coordinated volunteer labor. Internet historicization efforts that to overlook Fidonet and overstate the influence of USENET unjustly obscure the role that Fidonet played in establishing a foundation for contemporary norms and practices.

Though this study highlights the many detailed distinctions between its two subjects, there were many social and technological points of contact as well. Communication gateways between Fidonet and USENET were made possible by implementations of UUCP for MS-DOS and Fidonet for UNIX in the late 1980s (Bush, 1992). With minimal difficulty, users could exchange messages across the two platforms. Other gateways implemented TCP/IP for data transfer between Fidonet BBSs via the Internet instead of over telephone lines. These points of technological contact enabled Fidonet to span continents without bearing the financial burden of international dialing (Bush, 1992).

Socially, contact between the platforms does not appear to have been equally valued. While documentation of Fidonet occasionally includes references to USENET and the UUCP, similar artifacts from the USENET side do not make mention of the Fidonet (Bush, 1992; Forsberg, 1995). In an early criticism, Fido BBS user Richard Wilkes adopted a tone of frustration that microcomputer hobbyists were being "left out" of the internet (1984). He argued that Fidonet was relegating itself to a marginal status by choosing hobbyist protocols such as XMODEM rather than the "real" file-transfer protocols used at well-funded computing facilities. Wilkes' criticism was accurate but his prediction proved only half-true. Fidonet succeeded, whether by hubris or ingenuity, to reach nearly 40,000 nodes by 1995, a number that Wilkes believed impossible (Scott, 2005). But he was correct that protocological differences lead to a cultural marginalization of Fidonet. To date, the dominant narrative of internet history rarely makes mention of the hobbyist network; a problem that this study seeks to correct.

Summary

In 1983, USENET and Fidonet emerged as two different solutions to a similar problem. Each platform enabled users of one computer to exchange messages with users of other, geographically-dispersed machines. The means by which this task was accomplished reflect the social, cultural, economic, and technological circumstances within which they were developed. Fidonet, designed by a loose group of microcomputer hobbyists, organized their solution around the principle of low-cost administration. As a result, they implemented a topology that circumvented geographically-bound long-distance charges. The USENET project sought maximum participation from a growing community of UNIX programmers. To ease adoption, their solution extended tools and protocols that were already in use among their target population.

Platform, the abstract foundation of a digital media phenomenon, is as much a rhetorical as technological object. By limiting its analytical scope to the platform layers of Fidonet and USENET, this study enacts a morally-bound rhetorical critique as outlined by Klumpp and Hollihan (1989). Just as rhetoric is tied to the social order, so do platforms instantiate a particular set of social beliefs. Despite comparable functionality and reach, the reknown of USENET and relative obscurity of Fidonet effectively reproduce the hierarchies of power that structured the circumstances within which each platform was developed.

Several questions raised during the course of this study suggest rich opportunity for future inquiry. One wonders to what extent the success of Fidonet is anomalous among past media technologies. In particular, what other hobbyist efforts might be similarly obscured? Does historical emphasis on the preferred platforms of dominant institutions affect notions of possibility in the discourse of contemporary educators and policymakers? Could a comparative study locate similar parallel developments among hobbyist engineers and institutional researchers in other media spaces?

Fidonet was built using multipurpose microcomputer platforms and largely unregulated telephone lines. Recent changes in policy and technology recast the relationship between users and technologies as one between customers and services. "Trusted computing" platforms like many mobile phones and some popular operating systems restrict the extent to which users can tinker, modify, repair, and play with their devices. Likewise, the Digital Millenium Copyright Act enables technology manufacturers to take litigious action against hobbyists who find unexpected uses for their products. Would either Fidonet or USENET have been possible within this regulatory paradigm?

In one respect, today's internet is less protocologically diverse than it has been in over twenty years. With the web browser as most users' primary interface, nearly all information is, at one time or another, subject to the governing power of the Hypertext Transfer Protocol (HTTP). In this environment, future research cannot limit itself to historical examples. Galloway's call for the development of a "counter-protological" critique demands platform-level engagement with the technological substrate of the everyday media experience.

Footnotes

  1. ↑ Christensen's checksum is calculated by summing the ASCII values of each character in the 128-byte data block, dividing this number by 255, and keeping the remainder. In XMODEM, both the Sender and the Receiver calculate this value for a given block of data. If they match, then, presumably the transmission was free of error (Jordan, 1983).
  2. ↑ The union of Linux and the GNU Project in 1992 was the first time that a UNIX-like operating system could be run on home computing architecture. Parallel projects in the 1980s such as Fidonet/USENET foreshadow the blurring of protological boundaries between institutional and home computing that GNU/Linux would eventually bring about.

References

Retrieved from "http://www.kevindriscoll.org/wiki/COMM525/Comparative_study_of_Fidonet_and_USENET"
Personal tools