Domain > www.dragonfire.net

More information on this domain is in AlienVault OTX

DNS Resolutions

Date	IP Address
2019-07-24	74.208.174.96 (ClassC)
2026-02-24	153.246.140.138 (ClassC)

Port 80

HTTP/1.1 200 OKDate: Tue, 24 Feb 2026 03:40:02 GMTAccept-Ranges: bytesContent-Length: 112167Content-Type: text/html

?xml version1.0 encodingUTF-8 ?>!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd>html>head>meta http-equivContent-Type contenttext/html; charsetUTF-8 />meta http-equivContent-Style-Type contenttext/css />meta nameformat-detection contenttelephoneno />  !-- Required to avoid iOS Safari adding phone number links to text in the system status display mockup -->title>Dragonfire Internet Services: A Retrospective/title>style typetext/css>@import style.css;@media (prefers-color-scheme: dark) { body { background: black; color: white; } a { color: #6666ff; } }  /* needed by Safari *//style>/head>!-- Revision history:2021/10/28   * Adjusted the CSS stylesheet for easier reading on mobile devices.   * Revised the section describing bugs in the Amiga HTTP server for     easier reading by those without programming experience.   * Minor text edits.2021/8/5   * Updated external links to use the HTTPS scheme.   * Minor text edits.2021/4/11   * Added 2021 Addendum.   * Added a definition of modem, since modern readers may not be     familiar with the term.   * Adjusted the stylesheet to add a small amount of space between     paragraphs, for (hopefully) easier reading.   * Minor text and formatting edits.2019/12/13   * Increased the size of the text so its a more reasonable size when     viewed with current browser software.  How the times have changed...   * Updated footnote 7 (regarding domain speculation) to reflect the     current state of the dragonfire.net domain.   * Fixed broken link to footnote 25.2015/2/2   * Minor text edit to clarify the fault in the Amiga HTTP server.2014/3/17   * Minor text edits.   * Added a footnote (footnote 14) pointing out that I neglected to     consider my own compensation when calculating Dragonfires operating     costs.2014/1/1   * Minor text edits.   * Added the date of initial writing (February 2008) to the title block.2013/6/1   * Minor text edits.   * Added a footnote (footnote 1) explaining the difference between baud     and bits per second.   * Added a footnote (footnote 12) explaining the technical difficulties     limiting bandwidth on the 10-megabit-per-second dormitory network.   * Added a footnote (footnote 18) pointing out how sysmon truncated some     of the values displayed in the screenshot.2013/3/29   * Minor text edits.2011/12/3   * Minor text edits.   * Reduced the size of the text so its a more reasonable size when     viewed with current browser software.   * Updated the sysstat and sysmon source code to work correctly with     current system libraries and in 64-bit environments.2011/4/24   * Minor formatting edits (s//’/g).2010/11/29   * Minor text edits.2010/4/16   * Minor text edits.   * Slightly increased the size of the footnote numbers to improve     readability.2010/3/27   * Minor text edits.2010/3/26   * Minor text edits.2010/3/24   * Minor text edits and factual corrections, including deleting a few     unnecessary parenthetical comments to avoid disrupting the narrative     flow.   * Replaced — with — to inform browsers that lines can     be broken after em dashes.-->body>div classtitle>img srcwebsite-1998/dragonfire.gif width400 height135 altDragonfire logo />h1>Dragonfire Internet Services: A Retrospective/h1>div classsubtitle>One College Student’s Experience with the Web Explosion/div>div classauthor>by Andrew Churchbr />February 2008/div>/div>p>From late 1995 through early 1999, I operated a small World Wide Webservice provider named Dragonfire Internet Services.  In days when personalmegabit-class connections were the exclusive province of college studentsand 10 megabytes of file space was considered huge, I endeavored to, in myown little way, help people take advantage of the new communications mediumknown as the World Wide Web.  While I don’t dare claim any part inhow the web grew during that time, my experiences may give a glimpse intothose formative years of the present Internet, so I have set down, as best Ican recall, the history of Dragonfire from my point of view.  I hope thatthe reader finds this retrospective as interesting as the experiencesthemselves were for me./p>!------------------------------------------------------------------------>hr />div classtitle>h2>Table of Contents/h2>/div>table classcontents>tr>td>a href#s-1994>1994: Dreams of Flight/a>/td>/tr>tr>td>a href#s-1995>1995: Cracking the Shell/a>/td>/tr>tr>td>a href#s-1996>1996: Care and Nurture of a Dragon/a>/td>/tr>tr>td>a href#s-1997>1997: Thrust into the Real World/a>/td>/tr>tr>td>a href#s-1998>1998: Growing Up/a>/td>/tr>tr>td>a href#s-1999>1999: Departing the Nest/a>/td>/tr>tr>td>a href#s-2000>2000 and Beyond: Final Thoughts/a>/td>/tr>tr>td>a href#s-2021>2021 Addendum/a>/td>/tr>tr>td>a href#footnotes>Footnotes/a>/td>/tr>tr>td>a href#resources>Resources/a>/td>/tr>/table>!------------------------------------------------------------------------>hr />div ids-1994 classtitle>h2>1994: Dreams of Flight/h2>/div>p>While Dragonfire did not come into existence as a provider until late1995, its story properly begins nearly one year earlier, on December 24,1994.  This was the day I obtained my first semi-permanent Internetconnection, via my high school’s dial-in lines./p>p>To provide some background for those unfamiliar with the technology ofthe day, personal Internet connections in the early1990s—for those few who had them—were made almost exclusivelyover standard, land-based telephone lines, using devices known as“modems” to convert data to sound and back again.  A typicalmodem of the time operated at 2400 bits per second (usually called“2400 baud”, though this usage of “baud” istechnically incorrecta idfootback-1 href#footnote-1>sup>1/sup>/a>);since each 8-bit byte was accompanied by two control bits, data transferwas limited to a maximum of 240 bytes per second.  At this rate, forexample, one could watch E-mail text appear line by line on BBSes orsimilar text-based systems. Transferring a five-megabyte audio recording,a file size which itself was gigantic for the time, would have takennearly six hours!/p>p>By 1994, higher-speed modems had begun to percolate down from researchlaboratories into the commercial world, and late that year I finallyobtained my own 19.2-kilobit modem.  The speed difference was amazing; fora 2008 equivalent, imagine switching from an unstable ADSL connection to adedicated fiber-optic link.  Not only were file transfers shortened by anorder of magnitude, but that speed also allowed me to work on a remotecomputer almost as easily as on my own system.  The display was notinstantaneous, but reading mail or editing programs was much more tolerablethan it had been; at least I no longer had to wait nearly ten seconds justto view the next page of a file./p>p>The use of a telephone line imposed one other restriction:  No voicecalls could be made or received on the line while the modem was in use.For a child like myself without the means to obtain his own line, this wasa critical problem:  I had to get my parents’ permission whenever Iwanted to connect to the Internet, and I had to limit my connection time toa minimum.  (From a parent’s point of view, on the other hand,I’m sure that made it much easier to keep tabs on the child’sactivities compared to today, when permanent connections are the norm.)  Asit happened, though, we had a second phone line installed for the smallbusiness my mother ran out of our house.  She had started to wind thebusiness down, so I became able to use that phone line for my own purposes,first on evenings and weekends, later 24 hours a day—though Idid end up paying for the line out of my allowance./p>p>Finally, there was the issue of how to connect.  My highschool—a hrefhttps://mbhs.edu/>Montgomery Blair HighSchool/a>, in Silver Spring, Maryland, USA—had (and presumably stillhas) a strong computer science curriculum, in which I was enrolled.  Theschool provided all of us in the curriculum an account on the school’smultiuser system, a MicroVAX at the time; in addition to accessing thesystem from the school’s computer lab, we could also use modems toconnect from home.  That served well enough for reading mail and Usenetnews, but it was not enough to run a server./p>p>At Blair, most of the system administration and management tasks werehandled by computer science students rather than by staff members.  In mysenior year of high school, which started in September 1994, I was giventhe task of managing the MicroVAX system.  While I had already learned abit about multiuser system administration from conversations withclassmates—some of whom were experimenting with a new operatingsystem called “Linux”—and from my own studies, this wasmy first direct experience with system administration.  It gave me a solidgrounding in many aspects of administration that would later prove useful:managing system resources, backing up data (onto the funny little squaretape cassettes the VAX used), and learning how to communicate with userswho didn’t necessarily understand why the system worked the way it did.That year also provided me with a rather embarrassing lesson on the darkerside of the Internet, or perhaps just a demonstration of my ownnaiveté, as I was completely taken in by the “GoodTimes” virus hoax that spread late in 1994; I did not learn the truthof the matter until after I had already warned the entire school about thedangers of the supposed virus./p>p>In any case, one of the perks of being a student system administratorwas privileged access to the school’s Internet connection via modem.Rather than only being able to log into the VAX, I was allowed to set up aSLIPa idfootback-2 href#footnote-2>sup>2/sup>/a> connection frommy computer at home to the school’s terminal server, gaining my own IPaddress.  With an IP address, I could connect to any computer on theInternet without having to go through the VAX, but more importantly, otherInternet users would be able to connect to my computer as well./p>p>With those three factors covered—and, of course, with my owncomputer: a Commodore Amiga 2000, of which I was quite fond for both itsease of use and its programmer-friendliness—the stage was set for theappearance of what would later become Dragonfire.  And on Christmas Eve,1994, a server known to absolutely nobody as tt>dragon.mbhs.edu/tt> madeits Internet debut./p>p>Being a bit of a computer music fan, I had amassed a fair collection ofmusic files (modules, or MODs, as they were often called) from various FTPsites.  At the suggestion of a friend, and following the Internet principleof sharing, I set up an FTP server on my Amiga, making those filesavailable to anyone who happened across the server./p>p>At the time, I certainly had no intention of turning my computer into aweb service provider.  I was aware of the World Wide Web, and it was usefulenough every once in a while, but there wasn’t really that much to see,after all.  About the one thing that piqued my curiosity at the time wasthe appearance of a company called Mosaic Communications, which released anew browser called MosaicNetscapea idfootback-3 href#footnote-3>sup>3/sup>/a>.  Everybodyknew Mosaic, of course; Mosaic was i>the/i> browser.  But what was a“netscape”?  If nothing else, the question evoked a number offascinating drawings on the computer lab whiteboard./p>p>In fact, setting the web aside, I didn’t really have any long-termplans for the server at all.  At the time, it was just a way to play aroundwith the Internet, to learn more about computers—and to make myself(and my computer) useful.  That last facet in particular would, just a yearlater, end up leading me places I had never imagined./p>!------------------------------------------------------------------------>hr />div ids-1995 classtitle>h2>1995: Cracking the Shell/h2>/div>p>As I entered the second semester of my final year in high school, webegan making plans to replace the outdated MicroVAX with a new multi-usermachine, a PC (a powerful 133 MHz Pentium, if memory serves) running Linux.This meant months of planning, creating procedures and scripts fortransferring user data between machines, and the like.  Looking back onmail I saved from that period, I must concede that, even compared to theother student system administrators, I had a rather cavalier attitudetoward the whole thing.  My recollection is that I managed the VAX itselfwell enough, but I didn’t take a very active part in any otheraspects of managing the school’s systems, chiming in onlyoccasionally with comments or program fragments I thought might beuseful—though more often than not they only served to illustrate thelimited extent of my own knowledge and point of view.  I may have been lessobjective about it at the time, but given my behavior during those days, Ican’t help but be amazed that such a teenager ended up administeringa web service provider just a year later./p>p>At the same time, I continued running my anonymous FTP server, arguingto the school’s computer staff that it was an educational use of theschool’s Internet connection.  Which it was, certainly; running aserver on one’s own, and making it available to the Internet atlarge, is a much different issue than merely helping administer a server onan effectively closed network.  Nonetheless, that claim was undeniably anexcuse to pursue my own interests in spite of school rules; I can only verybelatedly apologize for whatever trouble I may have caused the staff, aswell as for monopolizing one of the limited number of phone lines availablefor connecting to the school.  (I also unwittingly created the potential toconsume a full third of the school’s Internet bandwidth, only 56kbpsat the time, though my actual traffic never grew that high.)/p>p>June rolled around, bringing my high school years to a close.  Theswitch from the old VAX to the new Linux system went off reasonablysmoothly, and we shut the VAX down for the last time, ending my firstexperience with multiuser system administration.  I had already beenaccepted to Carnegie Mellon University, and I settled back to enjoy mylast two months before entering college.  Somehow or other, I managed tosecure continued Internet access through my high school until I left forCarnegie Mellon in late August./p>p>July brought my first experience with trouble I had to rely on others tofix:  Early in the month, the phone line I used to connect to the Internetsuddenly stopped working, leaving my computer isolated.  A call to thetelephone company and a couple of weeks later, the problem—a shortcircuit in the line—had been rectified; but for a seventeen-year-oldlike myself, especially one who’d been spoiled by an always-on Internetconnection, two weeks was practically forever.  I wheedled permission outof my parents to use our primary phone line at night, and managed to get myserver online for about eight hours a day, worrying all the time aboutpeople I was presumably disappointing with the downtime.  (Or so I recall,anyway.  It’s quite possible I had just made that up as an excuse tocover the “shock of withdrawal” from the Internet.)/p>p>At last it was August, and the time came to move out to college.  Ipacked up my Amiga along with various other belongings, and headed out formy first taste of independent life.  I was of course nervous, as I imaginemost new students are, about being on my own for several months at a time;but I was also thinking ahead to bringing my server back online via thecampus network.  I had already learned that the entire campus, includingthe student dormitories, was wired for 10Mbps Ethernet, and I couldn’twait to try out such a blazingly fast connection./p>p>Once at Carnegie Mellon, I did of course participate in the week-longintroductory activities for new students, but I probably spent just as muchtime setting up and working on my computer, initially connecting via modemuntil my Ethernet connection was configured.  The university had its owncomputer network, known as the Andrew system—named after theuniversity’s founders, Andrew Carnegie and Andrew Mellon; no relationto me, of course—which I began to explore as well./p>p>It took about two weeks for my Ethernet connection request to beprocessed, and on September 6th, I finally had my very own 10Mbps Internetconnection.  I’d already had a taste of the speed from using computersin the various labs around campus, but being able to take advantage of itfrom my own dorm room was nothing short of incredible.  (In point of fact,I i>couldn’t/i> take advantage of that speed; my Amiga was simplytoo slow for the display to keep up.)  I promptly announced thereconnection of my server on relevant newsgroups, and FTP transfers startedup immediately./p>p>Around this same time, a friend of mine—Andrew Vestal, who laterwent on to found a highly regarded video game news site, the GamingIntelligence Agency—had run into a problem: His website, a source ofinformation for videogames from the company Squaresoft (now Square Enix Co.,Ltd.), had hit the 10-megabyte limit of his Internet service provider andwas still growing.  We’d been talking about this the previous month,while I was still on vacation; since I knew that I’d be gettinghigh-speed access at college, and since I had plenty of disk spaceavailable, I had blithely offered to host his site on my server.  Afterall, I figured, no big deal; my computer’s already going to beserving anonymous FTP data around the clock, so how much more trouble coulda web server possibly be?/p>p>As I later told a user who inquired about the history of Dragonfire:Was I ever wrong./p>p>While it was all well and good to offer to help out a friend in need,that plan was nearly derailed by the lack of a decent HTTP server for theAmiga.  (For that matter, there wasn’t much networking software forthe Amiga at all; Commodore had already gone bankrupt by that time, and theplatform was clearly on its way out.)  But as a computer geek, and one witha decent knowledge of programming, the solution was obvious:  What else todo but build my own?  So I spent most of August and much of my free timeduring my first two weeks at college building a lightweight HTTPservera idfootback-4 href#footnote-4>sup>4/sup>/a>, and by purecoincidence, I got it working the evening before my Ethernet connection wasactivated./p>p>With my preparations complete—or so I thought—we began thetransfer of the website data.  Five days later, when we were satisfiedeverything was in place, the site officially went live, and the originalsite was replaced by a link to my server.  This had two immediate effects:Activity on the server shot up by an order of magnitude or more, and I wasgiven a harsh introduction to the perils of multithreaded programming, oneof the most important techniques for developing efficient software./p>p>On modern computers, every program runs in its own “virtualmemory space” to prevent interference from other programs; insidethat space, the program can do whatever it wants, and the operating systemwill do its best to accommodate that.  But the Amiga lacked the hardwaresupport needed to implement virtual memory (though add-on programs usuallybilled as debugging aids provided this feature on later processors), soevery program on the system had to cooperate to keep things runningsmoothly.  Among other problems, this lack of memory management meant thatthe OS could not dynamically expand a program’s “stack”,the place where a program can store temporary data, as modern systems do;the stack had to be preset to a sufficiently large size, or the programwould overwrite other parts of memory, usually crashing the whole system.As a result, I had acquired a habit of storing large data buffers in theprogram’s “data heap”, a place usually meant forlonger-lived program data—and, critically, shared between allprocessing threads of a program—rather than on the stack./p>p>In order to maximize performance, I had used a multithreaded model formy HTTP server, creating a new task (a thread, in modern terms) for eachconnection to the server.  The task parsed the client’s request,located the appropriate file, and read it into a memory buffer—allocatedon the heap, as was my habit—one piece at a time to send to theclient.  In most circumstances, this works fine . . . but what iftwo clients connect at the same time?  Naturally, both tasks will read datainto the same buffer—with the result that the clients end upgetting random pieces of both files./p>p>As more and more users found the site’s new location and trafficcontinued to grow, the “scrambled pages” problem became a majorissue, and I spent the next week looking for, then (after a sufficientamount of cursing at my carelessness) fixing the bug.  School had to takepriority, of course, so the fix took longer than I would have liked; in anycase, it was quite a busy week./p>p>With that finally out of the way, and with classes safely in progress, Ifinally had a chance to relax a bit.  That lasted all of three days, untilthe ever-growing traffic load triggered what was presumably a bug in theOS, corrupting the filesystem on the hard disk.  So I switched back topanic mode, working like mad to repair the system and restore regularservice.  I don’t recall for certain, but I suspect my roommate mayhave complained about my late-night work once or twice around this time./p>p>One more event, seemingly innocuous, occurred around this time:  Avisitor to Andrew Vestal’s site sent me mail, asking if he could puthis low-traffic homepage on my server as well.  Naturally, thinking only oftrying to help others, I acquiesced./p>p>Sometimes I can’t help but think back on this hectic September andwonder if perhaps I should have taken things a little easier, become alittle more involved in college activities.  Knowing my own personality, Idoubt it would have made much difference in the end; I suppose it’sonly human nature to ponder “what-ifs”.  In any case, though,that one innocuous message—even more than the monstrous site thatloomed over my dreadfully underpowered Amiga—is the spark thateventually became Dragonfire./p>p>Having recognized the need for a more capable machine, I promptly soughtout a new computer to take over server functionality from the Amiga.  Beinga poor college student, I naturally had no budget for a top-of-the-linecomputer, and I settled for an IBM PC-compatible (as we still called themin those days) 80486-based system that my father was able to secure for me.When it arrived in mid-October, I quickly dug into the installation ofLinux he had preloaded on the machine, and before long I had transferred allof the web and FTP data to the new machine.  The difference was noticeable,with much smoother response and less hard disk noise—plus I couldonce again use my Amiga as I liked without web and FTP service slowing itdown./p>p>The downside to this was that I had only one Ethernet connection; sincethat connection was now used by the Linux box, and since the monitor I usedwith my Amiga couldn’t handle the VGA display output from the PC, Ihad to find another way to connect my Amiga to the Internet.  So Iconnected my Amiga to the PC using a serial cable; while the speed was ofcourse limited, I was once again able to browse the Internet freely./p>p>For one reason or another, I found myself with a need several days laterto connect to the college’s network directly.  Since my Amiga’sserial port was already being used to connect to the Linux box, I had toswitch cables and reconnect the modem.  Having owned the Amiga for nearlyfour years, I was of course familiar with the layout of the machine’sback panel, so I reached around the monitor, pulled out one cable, andattempted to plug the second into the same place.  Unfortunately, I missedby the width of a couple of pins; as I shifted the plug around, trying toalign plug and socket by touch, the machine suddenly turned itself off./p>p>I think my initial assumption was that I had accidentally bumped thepower switch, knocked the power cord out, or something along those lines.It wasn’t until I tried to power-cycle the computer—and itswitched itself off again half a second later—that I started to getthat classic sinking feeling in my stomach.  I never did investigate indetail exactly where the damage occurred, and I was able to borrow anotherAmiga from a friend somewhat later on; but that incident forced me, howeverunwillingly, to jump into the PC world and learn how to make do with Linux./p>p>While I may not have found it particularly convenient as an ordinarydesktop machine, I had been looking forward to Linux for a differentreason.  As mentioned above, I had granted access to a second user toupload his own homepage, along with one or two more people who sent mesimilar requests over the following month.  However, the Amiga’s OS wasa single-user one, with no provision for protecting one user’s filesfrom another; even setting aside the case of Andrew Vestal, whom I trustedimplicitly, I had no guarantee that these people would not try to destroyeach other’s files—or my own, for that matter.  This obviouslywas not an ideal situation, and I looked to the multiuser capabilities ofLinux to rectify it.  Indeed, Linux allowed me to configure system securityeasily, ensuring that users’ files and the system itself would besafe from any accidental or malicious destruction./p>p>With that problem settled, I thought back on the requests I’dreceived to host other users’ data.  Now that I had a reasonablysecure system, and one that was more than powerful enough to handle itscurrent load, why not open it up for anyone?  So, after duly checking theuniversity’s network usage rules, I slapped together a simplehomepage for the server itself, advertising free web and FTP space for allwho ask, and Dragonfire came into being.  (To be precise, at this time itwas still called Dragon, from the hostname tt>dragon.res.cmu.edu/tt>; thename Dragonfire would not appear for a few months yet.)/p>p>The following month of November was probably one of the quietest ofDragonfire’s life.  Account requests slowly started trickling in,perhaps one or two a week at first.  With each one, I’d read over theaccount request, add the user account, create the necessary directories onthe server, update various configuration files, and add the new user’sinformation to the user database—nothing more than a short textfile.  Overall, it was about a 5-minute process, as I recall: certainlynothing to worry about at the rate requests came in, and if anything, theexcitement of someone else finding the site and expressing interest inusing it far outweighed the loss of time./p>p>That peaceful month was abruptly ended by a warning I received from theuniversity’s data communications department, or DataComm, as theywere known:  “Pirated software has been found on your server.  Removeit now, or else.”  This was, of course, quite a shock to me, since Icertainly had no intention of engaging in such unscrupulous behavior.  Idon’t recall whether the offending URL was pointed out to me directly,or whether I found it by perusing the server’s log files; but eitherway, one recently-added account’s FTP traffic stuck out like a sorethumb, dwarfing the others over the previous several days.  This discoverywas a big blow to my youthful innocence, but having become aware of theproblem, there was nothing for it but to delete the account./p>p>Just deleting the account didn’t really strike me as fair, however,no matter how improper the owner’s behavior was.  So I proceeded towrite up a simple set of rules delimiting what would and would not bepermitted on Dragonfire, and what the penalties would be for violating therules.  Even at the time, though, I was aware of—in fact, had had toread myself—rule lists and policies full of so-called legalese, whichwas, if not quite impenetrable, certainly no fun to read.  So I drew a linethere, establishing a basic tenet of Dragonfire administration which wouldhold at least as long as I was in charge: mutual trust.  I don’t recallwhether I explicitly said as much in that first set of rules, or whetherthat came later, but I took the position that the rules were written withcommon sense in mind.  We (the royal We, though at the time I was the onlyone on the provider side) asked Dragon’s users to trust us to applythe rules fairly, and in return we trusted users to interpret the rulesfairly.  I can’t imagine a system like that would even get off theground today, but at the time, I wanted to make a statement:  I wanted toshow that you i>didn’t/i> need legalese for everything—ordie trying, so to speak./p>p>Speaking of traffic, one thing I had been doing ever since I set up myFTP server back in high school was keep track of the server’s datatransfer statistics.  Traffic analysis is, of course, an excellent tool fordetecting problems, as the pirated software incident amply demonstrated;but to me, it was also an indication of the server’s popularity—andtherefore of how useful others were finding my efforts.  And to be honest,I have always enjoyed playing with numbers, be they traffic statistics,finances, or abstract mathematical problems; so it was only natural that Iwould write a short program to summarize transfer statistics from the FTPand web logfiles./p>p>And what a surprise those statistics provided.  While transfers had beengradually growing even during the first months of modem-based connectivity,the growth turned virtually exponential after my move to a high-speed link.I had known firsthand about the traffic increase from the Squaresoft site,of course; traffic that month jumped by a factor of five from the previousone, to a level that would have saturated the modem connection (andundoubtedly angered the school’s staff).  But even after that initialjump, traffic continued to roughly double each month over the next fewmonths.  During its first year of operation, Dragon grew from a small FTPsite transferring 100MB in a month to a high-speed server sending out 1GBi>each day./i>  These days, multimedia files reach into the gigabyterange easily, and with a sufficiently fast connection downloading such afile is a matter of mereminutesa idfootback-5 href#footnote-5>sup>5/sup>/a>; but for afreshman college student in the mid-1990s, it was difficult to conceive ofa whole gigabyte of data going somewhere every day, especially from asingle little machine sitting under the desk in my dorm room./p>p>As the year drew to a close, word about Dragon seemed to be spreading.The rate of incoming account requests grew, slowly but surely; by the endof December, I saw one or two requests a day, and the excitement of havinganother Internet user request an account slowly gave way to the tedium ofhaving yet i>another/i> Internet user request an account.  Naturally, theprogrammer’s weapon of choice against tedium is automation, and aroundthis time I wrote the first scripts to automate account management.  Theuser database was still a flat text file, but instead of adding newentries manually, I taught myself the basics of the Perl scripting languageand wrote a script to take care of the details for me.  (This script wouldgive me some nasty headaches later on.)/p>p>All in all, it was a moderately eventful year, but an interesting onenonetheless, and things were looking up.  My first semester of collegeended in mid-December, and I headed home for the holidays, trusting that myLinux server would manage to keep itself running for the month I was away./p>!------------------------------------------------------------------------>hr />div ids-1996 classtitle>h2>1996: Care and Nurture of a Dragon/h2>/div>p>As it turned out, the server itself performed just fine on its own.  Mydormitory room Ethernet connection, however, did not fare as well,providing me with a bit of a scare in early January when Dragon suddenlybecame unreachable.  I initially feared that the server had gone down,which would be a significant problem in terms of service, since I would notbe able to return to the dorm to fix it until the middle of the month.  Acall to DataComm, however, revealed the true cause:  My connection had beenadministratively disabled in response to a report of a cracking attemptfrom my IP address.  The report, it turned out, came from the owner of asystem named tt>dragon.net/tt>./p>p>As my server’s traffic increased, I had started considering thepossibility of getting my own domain name.  The logical choice, of course,would have been tt>dragon.net/tt>, but as I had quickly discovered, thatname was already registered.  Curious as to what the system was, I triedconnecting on some common service ports: HTTP, FTP, SMTP, NNTP, Telnet,and finger (the latter three were still in fairly common use at the time).Except for SMTP, all of the connections were refused, so I shrugged it off,figuring that it was a private system.  Apparently, though, the system’sowner took that as a break-in attempt and reported it to Carnegie Mellon,who subsequently disabled my connection./p>p>The DataComm staff member I spoke with explained the situation to me,patiently telling me that my actions were akin to knocking on locked doorsand windows of a house, and I must behave more circumspectly on theInternet.  I could naturally understand how a system owner might beparanoid about break-in attempts; given that students were on vacation, Icertainly can’t fault DataComm’s response to the complaintitself; and indeed, I blamed myself for not having foreseen that my actionscould have been perceived as hostile.  At the time, I was more concernedwith getting my server back online than with defending my actions, so Igave the staff member a meek “yessir”.  Nonetheless, I wouldstill respectfully disagree with his characterization:  To the extent thata computer—especially one associated with a domain name—isaccessible to others on the Internet, the system administrator shouldexpect people to attempt to access it on well-known ports.  Many physicalmetaphors have been applied to the Internet with varying success, but ifone were to use the brick and mortar analogy, I would argue that my actionswere closer to checking a storefront on a shopping strip for an“Open” or “Closed” sign, hardly an unexpected orsuspicious event./p>p>At any rate, the connection was reactivated, and Dragon once more becamevisible to the world.  I settled back to enjoy the last week of my wintervacation—nearly lengthened due to surprise snowstorms that blanketedthe area—and returned to Carnegie Mellon in mid-January to begin mysecond semester of college./p>p>Account requests continued to come in unabated, and along with themcame support requests: questions from users on how to make use of theiraccount, requests to change account information, and so on.  The latter,in particular, came to consume a not-insignificant chunk of time from myday; so, in order to free myself for other pursuits (such as schoolwork),I enlisted the help of a friend to take care of handling those requests.I may have been a bit nervous about delegating responsibility for the firsttime, but Dragon was still a small server with only around 100 users, so Ididn’t expect much trouble.  Based on mail from the period, things doindeed seem to have gone smoothly, freeing up time for me to deal withissues like all-too-frequent memory shortages./p>p>As the number of users grew, I also became increasingly concerned aboutthe potential for data loss.  I was familiar enough with the concept ofbackups, but the idea of copying more than 1GB of user data onto stacks of1.44MB diskettesa idfootback-6 href#footnote-6>sup>6/sup>/a>didn’t really appeal to me.  Instead, I managed to secure a tapedrive for which I was able to buy tapes at the campus computer store; Ican’t recall any longer exactly what kind of tapes they were, butthey held 500 megabytes of data each, significantly reducing the amount oftime I had to spend making backups./p>p>At the same time, I was still looking into getting a domain name for myserver.  I explained the situation to some friends on IRC one night, afterlearning why the server had disappeared, and one of them suggestedtt>dragonfire.net/tt> as an alternative to tt>dragon.net/tt>.  The namerather appealed to me, and—more importantly—itwasn’t in use at the time.  Domainspeculationa idfootback-7 href#footnote-7>sup>7/sup>/a> wasunheard of in the 1990s, so acquiring an unused domain was simply a matterof establishing nameservers and sending the appropriate form and payment toInterNIC, the DNS management authority./p>p>Filling out forms was simple enough, but registration of a domainrequired two functioning nameservers, and I only had one machine.  Anotherfriend from IRC, Ian Justman, came to the rescue, offering to set up a“West Annex” (so named since he lived on the west coast of theUSA, while I was located on the east coast) for Dragon on his own homenetwork.  This allowed me to establish the second nameserver I needed, andalso gave me a backup site from which I could at least post status messagesif my own server became inaccessible again.  Though I had no way to guessat the time, this second ability would prove critical later in the year./p>p>With everything prepared at last, I submitted the domain registrationrequest, and on February 26, 1996, Dragon transformed into DragonfireInternet Services.a idfootback-8 href#footnote-8>sup>8/sup>/a>/p>p>Aside from the name change and the addition of a logo (shown at the topof this retrospective) to the server’s homepage, nothing particularlymomentous occurred to mark the occasion.  User accounts continued toincrease at a steady pace, however, and the Linux box which had served meso well until then began to show signs of stress./p>p>As a result of earlier system resource problems, I had already created asimple system status display program, with output looking something likethis:a idfootback-9 href#footnote-9>sup>9/sup>/a>/p>table classscreen>tr>td> 1:46am  up 14 days,  1:21,  4 users,  load: 0.03, 0.05, 0.08,  148 procsMemory use: 320200/2074416 real + 903484 buffers         0/32760 swapDisks:  span stylecolor: yellow>//span>                 span stylecolor: yellow>81   5329468/  6613856/span>   139844/417792  33  /home             77  10147576/ 13228720    68829/829056   8  /data             65  52361632/ 79965468    11682/234624   5  span stylecolor: red>/scratch/span>          21  65862408/310681652    span stylecolor: red>68530/ 75872  90/span>/td>/tr>/table>p>(The numbers above are from my personal machine in late 2007; a systemwith specifications like these would have been inconceivable in 1996!)  Bythis time, both 1GB disks installed in the server were hovering consistentlyin the red “danger” zone.  So I managed to secure a 2GB harddisk to add to the server, which was delivered in mid-March; after aconsiderable amount of physical and logical rearrangement, the server oncemore had room for growth, at least in the disk space department./p>p>Also around this time, I made an addition to Dragonfire’s rules thatis without doubt one of my poorer decisions.  This addition was thea hrefwebsite-1998/rules.html#gc>“good citizen” clause/a>,which threatened Dragonfire users with account termination for“inappropriate or illegal” activities—whether performedusing a Dragonfire account or not.  I don’t recall exactly whatprompted me to add this clause, though mail from the period suggests thatthere were some users trying to play fast and loose with the rules and Igot tired of their games.  Either way, the rule essentially served as anexcuse for me to remove users I didn’t want on Dragonfire.  It goeswithout saying that no proper commercial provider would even consider aclause like this; I may have felt that since I was providing accounts forfree, I had the right to be more pushy about such issues.  (Even if so, Iretained the rule after I began charging for service, so that hardlyqualifies as an excuse.)  Perhaps the only saving grace is that, aside fromwhatever incident may have prompted its creation in the first place, Idon’t recall any occasions on which I actually made use of therule—though that hardly mitigates the chilling effect it must havehad on users.  In any case, among the many things I would change if giventhe opportunity to redo Dragonfire, this is close to the top of the list./p>p>At any rate, the approach of April meant that I needed to secure somesort of Internet connection for Dragonfire over the summer, since Icouldn’t simply leave my system at the university for the wholethree-month summer vacation.  I had already investigated possibilities forconnectivity, and settled on a 112-kilobit dual-channelISDNa idfootback-10 href#footnote-10>sup>10/sup>/a> connection asthe best balance I could strike between service and cost; Dragonfire’saverage bandwidth use was already close to 300kbps at the time, but orderingthe requisite T1 line for something that provided no income whatsoever wasfar beyond my means.  I made the necessary preparations, registered for anaccount with my local service provider, and ordered an ISDN line from thelocal telephone company, Bell Atlantic.  The salesperson I spoke to assuredme that installation of the line would be a matter of one to two weeks, andsince I still had over a month before the semester ended, I figured that Iwas all set./p>p>Come May, though, the installation was still pending; when I was finallyable to secure an installation date, that date was set for May22—eight full days after my departure from Carnegie Mellon.Frustrated, I sent a message to users explaining the situation andapologizing for the interruption in service.  Most users were understanding,though, which was at least a slight relief to my jangled nerves.  I tookadvantage of the West Annex system to post a status page informing visitorsto Dragonfire’s site about the problem, and settled back to await theinstallation./p>p>One day before the planned installation, though, I received anunexpected call from the network provider which was working with BellAtlantic on the installation.  According to the call, Bell Atlantic’sengineers had, that very morning—over a month and a half since I hadinitially ordered the line—discovered that the local telephone switchdid not support ISDN and would have to be upgraded before the installationcould proceed.  As a result, the installation had been delayed to“early the following week”.  My frustration mounted as I wasonce again forced to type out an apologetic explanation to Dragonfire’susers.  And predictably enough, the complaints started trickling in:“Please remove my Dragonfire account.” “Will Dragonfireever be back up?”/p>p>Another week passed, and there was still no word about installation, soI called up the network provider again.  This time I was told that BellAtlantic had “just discovered” that my house was too far fromthe telephone switch for a straight ISDN line, and would have to install arepeater to amplify the signal.  Naturally, this meant yet more delay.  Inthe end, the ISDN line was not connected until June 13, thirty days after Ihad brought the system home./p>p>In perhaps cynical retrospect, I have no proof that Bell Atlantic wasactually the party at fault; it’s also possible the network providerhad simply forgotten and was shifting the blame to the telephone companyinstead of admitting their own faults, though I recall the person I spokewith sounding just as frustrated with the lack of progress.  And in allfairness, ISDN was still a new technology at the time; my father (who tookcare of paying the ISDN bills until I had earned enough to pay him back)tells me that it took months for Bell Atlantic to get their billingstraightened out.  Either way, the end result is that Dragonfire suffereda full month of downtime before finally reappearing on the Internet./p>p>Despite this—and to my considerable surprise—the vastmajority of users (at least, the vast majority of those who responded to mystatus-report messages) were both understanding and supportive.  I suspectthat in any case, I would have continued running Dragonfire out of a senseof duty; by this time I had realized, at least subconsciously, that I wasstuck with what I’d built—I couldn’t just take the systemdown while others were depending on it.  But those messages of support, thefriendly comments and encouragement sent by so many users, were animmeasurable boost to nerves that were frayed close to the breaking point.I can’t recall whether I ever expressed my thanks for that support,but if any Dragonfire users of the time happen to read this retrospective,allow me to say:  Thank you.  I can’t overstate how much thosemessages meant to me./p>p>Having ridden out that stormy month, Dragonfire once more got back towork.  Due to various wiring issues, I had to set up Dragonfire in thebasement of our house, but this didn’t particularly bother me as longas the server could do its job.  In fact, I spent much of my time at homeworking at the console—proving that there’s at least a modicumof truth to the stereotype of computer geeks living in their parents’basements:/p>p stylewidth: 500px; margin: 1em auto; font-size: 80%; line-height: 1em; text-indent: 0; text-align: center>img srcsummer-1996.jpg altPhotograph />br />Dragonfire and its owner in August 1996.  The tower case is theserver itself, with an external 4GB hard disk (low white box) attached on theright.  The black box just barely visible on the shelf above the monitor isthe ISDN router, an Ascend Pipeline 50./p>p>In contrast to that first month of frustration, the remaining two monthsof summer vacation proved mostly uneventful.  Naturally, the bandwidth wasnowhere near enough to support all the sites hosted on Dragonfire; the ISDNline reached its saturation rate of 112kbps for a few hours on the same dayit was connected, even though the updates to the tt>dragonfire.net/tt>DNS data had not yet completely propagated.  I was able to improveperformance by modifying the HTTP server software to limit the bandwidthused for image files, giving preference to the HTML pages themselves; aftera bit of fine-tuning, I was able to get a 100% response rate on HTML files,though at the cost of rejecting most requests for images.  (At this time,many websites were still text-oriented, using graphics for decoration atmost.  Doing this sort of throttling on a modern website could easilyrender it unusable.)  Nonetheless, new users continued to request accounts,and in August I had to buy an external 4-gigabyte hard disk to augment the4GB of space already installed in the server./p>p>August drew to a close, and at last I was able to bring Dragonfire backto the high-speed environment in which it had been born.  As a typicalcollege student, of course, I was not looking forward to the return ofclasses and homework, especially since I still had several requiredcourses to clear before I could take the more interesting advancedlectures.  As Dragonfire’s administrator, however, it was a relief tofinally be free of that constricting ISDN connection, able to stretch mywings once more.  (Well, not i>my/i> wings, but you get the idea.)/p>p>The Internet community, it seemed, was just as relieved; no sooner had Ireconnected Dragonfire than new account requests started literally floodingin—sometimes dozens in a single day.  Just three days after returningto CMU, Dragonfire reached 1,000 user accounts, stretching that old usermanagement script of mine to the breaking point./p>p>As mentioned earlier, the “user database” on Dragonfire wasnothing more than a simple text file listing each user’s username,account namea idfootback-11 href#footnote-11>sup>11/sup>/a>, andother details.  My maintenance scripts worked by reading in the entiredatabase, making whatever additions or changes were requested, and writingthe file back out to disk.  For one reason or another—perhaps Inoticed an error and thought to cancel a change I was making—Iinterrupted the script as it was rewriting the database, with thepredictably catastrophic result that most of the user database vanishedinto thin air.  I was able to reconstruct the data from backups anddirectory listings, but the incident told me in no uncertain terms that Ineeded a better way to manage user information.  So as classes started, Iput all the time I wasn’t doing homework (and probably some time Ii>should/i> have been doing homework) into creating a more robust userdatabase framework./p>p>I’m not sure why I didn’t switch to a proper databasemanagement system.  I had already gained some experience working withdatabases in my summer job; it may be that I felt such database systems tobe too complex for a “simple” task like user management, orthat I thought it would take too long to learn my way around them when Ineeded a solution i>now./i>  It’s also quite possible that I justwanted to try coming up with something on my own, to experiment and learnfor myself what worked and what didn’t.  In any case, I ended upwriting a full-fledged user data management library, complete withmenu-based administration tools, to replace the old, crusty scripts I hadbeen using./p>p>The creation of a stable, well-defined interface to the user databasegave me another idea:  How about adding an automated account request formto Dragonfire’s homepage?  I could easily write a CGI program to processthe form data and inform the user if their requested username or accountname was in use, avoiding the necessity of mailing back and forth to askfor alternate names.  So I did./p>p>If two to three dozen requests a day constituted a flood, the additionof that request form unleashed what I could only call a raging tsunami.The request rate quickly reached fifty per day, then a hundred.  Bymid-November, Dragonfire had swelled to over 5,000 user accounts—anincrease of 4,000 in less than two months.  When I finally announced atemporary hold on new accounts later that month, the rate was over 150 newaccounts a day.  I had streamlined the account creation process to thepoint where I only had to press two keys to confirm each account, and itstill took a significant chunk of time out of my day./p>p>The hold on new accounts was due only in part to this administrativeworkload.  Another reason was hardware limitations; predictably, the rapidaddition of so many accounts was a significant strain on the server.  Ireplaced the outdated 486-based computer with a Pentium machine inNovember, relieving the worst of the immediate problems, but it was clearthat even the Pentium had limits, and it wouldn’t last long at the rateDragonfire was growing./p>p>The final, critical reason for the hold on accounts was bandwidth use.At the time, each dormitory was connected to the main campus network with asingle, shared 10-megabit connection.  As I learned through severalincreasingly insistent complaints from CMU DataComm, Dragonfirewas—incredibly—using over a third of thatbandwidth all by itself.  Due to technicallimitationsa idfootback-12 href#footnote-12>sup>12/sup>/a>, theactual throughput on the so-called “10Mbps” dormitory networkwas actually closer to 4Mbps—meaning that everyone else in mydorm had to compete for the tiny fraction of bandwidth Dragonfirewasn’t using.  In the end, it came down to:  Reduce your bandwidthuse, or we’ll cut you off./p>p>Naturally, the hold on new accounts would help prevent Dragonfire’sbandwidth use from growing, at least in the dramatic way it had during theprevious months.  But how could I i>reduce/i> bandwidth use?  As astopgap measure, I throttled back the rate at which the server responded toHTTP requests; this was effective in the short run, but had the undesirableside effect of slowing down accesses to the server.  As the semester drewto a close and I headed for home, I continued toworrya idfootback-13 href#footnote-13>sup>13/sup>/a> over thebandwidth problem, trying to find any way around what I had begun torealize was the only viable solution./p>!------------------------------------------------------------------------>hr />div ids-1997 classtitle>h2>1997: Thrust into the Real World/h2>/div>p>That “only viable solution” was, of course, charging forservice.  Especially given the problems that had plagued Dragonfire overthe past year, I knew that any attempt to charge would be greeted coldly.(I had conducted an informal poll over the summer regarding thethen-hypothetical possibility of charging fees, and nine out of ten whoreplied had had no objection; but the number of replies was only a fractionof Dragonfire’s userbase at the time, which itself was insignificantcompared to the 5,000 users who inhabited Dragonfire now.)  As I headedback to start the spring semester of my second year of college, I thoughtover all the steps I would need to work through in order to make thetransition./p>p>I had already discussed with my network provider the possibility ofcolocating the Dragonfire server, and while I hadn’t signed the actualcontract yet, I had the information I needed on that end: the price ofconnectivity, $500 per month for the bandwidth Dragonfire required.  Iadded to that the rough cost of equipment addition and replacement,factored in taxes, and came up with a rough figure of $10,000 per year intotal costs.a idfootback-14 href#footnote-14>sup>14/sup>/a>  (Toa simple college student like myself, it was quite startling to realizethat I would soon be dealing in four- and five-figure amounts on a regularbasis.)  So the critical question was how to balance the equation on theother side:  How many users would be willing to pay—and whatwould I have to charge them?/p>p>A quick survey of the automated traffic statistics showed me that abouthalf of the 5,000 users weren’t using their accounts at all; presumablythey had found a site giving out free accounts and just signed up, figuringthat having an extra account never hurt.  That left 2,500 potential payingusers, but certainly many of them would choose to move to another freeprovider instead of paying.  Making a rough guess from my poll of theprevious summer, I estimated that between 10% and 20% of those, or 250 to500 users, would pay for service.  If I assumed 400 paying users, a yearlyfee of $25 would cleanly cover the expected costs; if the number of usersfell to 250, I would probably be able to reduce my bandwidth charges andstill stay out of the red.  And if I was lucky enough to keep 500 users, Ijust might be able to earn back some of the money I had spent on Dragonfirein the last year and a half./p>p>So I set the price for accounts at $25 per year, or $5 per twomonths—a slight premium in the latter case to cover theadministrative effort of having to update the account data more often.Since many users had already donated money to Dragonfire, I decided it wasonly fair to count those amounts toward account fees; but at the same timeI wanted to make as clean a break as possible with the current, freeaccounts.  So I decided to ask all users, even those who had donated, topay for at least two months of service; those who paid would then have anyprevious donations counted toward their account fees, extending theaccount’s expiration date.  I also asked users to mail theirpayments, since credit card transactions over the web turned out not to befeasible.  (A bonus to this was that many foreign users sent cash, and Igot the chance to see numerous kinds of money from around the globe.)  AndI set the changeover date, on which all unpaid accounts would expire, toApril 1, 1997./p>p>With the details settled, I finally wrote out a message toDragonfire’s users on January 20, explaining the situation.  Steelingmyself against the inevitable onslaught of angry replies, I sent themessage out, and sat back to wait./p>p>As expected, the response to this announcement was not nearly asgenerous as it had been during the previous summer’s downtime.  Responsesvaried from the apologetic (“I’m sorry to go because I liked theservices provided”) to the sarcastic (“If you seriously thinkI’m going to pay for such a slow server you better get a life.”)and the furious (which I just deleted after a cursory glance).  Many usersdidn’t even reply at all, and most of the 5,000 free accounts expiredwhen April arrived.  But at the same time, some users were satisfied enoughwith the service that they sent in payments; and when the dust had settled,Dragonfire had about 380 paying accounts—coincidentally close to the“sweet spot” I had initially estimated./p>p>On the network side of things, I had completed the paperwork for theconnection with my network provider, and I scheduled the physical transferof the system for late March, coinciding with the university’s week-longspring break.  While the provider assured me they would have staffavailable 24 hours a day, I was quite nervous about moving the server sofar away (not too far from my parents’ house, but about 400 kilometersfrom Carnegie Mellon).  Until then, even if the machine acted up I could alwayslog in on the console to fix the problem, or hit the reset button in theworst case.  But with the server in a remote location, I had to rely on themachine’s network connection in order to do anything at all; if a freaksoftware or hardware glitch cut the server off from the network, I washelpless.  Nonetheless, the decision had been made, so I plodded along,trying to keep things moving as smoothly as possible over the transition./p>p>By this point, I must admit that Dragonfire had lost a lot of its lusterfor me.  As I said frankly to one longtime user who complained about myplan to charge for service: “Dragonfire has gone from something Ithought of as a fun little hobby to a huge Service that’s absolutely nofun at all. And yet I can’t just shut it down, much as I want to, becauseso many people depend on it. I’m caught between a rock and a hard place:I can’t keep the server here, but at the same time I can’t keep itanywhere else because I’d have to pay huge amounts of money.  So whatelse can I do?”/p>p>While my negative feelings about Dragonfire were undoubtedly exaggeratedfrom reading all the complaints about fees, I can’t deny that thetedium of dealing with dozens of support requests every day, the frustrationof having to deal with users that tried to skirt the rules, that sort ofactivity was wearing on me.  At heart, I’m much more of a technicalperson than an administrative one, and the enjoyment of providing a serviceto others was rapidly being dulled.  It was, once again, the kind,supportive messages from those users who stayed with Dragonfire that keptmy spirits from collapsing completely.  While most of the payment formssent I received had only the requisite account details written on them,some users added friendly notes or sketches, which were always a joy tosee.  One user even sent a excellently drawn full-pageillustration—in color, no less!  (Color printers were still somethingof a luxury in those days.)/p>p>So I managed to weather those rough winds, and late in March, Idisconnected Dragonfire from Carnegie Mellon’s network for the lasttime.  I took the server home with me, as I had the previous summer; butinstead of returning it to my parents’ basement, this time I took itto the site of Clark Internet Services, a.k.a. ClarkNet, my networkprovider from the previous summer and the company with which I hadcontracted for colocation./p>p>Dragonfire’s initial site, as it happens, was on the floor of abarn.  If I recall correctly, the founder of ClarkNet owned a farm, andtook advantage of an unused barn to house the company’s networkequipment.  (When I first spoke with them and they talked about housing myserver in “the barn”, I had blithely assumed that was theirjargon for the room or building containing the equipment.  I hadn’timagined it was an actual, literal barn.)  This only lasted for a week orso, however; power supply problems that coincidentally appeared around thesame time led ClarkNet to move my server to a rack they were renting inanother network provider’s data center, and I have to admit relief athaving Dragonfire settled in a more traditional environment./p>p>At last, April arrived.  I allowed a two-week grace period for those whodid not send payments early, so the transition from a free service was notinstantaneous; but on April 17, over four thousand accounts disappearedfrom the server, and Dragonfire was a free provider no longer./p>p>On one hand, going commercial meant that I was no longer constrained bythe university’s network rules.  In particular, I was able to liftthe restriction against hosting commercial sites on Dragonfire, which theuniversity would not have permitted.  On the other hand, accepting moneyfrom users in exchange for providing service placed an additional onus ofresponsibility on me, one which frankly made me nervous.  Saying“I’m doing the best I can” and expecting users to acceptthat is fine if you’re giving them something for free; but when moneybecomes involved, the service has to be good enough to satisfy those payingfor it, and I wasn’t confident that I could manage./p>p>As it turned out, Dragonfire’s first trial was an incident I hadno power to resolve.  Shortly after the changeover, the networkbackbonea idfootback-15 href#footnote-15>sup>15/sup>/a> throughwhich Dragonfire’s traffic passed suffered aDDoSa idfootback-16 href#footnote-16>sup>16/sup>/a> attack, withthe result that users trying to access pages on Dragonfire encountered slowresponse times.  Nonetheless, I had to face numerous complaints of poorservice from Dragonfire’s users.  And who can blame them?  Usersshouldn’t need to care i>how/i> service is provided to them, aslong as it i>is./i>  Frustrated at being unable to do anything, I pokedand prodded both ClarkNet and the data center administrator, probably moreoften and more harshly than I should have; but in the end, the problem wasresolved by the backbone company, and Dragonfire’s response speedreturned to normal./p>p>Once that issue was cleared up, things ran smoothly for the most part.There were a few occasional bumps along the way; in particular, ClarkNetcontinued having on-and-off problems with their power supply, to the pointthat the data center forced them to switch over to the common circuits.  Ialso recall a couple of times I found Dragonfire down for no apparentreason, only to learn later that someone had accidentally knocked out acable or switched off the wrong machine; though since ClarkNet’s rack wasrather haphazardly set up (perhaps unavoidable when each customer has theirown distinct machines and wiring), I guess I shouldn’t have been toosurprised./p>p>As time passed, though, the system load on Dragonfire began to creepup again, pushing against the limits of the hardware.  It wasn’t theresult of a flood of accounts this time; while new account requests wereonce more trickling in, the rate was much closer to that ofDragonfire’s first few months of operation.  I can only guess thatthe increasing popularity of the World Wide Web as a whole had begun tomake itself apparent./p>p>One concept that had started making the rounds in web services was thatof the personalized hostname.  Until then, most providers (includingDragonfire) had given all their users URLs on the same server, with adistinct directory name for each user: for example,tt>http://www.dragonfire.net/~achurch//tt>.  With personalized hostnames,each user would have their own hostname within the provider’s domain:for example, tt>http://achurch.dragonfire.net//tt>.  This allowed users tosimplify the URLs for their pages without having to go through the hassleand cost of registering a separate domain.  Seeing as Dragonfire’s userswere now paying for their service, I thought it only appropriate that Ilook into improving that service; and once I had modified the serversoftware appropriately and obtained a block of 256 IPaddressesa idfootback-17 href#footnote-17>sup>17/sup>/a>,Dragonfire began offering personalized hostnames./p>p>Then, late in August, I was hit with a zinger:  ClarkNet told me thatthey were changing their rates—and Dragonfire’s bandwidth would nowcost not $500 per month, but $2,100./p>p>This was quite a shock, not least because I had carefully tailoredDragonfire’s fees to the cost of colocation.  If I kept to the samefee structure, the “not-quite-free” rate of $25/year wouldskyrocket to $100, no better than most other providers—and withconsiderably less stable service.  Instead, I individually contacted thefew users who were using the most bandwidth, explaining the situation andasking them to cover their fair share.  With luck, I hoped, that wouldeither help cover the added costs or encourage those users to reduce theirbandwidth usage./p>p>But by the time winter vacation rolled around, I knew that I wouldn’tbe able to avoid passing the increased bandwidth charges on to users anylonger. As my finance charts clearly told me, Dragonfire had been bleedingmoney in the months since ClarkNet’s rate change, and there was justno way to make things work otherwise.  With a heavy heart, I set to workingout just how much I would need to ask the users to pay./p>!------------------------------------------------------------------------>hr />div ids-1998 classtitle>h2>1998: Growing Up/h2>/div>p>In the end, I had to raise the basic account fee by about half, from$25 to $40 per year.  At least I was able to keep it from jumping asdrastically as my own costs had, but it was still frustrating to feelDragonfire slip farther and farther from the inexpensive provider I hadwanted it to be./p>p>To try and take some of the sting out of the fee increase, I worked onseveral improvements to Dragonfire’s services.  Most significant amongthese was the addition of a new server; the original server, Bahamut, hadalready been expanded and upgraded to its limits, and it was still nearlyoverloaded.  On January 30—two days before implementing the newrates—I installed the new system at the data center, which finallytook care of the system load problems for good.  Continuing the fantasytheme, I named the new server Palantir, from J. R. R. Tolkien’sMiddle-Earth novels./p>p>With the addition of the new server and a growing number of serviceprocesses to monitor, I decided to merge my old system status displayprogram with several other short utility scripts I had written, creating afull-fledged monitoringprograma idfootback-18 href#footnote-18>sup>18/sup>/a> whichcould show me the complete status of Dragonfire at a glance:/p>p stylemargin: 1em 0; text-indent: 0; text-align: center>img srcsysmon.png altsysmon screenshot />/p>p>(Once again, thenumbersa idfootback-19 href#footnote-19>sup>19/sup>/a> are frommy personal machines in late 2007, not the actual hardware used byDragonfire.)  Aside from having a compact status display, the program wouldbeep at me if it discovered anything untoward, such as a server going down;on one occasion, that woke me in the middle of the night and sent me on a12-hour trek from CMU down to the data center to repair one of the servers./p>p>On the whole, 1998 was the most uneventful year in Dragonfire’sshort history.  However, I had one of my greatest surprises of all in May,when I received a letter from (what was at the time) a fairly major webservice providera idfootback-20 href#footnote-20>sup>20/sup>/a>in the USA.  I had almost tossed it out as advertising before I noticedthat it was addressed to “President, Dragonfire Internet Services”.Upon opening and reading the letter, I discovered that this major providerwas essentially offering to buy out Dragonfire./p>p>I was amazed more than anything, both that Dragonfire had caught the eyeof another provider and that the provider thought Dragonfire was worthenough to send such a letter.  But at the same time, I couldn’t helpbut wonder whether they had done due diligence.  Even after the Februaryincrease, Dragonfire’s rates were significantly below those of mostother providers; taking on users and promptly hitting them with massivefees seemed to me to be asking for trouble./p>p>Seeing no benefit to anyone, I decided to write back, pointing out whyI didn’t think their proposal was such a good idea.  If they werepersistent, I figured that I could always see what the users of Dragonfirethought; perhaps the stability of a proven hosting provider was worth theadditional cost after all.  But I never received a reply, and the matterended there./p>p>There was one other kind of mail, albeit electronic, that I receivedfrom organizations occasionally: copyright and other claims againstmaterial posted by Dragonfire users, usually in the form of legal threats.I probably got about one every two months or so after taking Dragonfirecommercial.  At the time, theDMCAa idfootback-21 href#footnote-21>sup>21/sup>/a> had not yetbeen enacted, so there was no standard procedure for dealing with problemslike copyright violation; however, many ISPs of those days would simplydelete any questioned material out of hand or even terminate the allegedlyinfringing user’s account, a heavy-handed practice—sometimes abusedto “censor” undesired material—which I found repellent.As such, I took the position that, barring court orders or the like, Iwould take no action against any Dragonfire user unless I could personallyconfirm the alleged infringement (though I did pass along the allegationsto the users involved)./p>p>While I can only look back and be amazed at my hubris, I replied toevery one of those messages in a similar fashion:  “Please provideproof of infringement, or Dragonfire cannot take any action.”Depending on the tone and content of the message, I sometimes even fellinto lecturing mode, explaining my position.  This must have been quitefrustrating to the people at these companies who were just doing their job,undoubtedly thinking they were contacting a faceless administrator at arandom provider who was also just doing his job.  In fact, I recall oneargument that went back and forth probably a dozen times as we each triedto convince the other of the “correctness” of our beliefs.Miraculously, though, I was never actually sued by anyone./p>p>As my fourth and final year of college began in September 1998,Dragonfire was once again losing money.  The fee increases I hadimplemented at the beginning of the year had not been enough to cover thehigher costs of bandwidth—to put it simply, I’d goofed.Unfortunately, I wasn’t strong enough to admit that plainly, and Ifound myself unwittingly headed down the same road followed by many lessscrupulous companies: using additional services as an excuse to raise baseprices./p>p>Unsurprisingly, most users weren’t fooled when I told users later inthe month that “Dragonfire is pleased to announce” personalizedhostnames becoming standard for all accounts and an increase in the defaultbandwidth limit—with an accompanying increase in fees.  I did make acomment about “concerns regarding Internet connectivity”, but Isuspect that may not have been convincing given the tone of the rest of themessage./p>p>At the same time, I had learned of and applied for an opportunity for aninternship in Japan, eager for the opportunity to learn more about thecountry and try out my Japanese skills in a real-life setting.  Of course,if I was accepted, I would end up being located halfway around the worldfrom Dragonfire; this would be something of an impediment to Dragonfireadministration, to put it mildly.  I could, at least in theory, relocateDragonfire to a colocation center in Japan and continue it there.  But Ibegan to consider the possibility that I might have to borrow others’help to run Dragonfire—or perhaps let Dragonfire go completely./p>p>So I began talking with a friend of mine, Mikel Tidwell, who also ran asmall service provider, called Dreamhaven.  We worked though variouspossibilities, such as having him help administratively while I wasoverseas (I didn’t plan at the time to remain in Japan indefinitelyeven if the internship came through), or forming a partnership to runDragonfire.  We didn’t finalize anything yet, though; I was still waitingto hear back regarding Japan, and more than anything, I was hesitant toturn over the reins of Dragonfire to anyone else./p>p>In November, I received word that I had been accepted to the internshipprogram.  That set a firm time limit on when I would have to decide what todo about Dragonfire:  I would be departing for Japan the following May,shortly after graduation.  I began looking into what would be needed to setup an LLC, a simplified type of corporation, for Dragonfire; but I had notyet decided what I was going to do with the servers themselves./p>p>That latter decision was made for me when Verio, an Internet companywhich had purchased ClarkNet, demanded administrative access to my servers.Since the buyout a year earlier, I had had a number of problems with Verio,and I simply didn’t trust them enough to give them full access toDragonfire’s systems.  So I talked with Mikel, and we decided to movethe servers to the same place Dreamhaven was located, a provider in Utah.After finishing up the semester, I headed home and retrieved the serversfrom their colocation site; and the last I ever saw of Bahamut and Palantirwas when I packed them up on December 28 for shipping to Utah./p>!------------------------------------------------------------------------>hr />div ids-1999 classtitle>h2>1999: Departing the Nest/h2>/div>p>I can’t recall exactly what gave me the final push toward mydecision to let Dragonfire go.  As I mentioned above, the administrativeside of Dragonfire was a continuing burden on both my time and my spirits;I certainly wanted to go to Japan with as few extraneous things on my mindas possible.  And the fact that the servers were now out of my reach mayhave made it easier to come to that final determination./p>p>As I prepared to return to Carnegie Mellon for my final semester ofschool, I broached the issue to Mikel:  Would you be interested in takingover Dragonfire?/p>p>He was delighted at the opportunity, and over the course of several morediscussions, we finalized an agreement whereby I would turn Dragonfire overto him, and he would pay me a percentage of profits to cover the cost ofthe equipment.  And on February 13, I officially left my post asadministrator./p>p>That choice was probably the best one that could have been made from theviewpoint of Dragonfire and its users.  Mikel was technically competent,and moreover, he didn’t shy away from administration as I tended todo.  He also had experience running his own (albeit small) provider, and hehad worked for a larger, commercial operation as well.  He had the serversunder his direct control, so he would be able to resolve any problems farmore easily than I could if I had to administer them remotely./p>p>And yet, it was a hard decision to make.  After all, Dragonfire (andDragon before it) had been with me for over four years; for all thetrouble it had been at times, I had grown rather attached to it.  It wouldcertainly be a relief not to have to deal with support request aftersupport request, not to have to worry about whether one of the machineswas a bit too loaded or one of the hard disks was getting a bit too full.But I would have no more opportunities to work on optimizing the serverprocesses, no more chances to come up with another useful tool for users.I would no longer be able to glance at the system monitor screen and seeeverything running along smoothly.  I didn’t have the faintest ideawhat I was going to do with all the time I’d normally spend workingon Dragonfire./p>p>In the end, though, what mattered was Dragonfire’s users—andif Dragonfire’s users were best served by my stepping out of thepicture, then so it must be.  I stayed around to help Mikel with thetransition, of course; but Dragonfire had concluded its final chapter undermy care, and I could only gaze after it as it flew off to new skies./p>p>Looking back on Dragonfire now, I’m fairly incredulous that peoplewere willing to publish their websites on what was frankly a shoestringoperation, especially after I started charging for service and stillcouldn’t improve things much.  Even for the time, Dragonfire probablyranked among one of the least stable service providers on the Internet./p>p>While I honestly tried to provide the best service I could, I may wellhave hurt Dragonfire by setting my sights too low.  As can be seen fromDragonfire’s website (see thea hrefwebsite-1998/faq.html#downtime>FAQ on downtime/a>), I explicitlydisclaimed any intent to try for 100% uptime, even going so far as to bringup the adage “you get what you pay for”—with Dragonfireitself as the victim!  I was only intending to be realistic, but suchstatements probably turned into a subconscious excuse to let problems slideby.  In truth, I tended to wait until issues like lack of disk space or CPUpower actually manifested themselves before taking action, rather thanthinking ahead and preventing the problems from occurring in the firstplace./p>p>I think that attitude may have stemmed from a hesitation to go—onemight even say fear of going—truly commercial, in the broadest sense.I never really got over thinking of Dragonfire as a hobby, an experimentwith which to occupy my free time, and thus I never seriously consideredthe possibility of expanding it as abusiness.a idfootback-22 href#footnote-22>sup>22/sup>/a>  Ieschewed at least one opportunity to visit a trade show and learn fromothers in the industry—undoubtedly there were many such conferencesI could have attended, but I still have the unused tickets and theinvitation letter from ClarkNet to the May 1997 ITEC Expo.  It’s beentoo many years since then to recall my thoughts of the time with anyclarity, but I suspect that at heart, I didn’t really want to run aservice provider for any extended length of time.  The technical aspectswere interesting, certainly, and I enjoyed working through the variousdifficulties I ran into (however much distress they may have caused theusers); but as I commented above, I found the administrative aspects rathertiresome to deal with.  My growing interest in Japan at the time wasundoubtedly another factor; even before my internship was finalized, I wasprobably reluctant to tie myself to a job in the USA without investigatingpossibilities abroad./p>!------------------------------------------------------------------------>hr />div ids-2000 classtitle>h2>2000 and Beyond: Final Thoughts/h2>/div>p>In the decade since my experiences with Dragonfire, the World WideWeb—and the Internet as a whole—have changed dramatically.Websites are no longer just a cute little toy for people to play aroundwith; these days, i>everything/i> is on the web.  (In fact, there’sso much on the web that it would be practically impossible to navigatewithout search engines like Google.)/p>p>Perhaps from the length of my experience with the web, I tend to beskeptical of the new fads that arise in web technology from time to time.From Netscape’s loved-then-hated tt><blink>/tt> tag toframesets and scrolling status bar text, any number of ideas have popped upand quickly vanished.  On the whole, however, I’ve seen the webtransform from a mostly static repository of information to a dynamiccommunity of users.  “Wikis” (such as thea hrefhttps://www.wikipedia.org/>Wikipedia/a> project), allowing usersto collaborate in creating a website, are probably the most visibleexamplea idfootback-23 href#footnote-23>sup>23/sup>/a> of this,and are a striking demonstration of the Internet’s power to connectpeople./p>p>On the hosting side, things seem to have pretty much settled down.There are still free hosting services, generally supported by advertising;I’m mildly opposed to the concept of advertising as applied to theweb (though I don’t find the text-based ads common today quite asobjectionable), which is one reason I didn’t seriously consider itfor Dragonfire.  The pay services seem to be generally run by largercompanies, with little room for small players anymore—Dragonfireitself was squeezed out of the provider business late in 2000.  On theother hand, the very concept of “web service provider” hasgrown and changed since the 1990s.  There are still simple hosting serviceslike Dragonfire was, but there are also application service providers, website designers, and more.  Now that the base Internet technologies arenearly ubiquitous, I suspect entrepreneurs will need to find clever ways ofmaking use of those technologies in order to succeed./p>p>So what’s in store next for the World Wide Web?  That Idon’t know.  I doubt the often-hyped “semantic web” willmaterialize in the near future, at least in its full-fledged form; thenatural language processing technology needed to make this useful is, likemost advancements in artificial intelligence, at least 20 yearsoff.a idfootback-24 href#footnote-24>sup>24/sup>/a>  With duerespect to Tim Berners-Lee, I’m also not sure a semantic web isreally needed, though I’m certain the associated research will proveuseful for other ends./p>p>Without a doubt, the web’s primary power lies in connecting peopleto information.  I still remember an occasion, sometime in the early 2000s,when I became curious about a song I heard playing on a cafeterialoudspeaker; without thinking, I pulled out my mobile phone, brought upGoogle, and searched for a phrase from the song.  Thirty seconds later, Ihad learned the song’s title and artist—and only then did Irealize what I had just done: located exactly the information I was lookingfor out of an immeasurable flood of bits and bytes in almost no time atall.  Before the advent of the web, I would have had to chance acrosssomeone else who knew the song and hope that they recognized it from asingle phrase, a task so daunting I probably would have just given up./p>p>More important than raw information, though, are the people behind it.Wikis aren’t just an information depot; they bring together thepeople behind that information, letting them find and work with others whoshare their interests.  More recently, social networking services such asMySpace and Facebook have brought this aspect of the web to the forefront.As the web becomes more dynamic in nature, I expect to see increasedemphasis on this sort of interpersonal connectivity./p>p>I do have to admit to uncertainty over whether we, the human race, areready for such a level of connectedness.  Just a hundred years ago,instantaneous communication around the world was the sole province of a fewtelegraph operators, and countries (especially on different continents)were separated by so much travel time they might as well have beendifferent worlds.  Even now, despite the vast leaps made in technology,needless conflicts continue to arise out of simple misunderstandings orfailures to communicate; and I fear that dropping such a powerful tool asthe Internet into the middle of that mess will only exacerbate theproblem—after all, a tool that can spread information can alsospread misinformation.  But even if it does prove disruptive, I believe wewill eventually learn how to use it well, to help eliminate themisunderstandings that separateus.a idfootback-25 href#footnote-25>sup>25/sup>/a>  If nothingelse, the teenagers of the future will probably just brush us old fogiesoff to some remote corner of the ’Net and go on their merry,enlightened way./p>!------------------------------------------------------------------------>hr />div ids-2021 classtitle>h2>2021 Addendum/h2>/div>p>How the Internet has grown!  Just 25 years on from running Dragonfireand about half that since first writing this retrospective, much of theworld now lives in an Internet-centric society.  Government services areavailable online, and sometimes only online; ride-hailing apps haveovertaken taxi call centers; most people are walking around with abouttwo orders of magnitude more computing power in their pocket thanDragonfire ever had in its data center rack./p>p>But thinking back over the intervening time, I can’t really sayanything took me by surprise.  Each individual step was reasonablyapparent from the previous one, and while I certainly put effort intostaying abreast of current research and practice, that was more out ofpersonal interest than necessity.  Miniaturization of components andimprovements in touchscreen technology created the smartphone, arguably abetter candidate for the term “personal computer” than the IBMPC which begat that term; replacement of traditional mobile phones bysmartphones encouraged the development of online services based aroundeach person having their own computer; and while MySpace has effectivelybeen consigned to history, Facebook now connects a significant fraction ofthe global human population.  (And I would be remiss not to point outthat, 13 years into my 20-year prediction, natural language processingstill hasn’t advanced enough for the “semantic web” tobe a thing.)/p>p>On the less pleasant side of things, my prediction of the Internetbeing used to spread misinformation unfortunately appears to have beenspot-on.  Who, in any Internet-connected society, has not heard aboutso-called “fake news” by now?  While the term itself is a sortof misinformation in that it is often used to label inconvenient factswhich the speaker wishes their audience to ignore, actual “fakenews” in the sense of lies presented as truth has rapidly become amajor societal problem.  Worse, the fabrications are not limited to text;advances in image and sound processing technology have made it possible toliterally put words in people’s mouths, to create convincingsimulations of people saying things they did not in fact say.  (Wedidn’t have the technology to simulate the moon landing in 1969, toreference a persistent conspiracy theory, but we might well be able to doit in 2021.)  I fear this plague of misinformation will get worse beforeit gets better./p>p>One additional trend I find a bit disturbing is what I might call a rushto collective judgment over violations of societal norms.  In one recentexample as of this writing (April 2021), video streaming service Twitchdeclared that it would act against users of its service who engaged inhate speech or similar undesirable actions, even if those actions were notperformed on Twitch itself.  While I imagine that this is more a knee-jerkreaction to recent events than a deeply-considered change of approach, itnonetheless sounds eerily similar to the “good citizen” clauseof Dragonfire’s rules which I discussed under thea href#s-1996>“1996”/a> section, and I find it just asconcerning as in Dragonfire’s case—perhaps more so,because viewer subscriptions are a nontrivial part of income for at leastsome of Twitch’s users.  Given how quickly people seem to claiminsult from even well-intentioned discussion of sensitive topics thesedays, and how difficult it often is for a single user to challenge a largecompany—or secure proper reparations even if they aresuccessful—would such users not fear engaging in opendiscussion, however objectively reasonable that discussion might be?  Thatis the sort of chilling effect for which I regretted my own decision toadd Dragonfire’s “good citizen” clause, and I find it noless relevant here./p>p>At the same time, I don’t dispute that proactive silencing oftroublemaking users may be necessary for the good of society.  Even fromthe days of the first “flash mobs”, it was clear that theability to instantly transmit information to a wide audience raised riskswhich traditional societal systems are ill-equipped to address.  One mightmake the superficially sensible argument that judicial instutitions suchas courts are the proper forum in which to censure troublemakers, but whenthey can make their trouble and be done with it before law enforcement iseven aware trouble has been made, that offers little solace to those whohave been injured by the trouble.  In the particular case of disseminatingmisinformation, even punishment of the disseminator will not stop thatmisinformation from spreading; lacking any way to, perhaps,“inoculate” ordinary users against misinformation, it seemsthe best we can manage is this sort of collective defense, despite thechilling effects it entails.  (Sadly, I have no solution to offer for thisconundrum.  So much for age begetting wisdom . . .)/p>p>Perhaps in my frustration at seeing us stuck in this“misinformation” stage, I have developed a fair amount ofantipathy toward social media services as they are currently implemented.What ought to be a tool allowing us to talk i>with/i> other people isinstead abused to talk i>at/i> other people, without expectation of aproper conversation—and perhaps even in search ofcontroversy, since angry interchanges draw viewers and provide the“likes” which offer such a seductive, if shallow, sense ofself-worth.  In particular, I feel that Twitter and its emphasis on shortmessages encourage what one might call “animal reactions”rather than reasoned discussion, and while I grant that Twitter has helpedpeople as well, I admit that I would not be at all disappointed to wake upone morning and find that it had shut down./p>p>I do hold out hope that, since my intuition has proven correct inforecasting the current flood of misinformation, it may also prove correctin predicting that we will eventually learn to move beyond this stage, totruly understand the nature of this instant communication and how we canuse it to build a better society for all rather than simply destroy thatwith which we disagree.  I often find myself thinking back on a remark Iwrote as a footnote toward the original end of this piece, on the topic ofmisunderstandings caused by instant communication, which I will quote here:/p>    p classblockquote>I don’t mean to suggest that we should    eliminate the differences that lead to such misunderstandings; I, at    least, find the view of a homogeneous human race espoused by some    science fiction stories rather dystopian. It’s my hope that    technologies like the Internet will help us better i>understand,/i>    and accept, each other’s differences.  It is those differences,    after all, that make human society so vibrant./p>p styletext-indent: 0;>So many of the disputes I have seen in recentyears feel to me as though they stem from a reflexive rejection ofanything or anyone different from the speaker, to the point where I wantto cry out, i>That’s not how it was supposed to be!/i>  Being bothold enough to have lived during pre-Internet days and known the ideals ofharmony to which that era aspired, but also young enough to have grown uparound computers and have a native understanding of the relatedtechnologies and at least some of their ramifications, I have longenvisioned a future in which Internet-style instant communication servedas a ubiquitous adjunct to our lives, letting us bridge physical andsocial gaps even more easily and building an ever-wider, ever-more-diverseglobal society.  And while I sometimes feel a touch of despair seeingpeople worldwide retreat into their own small, homogeneous tribes, I alsorealize that—much like pandemics, to reference anothercurrent source of concern—periods of trouble feel much longerto live through than to simply read about as past events.  Indeed, it hasbeen said that living through bad times is what reminds us to treasure thegood times, and so I continue to hope that someday, we will be able tobuild that positive, diverse society.  Even if I do get brushed off tosome remote corner of the ’Net as one of those “oldfogies”./p>!------------------------------------------------------------------------>hr />div idfootnotes classtitle>h2>Footnotes/h2>/div>p classfootnote>a idfootnote-1 href#footback-1>sup>1/sup>/a>“Baud”(also “baud rate”; named after Émile Baudot, an earlytelegraph engineer) refers to the number of i>symbols/i> per secondtransmitted over a communication link.  Early computer modems used a simplecoding scheme with only two symbols, corresponding to the values 0 and 1,such that each transmitted symbol contained exactly one bit of information;in this scheme, the baud rate and data rate (number of i>bits/i> persecond) are equal.  Later modems used more complex schemes which allowedmore than one bit of information to be packed into a symbol; for example,modems communicating at 2400 bits per second typically ran at 600 baud,packing 4 bits of information into each symbol sent over the telephoneline.  Nonetheless, “baud” was misused by many (including thisauthor, who didn’t know better at the time) to refer to data rate,perhaps because it was easier to say “2400 baud” than“2400 bits per second”./p>p classfootnote>a idfootnote-2 href#footback-2>sup>2/sup>/a>SerialLine Internet Protocol, a protocol used to establish Internet connectionsover modems and similar point-to-point links before PPP (Point-to-PointProtocol) became prevalent./p>p classfootnote>a idfootnote-3 href#footback-3>sup>3/sup>/a>Laterknown as Netscape Navigator.  At the time of this writing (February 2008),Netscape is no longer being developed, though the currently popular Firefoxbrowser was born from the Netscape source code several years ago./p>p classfootnote>a idfootnote-4 href#footback-4>sup>4/sup>/a>Thesource code to the final version of the server can be found in thea href#resources>Resources/a> section of this retrospective./p>p classfootnote>a idfootnote-5 href#footback-5>sup>5/sup>/a>Atpresent (February 2008), I routinely obtain sustained speeds exceeding40Mbps in both directions through my consumer-grade fiber-optic Internetconnection, and I can transfer 1GB files between my home network in Japanand a USA-based server in three to four minutes./p>p classfootnote>a idfootnote-6 href#footback-6>sup>6/sup>/a>Or“floppies”, as they are typically called these days (2008).Through the mid-1990s, at least, the term “diskette” wassometimes used to differentiate rigid 3½-inch disks from the flexible(“floppy”) 5¼-inch disks that had preceded them./p>p classfootnote>a idfootnote-7 href#footback-7>sup>7/sup>/a>Theact of registering domains for the sole purpose of selling them to othersat higher prices.  At the time of this writing (February 2008),“tt>dragonfire.net/tt>” is owned by a speculator askingUS$320,000 for the domain.  (December 2019 update: tt>dragonfire.net/tt>became available for a much lower cost, and I have obtained it to use as ahome for this retrospective.)/p>p classfootnote>a idfootnote-8 href#footback-8>sup>8/sup>/a>Withthe name change, I also gained the opportunity to give my server its ownhostname in the tt>dragonfire.net/tt> domain.  The name I chose,“Bahamut”, comes from a recurring dragon character in theFinal Fantasy series of video games; given that many of the sites onDragonfire at the time were related to video games or similar interests, itseemed quite appropriate./p>p classfootnote>a idfootnote-9 href#footback-9>sup>9/sup>/a>Thisprogram was based on an earlier script that simply ran the tt>uptime/tt>,tt>free/tt>, and tt>df/tt> commands over and over.  The first lineshows the current time, system uptime, number of logins, load averages, andprocess count; the next line shows memory usage in 1024-byte units; and thedisk status lines show percentage of data space used, used and total dataspace (in 1024-byte blocks), used and total number of inodes, andpercentage of inodes used.  Source code for the program is available in thea href#resources>Resources/a> section./p>p classfootnote>a idfootnote-10 href#footback-10>sup>10/sup>/a>IntegratedServices Digital Network, a technology allowing reliable, high-speed(for the time) connections over ordinary telephone wires by sending datadigitally through the telephone network, skipping the analog/digitalconversions necessary for modems which reduced data throughput.  Potentialcustomers of the time also expanded the acronym as “I StillDon’t kNow”, for reasons which will become apparent shortly./p>p classfootnote>a idfootnote-11 href#footback-11>sup>11/sup>/a>The“account name” was my way of working around the traditional8-character limit on Unix usernames.  I required each new user to select ausername following the traditional Unix rules, but also allowed the user toselect a different name—the account name—to be used in URLs;so, for example, a user could have the username tt>johnpage/tt> but theURL tt>http://www.dragonfire.net/~JohnsHomePage//tt>./p>p classfootnote>a idfootnote-12 href#footback-12>sup>12/sup>/a>Thenetwork used simple Ethernet hubs to connect dormitory rooms, such that allcomputers in the building were effectively connected to the same physicalcommunication link.  This design introduces the risk of i>collisions:/i>if two computers try to send data at the same time, the signals willinterfere with each other and the data will be lost, forcing both computersto retransmit the lost data.  As the amount of data transmitted on a linkincreases, so does the rate of collisions; eventually, collisions become sofrequent that they consume most of the network’s capacity and theeffective data rate begins to decrease.  This enforces a “speedlimit” on the network which can be significantly lower than thetheoretical capacity./p>p classfootnote>a idfootnote-13 href#footback-13>sup>13/sup>/a>Thatworry was punctuated by one final untoward event:  Dragonfiredisappeared from the net shortly into winter vacation, only to reappearseveral days later.  On the a hrefwebsite-1998/history.html>historypage/a>, I explained this as the apparent result of a maliciousintrusion.  I must, however, make an embarrassing admission:  That may wellhave been a lie to cover a careless mistake of my own.  Over a decadelater, of course, there is no longer any way to know exactly what happened,but I have a distinct recollection of discovering that I had done somethingincredibly stupid, then frantically searching for any plausible excuse toexplain it away.  It’s also possible that I only thought I had made amistake, and the system really was broken into; but even if so, I’mjust as much at fault for not securing the system well enough.  The detailsare, regrettably, too hazy at this point to say one way or another; but thefact that I have such a clear memory of i>something/i> happening suggeststhat there’s more to the story than that single history file entry.If that’s the case, I can only say:  i>Mea culpa./i>  I screwed up,and I’m sorry./p>p classfootnote>a idfootnote-14 href#footback-14>sup>14/sup>/a>Thosewith business management experience may note one cost I neglected toconsider: that of my own compensation for running Dragonfire.  Whetherbecause I was still a student and therefore didn’t consider myselfworthy of a salary, because I simply didn’t need the additionalincome at the time, or for whatever reason, it never occurred to me toinclude a salary to myself in Dragonfire’s costs.  By the time I hadthis omission pointed out to me, Dragonfire had already been runningcommercially for several months, and at that point I could hardly justifyraising fees simply because I wanted to give myself some money./p>p classfootnote>a idfootnote-15 href#footback-15>sup>15/sup>/a>Theprimary “trunk” lines through which all Internet data passes.Much like the USA’s Interstate road network or Japan’s bullettrains (i>Shinkansen/i>), the Internet backbones connect to each otherand to the largest service providers; those service providers, in turn,connect to smaller providers like Dragonfire.  Typically, data from acomputer connected to the Internet will pass through four or five differentnetworks before reaching its destination./p>p classfootnote>a idfootnote-16 href#footback-16>sup>16/sup>/a>DistributedDenial of Service, a type of attack that floods its target with so muchdata that the target becomes inaccessible.  DDoS attacks are typicallycarried out via ordinary Internet users’ computers which have beeninfected with viruses or other malicious software, and (as in this case)can severely hurt even the largest networks—this is why it’simportant for every Internet user to learn how to protect themselves fromsuch malicious software./p>p classfootnote>a idfootnote-17 href#footback-17>sup>17/sup>/a>Atthat time, each separate hostname on a server was normally given its own IPaddress.  A subsequent extension to the HTTP protocol allowed multiplehostnames to be served from the same IP address, and this latter extensionis now almost universally used./p>p classfootnote>a idfootnote-18 href#footback-18>sup>18/sup>/a>Sourcecode for the program is available in the a href#resources>Resources/a>section.  As a cursory examination of the source code will show, the onlysecurity on the control connection was a secret port number, a passwordsent in the clear, and source IP address checking.  I’m lucky nobodyfigured out how to spoof TCP sequence numbers while I was using it./p>p classfootnote>a idfootnote-19 href#footback-19>sup>19/sup>/a>Astutereaders will notice that two of the memory values (207441 and 104856) havethe last digit truncated.  At the time I wrote the program, PC-classsystems with more than a gigabyte of memory were still far in the future./p>p classfootnote>a idfootnote-20 href#footback-20>sup>20/sup>/a>HostAmerica.com(no relation to the current owner of the domain).  From what I can tell,HostAmerica was later bought by a provider called Sage Networks, whichitself merged with another company named Interliant before going bankruptin mid-2002./p>p classfootnote>a idfootnote-21 href#footback-21>sup>21/sup>/a>TheDigital Millenium Copyright Act, a law passed later in 1998 which updatedvarious parts of USA copyright law with respect to computers and theInternet.  The portion of the DMCA relevant to this discussion is Title II,which grants service providers immunity from copyright liability if theypromptly remove allegedly copyrighted material from users’ accountswhen notified of its presence./p>p classfootnote>a idfootnote-22 href#footback-22>sup>22/sup>/a>Inthe end, Dragonfire never did earn enough money to recover my initialout-of-pocket expenses.  While it brought in about $2,000 a year (net) overits commercial life, I was short $1,421 as of November 1998, the last monthfor which I still have data.  Between the last three months I operatedDragonfire and the sale of Dragonfire itself, I may or may not have made upthat difference, but either way, Dragonfire never turned a significantprofit./p>p classfootnote>a idfootnote-23 href#footback-23>sup>23/sup>/a>Ialmost listed weblogs (“blogs”) instead, but it occurred to methat those are really no different in substance from the “bulletinboards” for which pre-Internet BBS systems were named.  Everythingold is new again, I suppose./p>p classfootnote>a idfootnote-24 href#footback-24>sup>24/sup>/a>Onecynical view of this “20 years” phenomenon is that it’sjust long enough for the person making the prediction to retire beforebeing called on its inaccuracy.  Having studied a bit of artificialintelligence myself, I think honest optimism is closer to the truth.Computer science in general is a field pervaded by optimism, which in manycases is justified; artificial intelligence is simply a branch of the fieldwhich has more roadblocks and unexpected twists than usual./p>p classfootnote>a idfootnote-25 href#footback-25>sup>25/sup>/a>Idon’t mean to suggest that we should eliminate the differences thatlead to such misunderstandings; I, at least, find the view of a homogeneoushuman race espoused by some science fiction stories rather dystopian.It’s my hope that technologies like the Internet will help us betteri>understand,/i> and accept, each other’s differences.  It is thosedifferences, after all, that make human society so vibrant./p>!------------------------------------------------------------------------>hr />div idresources classtitle>h2>Resources/h2>/div>dl>dt idr-website>a hrefwebsite-1998/index.html>Dragonfire’s website (as of December 1998)/a>/dt>    dd>The Dragonfire Internet Services website, more or less as it        appeared on December 12, 1998.  Some internal links have been        adjusted to work correctly at the current URL, and outdated links        to external sites have been disabled.  (Changes to links can be        seen by viewing the source of each page.)/dd>dt idr-httpd>a hrefamiga-httpd/>Custom Amiga HTTP server/a>/dt>    dd>The source and object code to the custom HTTP server I wrote for        my Amiga in 1995.  The program was built with the DICE C compiler        and the accompanying tt>dmake/tt> tool./dd>dt idr-sysstat>a hrefsysstat/>System status display program/a>/dt>    dd>The source code for the simple system status display program I        initially used (a precursor to the system monitoring program listed        below), along with an updated version of the program that works in        modern Linux environments./dd>dt idr-sysmon>a hrefsysmon/>System monitoring program/a>/dt>    dd>The source code and configuration files for the custom system        monitoring program I created for Dragonfire.  Aside from minor        changes to work in modern Linux environments (and removal of the        hardcoded password), the program is unchanged from its form at the        time I sold Dragonfire in 1999./dd>/dl>!------------------------------------------------------------------------>hr />div classfootleft>a hrefhttps://achurch.org/>Andrew Church/a>/div>div classfootright>Last modified: 2021/10/28/div>/body>/html>

Port 443

HTTP/1.1 200 OKDate: Tue, 24 Feb 2026 03:40:02 GMTAccept-Ranges: bytesContent-Length: 112167Content-Type: text/html

View on OTX | View on ThreatMiner

Data with thanks to AlienVault OTX, VirusTotal, Malwr and others. [Sitemap]

Domain > www.dragonfire.net

Is this malicious?

DNS Resolutions

Port 80

Port 443