-
-
Notifications
You must be signed in to change notification settings - Fork 0
/
34.txt
4371 lines (3439 loc) · 180 KB
/
34.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Project Gutenberg's Zen and the Art of the Internet, by Brendan P. Kehoe
This eBook is for the use of anyone anywhere at no cost and with
almost no restrictions whatsoever. You may copy it, give it away or
re-use it under the terms of the Project Gutenberg License included
with this eBook or online at www.gutenberg.org
** This is a COPYRIGHTED Project Gutenberg eBook, Details Below **
** Please follow the copyright guidelines in this file. **
Title: Zen and the Art of the Internet
Author: Brendan P. Kehoe
Posting Date: December 17, 2011 [EBook #34]
Release Date: June, 1992
Language: English
Character set encoding: ASCII
*** START OF THIS PROJECT GUTENBERG EBOOK ZEN AND THE ART OF THE INTERNET ***
Part A
Zen and the Art of the Internet
Copyright (c) 1992 Brendan P. Kehoe
Permission is granted to make and distribute verbatim copies of this
guide provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of
this booklet under the conditions for verbatim copying, provided that
the entire resulting derived work is distributed under the terms of a
permission notice identical to this one.
Permission is granted to copy and distribute translations of this
booklet into another language, under the above conditions for
modified versions, except that this permission notice may be stated
in a translation approved by the author.
Zen and the Art of the Internet
A Beginner's Guide to the Internet
First Edition
January 1992
by Brendan P. Kehoe
This is revision 1.0 of February 2, 1992.
Copyright (c) 1992 Brendan P. Kehoe
The composition of this booklet was originally started because the
Computer Science department at Widener University was in desperate
need of documentation describing the capabilities of this "great new
Internet link" we obtained.
It's since grown into an effort to acquaint the reader with much of
what's currently available over the Internet. Aimed at the novice
user, it attempts to remain operating system "neutral"---little
information herein is specific to Unix, VMS, or any other
environment. This booklet will, hopefully, be usable by nearly
anyone.
A user's session is usually offset from the rest of the paragraph, as
such:
prompt> command
The results are usually displayed here.
The purpose of this booklet is two-fold: first, it's intended to
serve as a reference piece, which someone can easily grab on the fly
and look something up. Also, it forms a foundation from which people
can explore the vast expanse of the Internet. Zen and the Art of the
Internet doesn't spend a significant amount of time on any one point;
rather, it provides enough for people to learn the specifics of what
his or her local system offers.
One warning is perhaps in order---this territory we are entering can
become a fantastic time-sink. Hours can slip by, people can come and
go, and you'll be locked into Cyberspace. Remember to do your work!
With that, I welcome you, the new user, to The Net.
Chester, PA
Acknowledgements
Certain sections in this booklet are not my original work---rather,
they are derived from documents that were available on the Internet
and already aptly stated their areas of concentration. The chapter
on Usenet is, in large part, made up of what's posted monthly to
news.announce.newusers, with some editing and rewriting. Also, the
main section on archie was derived from whatis.archie by Peter
Deutsch of the McGill University Computing Centre. It's available
via anonymous FTP from archie.mcgill.ca. Much of what's in the
telnet section came from an impressive introductory document put
together by SuraNet. Some definitions in the one are from an
excellent glossary put together by Colorado State University.
This guide would not be the same without the aid of many people on The
Net, and the providers of resources that are already out there. I'd
like to thank the folks who gave this a read-through and returned some
excellent comments, suggestions, and criticisms, and those who
provided much-needed information on the fly. Glee Willis deserves
particular mention for all of his work; this guide would have been
considerably less polished without his help.
Andy Blankenbiller <[email protected]>
Andy Blankenbiller, Army at Aberdeen
Alan Emtage, McGill University Computer Science Department
Brian Fitzgerald <[email protected]>
Brian Fitzgerald, Rensselaer Polytechnic Institute
John Goetsch <[email protected]>
John Goetsch, Rhodes University, South Africa
Jeff Kellem, Boston University's Chemistry Department
Bill Krauss, Moravian College
Steve Lodin <[email protected]>
Steve Lodin, Delco Electronics
Mike Nesel <[email protected]>
Mike Nesel, NASA
Bob <[email protected]>
Bob Neveln, Widener University Computer Science Department
[email protected] (Wanda Pierce)
Wanda Pierce, McGill University Computing Centre
Joshua Poulson, Widener University Computing Services
Dave Sill, Oak Ridge National Laboratory
Bob Smart, CitiCorp/TTI
Ed Vielmetti, Vice President of MSEN
Craig E. Ward <[email protected]>
Craig Ward, USC/Information Sciences Institute (ISI)
Glee Willis <[email protected]>
Glee Willis, University of Nevada, Reno
Charles Yamasaki <[email protected]>
Chip Yamasaki, OSHA
Network Basics
We are truly in an information society. Now more than ever, moving
vast amounts of information quickly across great distances is one of
our most pressing needs. From small one-person entrepreneurial
efforts, to the largest of corporations, more and more professional
people are discovering that the only way to be successful in the '90s
and beyond is to realize that technology is advancing at a break-neck
pace---and they must somehow keep up. Likewise, researchers from all
corners of the earth are finding that their work thrives in a
networked environment. Immediate access to the work of colleagues
and a "virtual" library of millions of volumes and thousands of
papers affords them the ability to encorporate a body of knowledge
heretofore unthinkable. Work groups can now conduct interactive
conferences with each other, paying no heed to physical
location---the possibilities are endless.
You have at your fingertips the ability to talk in "real-time" with
someone in Japan, send a 2,000-word short story to a group of people
who will critique it for the sheer pleasure of doing so, see if a
Macintosh sitting in a lab in Canada is turned on, and find out if
someone happens to be sitting in front of their computer (logged on)
in Australia, all inside of thirty minutes. No airline (or tardis,
for that matter) could ever match that travel itinerary.
The largest problem people face when first using a network is
grasping all that's available. Even seasoned users find themselves
surprised when they discover a new service or feature that they'd
never known even existed. Once acquainted with the terminology and
sufficiently comfortable with making occasional mistakes, the
learning process will drastically speed up.
Domains
Getting where you want to go can often be one of the more difficult
aspects of using networks. The variety of ways that places are named
will probably leave a blank stare on your face at first. Don't fret;
there is a method to this apparent madness.
If someone were to ask for a home address, they would probably expect
a street, apartment, city, state, and zip code. That's all the
information the post office needs to deliver mail in a reasonably
speedy fashion. Likewise, computer addresses have a structure to
them. The general form is:
a person's email address on a computer: [email protected]
a computer's name: somewhere.domain
The user portion is usually the person's account name on the
system, though it doesn't have to be. somewhere.domain tells
you the name of a system or location, and what kind of organization it
is. The trailing domain is often one of the following:
com
Usually a company or other commercial institution or organization,
like Convex Computers (convex.com).
edu
An educational institution, e.g. New York University, named nyu.edu.
gov
A government site; for example, NASA is nasa.gov.
mil
A military site, like the Air Force (af.mil).
net
Gateways and other administrative hosts for a network (it does not
mean all of the hosts in a network). {The Matrix, 111. One such
gateway is near.net.}
org
This is a domain reserved for private organizations, who don't
comfortably fit in the other classes of domains. One example is the
Electronic Frontier Foundation named eff.org.
Each country also has its own top-level domain. For example, the
us domain includes each of the fifty states. Other countries
represented with domains include:
au Australia
ca Canada
fr France
uk The United Kingdom. These also have sub-domains of things like
ac.uk for academic sites and co.uk for commercial ones.
FQDN (Fully Qualified Domain Name)
The proper terminology for a site's domain name (somewhere.domain
above) is its Fully Qualified Domain Name (FQDN). It is usually
selected to give a clear indication of the site's organization or
sponsoring agent. For example, the Massachusetts Institute of
Technology's FQDN is mit.edu; similarly, Apple Computer's domain name
is apple.com. While such obvious names are usually the norm, there
are the occasional exceptions that are ambiguous enough to
mislead---like vt.edu, which on first impulse one might surmise is an
educational institution of some sort in Vermont; not so. It's
actually the domain name for Virginia Tech. In most cases it's
relatively easy to glean the meaning of a domain name---such
confusion is far from the norm.
Internet Numbers
Every single machine on the Internet has a unique address, {At least
one address, possibly two or even three---but we won't go into
that.} called its Internet number or IP Address. It's actually a
32-bit number, but is most commonly represented as four numbers
joined by periods (.), like 147.31.254.130. This is sometimes also
called a dotted quad; there are literally thousands of different
possible dotted quads. The ARPAnet (the mother to today's Internet)
originally only had the capacity to have up to 256 systems on it
because of the way each system was addressed. In the early eighties,
it became clear that things would fast outgrow such a small limit;
the 32-bit addressing method was born, freeing thousands of host
numbers.
Each piece of an Internet address (like 192) is called an "octet,"
representing one of four sets of eight bits. The first two or three
pieces (e.g. 192.55.239) represent the network that a system is on,
called its subnet. For example, all of the computers for Wesleyan
University are in the subnet 129.133. They can have numbers like
129.133.10.10, 129.133.230.19, up to 65 thousand possible
combinations (possible computers).
IP addresses and domain names aren't assigned arbitrarily---that
would lead to unbelievable confusion. An application must be filed
with the Network Information Center (NIC), either electronically (to
[email protected]) or via regular mail.
Resolving Names and Numbers
Ok, computers can be referred to by either their FQDN or their
Internet address. How can one user be expected to remember them all?
They aren't. The Internet is designed so that one can use either
method. Since humans find it much more natural to deal with words
than numbers in most cases, the FQDN for each host is mapped to its
Internet number. Each domain is served by a computer within that
domain, which provides all of the necessary information to go from a
domain name to an IP address, and vice-versa. For example, when
someone refers to foosun.bar.com, the resolver knows that it should
ask the system foovax.bar.com about systems in bar.com. It asks what
Internet address foosun.bar.com has; if the name foosun.bar.com
really exists, foovax will send back its number. All of this
"magic" happens behind the scenes.
Rarely will a user have to remember the Internet number of a site
(although often you'll catch yourself remembering an apparently
obscure number, simply because you've accessed the system
frequently). However, you will remember a substantial number of
FQDNs. It will eventually reach a point when you are able to make a
reasonably accurate guess at what domain name a certain college,
university, or company might have, given just their name.
The Networks
Internet
The Internet is a large "network of networks." There is no
one network known as The Internet; rather, regional nets like SuraNet,
PrepNet, NearNet, et al., are all inter-connected
(nay, "inter-networked") together into one great living thing,
communicating at amazing speeds with the TCP/IP protocol. All
activity takes place in "real-time."
UUCP
The UUCP network is a loose association of systems all communicating
with the UUCP protocol. (UUCP stands for `Unix-to-Unix Copy
Program'.) It's based on two systems connecting to each other at
specified intervals, called polling, and executing any work
scheduled for either of them. Historically most UUCP was done with
Unix equipment, although the software's since been implemented on
other platforms (e.g. VMS). For example, the system oregano
polls the system basil once every two hours. If there's any
mail waiting for oregano, basil will send it at that time;
likewise, oregano will at that time send any jobs waiting for
basil.
BITNET
BITNET (the "Because It's Time Network") is comprised of systems
connected by point-to-point links, all running the NJE protocol.
It's continued to grow, but has found itself suffering at the hands of
the falling costs of Internet connections. Also, a number of mail
gateways are in place to reach users on other networks.
The Physical Connection
The actual connections between the various networks take a variety of
forms. The most prevalent for Internet links are 56k leased lines
(dedicated telephone lines carrying 56kilobit-per-second connections)
and T1 links (special phone lines with 1Mbps connections). Also
installed are T3 links, acting as backbones between major locations
to carry a massive 45Mbps load of traffic.
These links are paid for by each institution to a local carrier (for
example, Bell Atlantic owns PrepNet, the main provider in
Pennsylvania). Also available are SLIP connections, which carry
Internet traffic (packets) over high-speed modems.
UUCP links are made with modems (for the most part), that run from
1200 baud all the way up to as high as 38.4Kbps. As was mentioned in
The Networks, the connections are of the store-and-forward
variety. Also in use are Internet-based UUCP links (as if things
weren't already confusing enough!). The systems do their UUCP traffic
over TCP/IP connections, which give the UUCP-based network some
blindingly fast "hops," resulting in better connectivity for the
network as a whole. UUCP connections first became popular in the
1970's, and have remained in wide-spread use ever since. Only with
UUCP can Joe Smith correspond with someone across the country or
around the world, for the price of a local telephone call.
BITNET links mostly take the form of 9600bps modems connected from site
to site. Often places have three or more links going; the majority,
however, look to "upstream" sites for their sole link to the network.
"The Glory and the Nothing of a Name"
Byron, {Churchill's Grave}
-----------
Electronic Mail
The desire to communicate is the essence of networking. People have
always wanted to correspond with each other in the fastest way
possible, short of normal conversation. Electronic mail (or
email) is the most prevalent application of this in computer
networking. It allows people to write back and forth without having
to spend much time worrying about how the message actually gets
delivered. As technology grows closer and closer to being a common
part of daily life, the need to understand the many ways it can be
utilized and how it works, at least to some level, is vital.
part of daily life (as has been evidenced by the ISDN effort, the need
to understand the many ways it can be utilized and how it works, at
least to some level, is vital.
Email Addresses
Electronic mail is hinged around the concept of an address; the
section on Networking Basics made some reference to it while
introducing domains. Your email address provides all of the
information required to get a message to you from anywhere in the
world. An address doesn't necessarily have to go to a human being.
It could be an archive server, {See Archive Servers, for a
description.} a list of people, or even someone's pocket pager.
These cases are the exception to the norm---mail to most addresses is
read by human beings.
%@!.: Symbolic Cacophony
Email addresses usually appear in one of two forms---using the
Internet format which contains @, an "at"-sign, or using the
UUCP format which contains !, an exclamation point, also called
a "bang." The latter of the two, UUCP "bang" paths, is more
restrictive, yet more clearly dictates how the mail will travel.
To reach Jim Morrison on the system south.america.org, one would
address the mail as [email protected]. But if Jim's account was
on a UUCP site named brazil, then his address would be brazil!jm. If
it's possible (and one exists), try to use the Internet form of an
address; bang paths can fail if an intermediate site in the path
happens to be down. There is a growing trend for UUCP sites to
register Internet domain names, to help alleviate the problem of path
failures.
Another symbol that enters the fray is %---it acts as an extra
"routing" method. For example, if the UUCP site dream is connected
to south.america.org, but doesn't have an Internet domain name of its
own, a user debbie on dream can be reached by writing to the address
not smallexample!
debbie%[email protected]
The form is significant. This address says that the local system
should first send the mail to south.america.org. There the address
debbie%dream will turn into debbie@dream, which will hopefully be a
valid address. Then south.america.org will handle getting the mail
to the host dream, where it will be delivered locally to debbie.
All of the intricacies of email addressing methods are fully covered
in the book "!%@@:: A Directory of Electronic Mail Addressing and
Networks" published by O'Reilly and Associates, as part of their
Nutshell Handbook series. It is a must for any active email user.
Write to [email protected] for ordering information.
Sending and Receiving Mail
We'll make one quick diversion from being OS-neuter here, to show you
what it will look like to send and receive a mail message on a Unix
system. Check with your system administrator for specific
instructions related to mail at your site.
A person sending the author mail would probably do something like this:
% mail [email protected]
Subject: print job's stuck
I typed `print babe.gif' and it didn't work! Why??
The next time the author checked his mail, he would see it listed in
his mailbox as:
% mail
"/usr/spool/mail/brendan": 1 messages 1 new 1 unread
U 1 [email protected] Tue May 5 20:36 29/956 print job's stuck
?
which gives information on the sender of the email, when it was sent,
and the subject of the message. He would probably use the
reply command of Unix mail to send this response:
? r
To: joeuser@@foo.widener.edu
Subject: Re: print job's stuck
You shouldn't print binary files like GIFs to a printer!
Brendan
Try sending yourself mail a few times, to get used to your system's
mailer. It'll save a lot of wasted aspirin for both you and your
system administrator.
Anatomy of a Mail Header
An electronic mail message has a specific structure to it that's
common across every type of computer system. {The standard is written
down in RFC-822. See also RFCs for more info on how to get copies of
the various RFCs.} A sample would be:
>From [email protected] Sat May 25 17:06:01 1991
Received: from hq.mil by house.gov with SMTP id AA21901
(4.1/SMI for [email protected]); Sat, 25 May 91 17:05:56 -0400
Date: Sat, 25 May 91 17:05:56 -0400
From: The President <[email protected]>
Message-Id: <[email protected]>
Subject: Meeting
Hi Dan .. we have a meeting at 9:30 a.m. with the Joint Chiefs. Please
don't oversleep this time.
The first line, with From and the two lines for Received: are usually
not very interesting. They give the "real" address that the mail
is coming from (as opposed to the address you should reply to, which
may look much different), and what places the mail went through to
get to you. Over the Internet, there is always at least one
Received: header and usually no more than four or five. When a
message is sent using UUCP, one Received: header is added for each
system that the mail passes through. This can often result in more
than a dozen Received: headers. While they help with dissecting
problems in mail delivery, odds are the average user will never want
to see them. Most mail programs will filter out this kind of
"cruft" in a header.
The Date: header contains the date and time the message was
sent. Likewise, the "good" address (as opposed to "real" address)
is laid out in the From: header. Sometimes it won't include
the full name of the person (in this case The President), and
may look different, but it should always contain an email address of
some form.
The Message-ID: of a message is intended mainly for tracing
mail routing, and is rarely of interest to normal users. Every
Message-ID: is guaranteed to be unique.
To: lists the email address (or addresses) of the recipients of
the message. There may be a Cc: header, listing additional
addresses. Finally, a brief subject for the message goes in the
Subject: header.
The exact order of a message's headers may vary from system to system,
but it will always include these fundamental headers that are vital to
proper delivery.
Bounced Mail
When an email address is incorrect in some way (the system's name is
wrong, the domain doesn't exist, whatever), the mail system will
bounce the message back to the sender, much the same way that the
Postal Service does when you send a letter to a bad street address.
The message will include the reason for the bounce; a common error is
addressing mail to an account name that doesn't exist. For example,
writing to Lisa Simpson at Widener University's Computer Science
department will fail, because she doesn't have an account. {Though if
she asked, we'd certainly give her one.}
From: Mail Delivery Subsystem <MAILER-DAEMON>
Date: Sat, 25 May 91 16:45:14 -0400
Subject: Returned mail: User unknown
----- Transcript of session follows -----
While talking to cs.widener.edu:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 lsimpson... User unknown
As you can see, a carbon copy of the message (the Cc: header
entry) was sent to the postmaster of Widener's CS department. The
Postmaster is responsible for maintaining a reliable mail system
on his system. Usually postmasters at sites will attempt to aid you
in getting your mail where it's supposed to go. If a typing error was
made, then try re-sending the message. If you're sure that the
address is correct, contact the postmaster of the site directly and
ask him how to properly address it.
The message also includes the text of the mail, so you don't have to
retype everything you wrote.
----- Unsent message follows -----
Received: by cs.widener.edu id AA06528; Sat, 25 May 91 16:45:14 -0400
Date: Sat, 25 May 91 16:45:14 -0400
From: Matt Groening <[email protected]>
Message-Id: <[email protected]>
Subject: Scripting your future episodes
Reply-To: [email protected]
.... verbiage ...
The full text of the message is returned intact, including any headers
that were added. This can be cut out with an editor and fed right
back into the mail system with a proper address, making redelivery a
relatively painless process.
Mailing Lists
People that share common interests are inclined to discuss their
hobby or interest at every available opportunity. One modern way to
aid in this exchange of information is by using a mailing
list---usually an email address that redistributes all mail sent to
it back out to a list of addresses. For example, the Sun Managers
mailing list (of interest to people that administer computers
manufactured by Sun) has the address [email protected]. Any
mail sent to that address will "explode" out to each person named
in a file maintained on a computer at Northwestern University.
Administrative tasks (sometimes referred to as administrivia) are
often handled through other addresses, typically with the suffix
-request. To continue the above, a request to be added to or deleted
from the Sun Managers list should be sent to
When in doubt, try to write to the -request version of a mailing list
address first; the other people on the list aren't interested in your
desire to be added or deleted, and can certainly do nothing to
expedite your request. Often if the administrator of a list is busy
(remember, this is all peripheral to real jobs and real work), many
users find it necessary to ask again and again, often with harsher
and harsher language, to be removed from a list. This does nothing
more than waste traffic and bother everyone else receiving the
messages. If, after a reasonable amount of time, you still haven't
succeeded to be removed from a mailing list, write to the postmaster
at that site and see if they can help.
Exercise caution when replying to a message sent by a mailing list. If
you wish to respond to the author only, make sure that the only
address you're replying to is that person, and not the entire list.
Often messages of the sort "Yes, I agree with you completely!" will
appear on a list, boring the daylights out of the other readers. Likewise,
if you explicitly do want to send the message to the whole list,
you'll save yourself some time by checking to make sure it's indeed
headed to the whole list and not a single person.
A list of the currently available mailing lists is available in at
least two places; the first is in a file on ftp.nisc.sri.com called
interest-groups under the netinfo/ directory. It's updated fairly
regularly, but is large (presently around 700K), so only get it every
once in a while. The other list is maintained by Gene Spafford
([email protected]), and is posted in parts to the newsgroup
news.lists semi-regularly. (Usenet News, for info on how to read that
and other newsgroups.)
Listservs
On BITNET there's an automated system for maintaining discussion lists
called the listserv. Rather than have an already harried and
overworked human take care of additions and removals from a list, a
program performs these and other tasks by responding to a set of
user-driven commands.
Areas of interest are wide and varied---ETHICS-L deals with ethics in
computing, while ADND-L has to do with a role-playing game. A full
list of the available BITNET lists can be obtained by writing to
[email protected] with a body containing the command
list global
However, be sparing in your use of this---see if it's already on your
system somewhere. The reply is quite large.
The most fundamental command is subscribe. It will tell the
listserv to add the sender to a specific list. The usage is
subscribe foo-l Your Real Name
It will respond with a message either saying that you've been added to
the list, or that the request has been passed on to the system on
which the list is actually maintained.
The mate to subscribe is, naturally, unsubscribe. It will remove a
given address from a BITNET list. It, along with all other listserv
commands, can be abbreviated---subscribe as sub, unsubscribe as
unsub, etc. For a full list of the available listserv commands,
write to [email protected], giving it the command help.
As an aside, there have been implementations of the listserv system
for non-BITNET hosts (more specifically, Unix systems). One of the
most complete is available on cs.bu.edu in the
directory pub/listserv.
"I made this letter longer than usual because
I lack the time to make it shorter."
Pascal, Provincial Letters XVI
--------------
Anonymous FTP
FTP (File Transfer Protocol) is the primary method of transferring
files over the Internet. On many systems, it's also the name of the
program that implements the protocol. Given proper permission, it's
possible to copy a file from a computer in South Africa to one in Los
Angeles at very fast speeds (on the order of 5--10K per second).
This normally requires either a user id on both systems or a special
configuration set up by the system administrator(s).
There is a good way around this restriction---the anonymous FTP
service. It essentially will let anyone in the world have access to
a certain area of disk space in a non-threatening way. With this,
people can make files publicly available with little hassle. Some
systems have dedicated entire disks or even entire computers to
maintaining extensive archives of source code and information. They
include gatekeeper.dec.com (Digital), wuarchive.wustl.edu (Washington
University in Saint Louis), and archive.cis.ohio-state.edu (The Ohio
State University).
The process involves the "foreign" user (someone not on the system
itself) creating an FTP connection and logging into the system as the
user anonymous, with an arbitrary password:
Name (foo.site.com:you): anonymous
Password: [email protected]
Custom and netiquette dictate that people respond to the
Password: query with an email address so that the sites can
track the level of FTP usage, if they desire. (Addresses for
information on email addresses).
The speed of the transfer depends on the speed of the underlying
link. A site that has a 9600bps SLIP connection will not get the same
throughput as a system with a 56k leased line (The Physical
Connection, for more on what kinds of connections can exist in a
network). Also, the traffic of all other users on that link will
affect performance. If there are thirty people all FTPing from one
site simultaneously, the load on the system (in addition to the
network connection) will degrade the overall throughput of the
transfer.
FTP Etiquette
Lest we forget, the Internet is there for people to do work. People
using the network and the systems on it are doing so for a purpose,
whether it be research, development, whatever. Any heavy activity
takes away from the overall performance of the network as a whole.
The effects of an FTP connection on a site and its link can vary; the
general rule of thumb is that any extra traffic created detracts from
the ability of that site's users to perform their tasks. To help be
considerate of this, it's highly recommended that FTP sessions
be held only after normal business hours for that site, preferably
late at night. The possible effects of a large transfer will be less
destructive at 2 a.m. than 2 p.m. Also, remember that if it's past
dinner time in Maine, it's still early afternoon in California---think
in terms of the current time at the site that's being visited, not of
local time.
Basic Commands
While there have been many extensions to the various FTP clients out
there, there is a de facto "standard" set that everyone expects to
work. For more specific information, read the manual for your
specific FTP program. This section will only skim the bare minimum of
commands needed to operate an FTP session.
Creating the Connection
The actual command to use FTP will vary among operating systems; for
the sake of clarity, we'll use FTP here, since it's the most
general form.
There are two ways to connect to a system---using its hostname
or its Internet number. Using the hostname is usually preferred.
However, some sites aren't able to resolve hostnames properly,
and have no alternative. We'll assume you're able to use hostnames
for simplicity's sake. The form is
ftp somewhere.domain
Domains for help with reading and using domain names
(in the example below, somewhere.domain is ftp.uu.net).
You must first know the name of the system you want to connect to.
We'll use ftp.uu.net as an example. On your system, type:
ftp ftp.uu.net
(the actual syntax will vary depending on the type of system the
connection's being made from). It will pause momentarily then respond
with the message
Connected to ftp.uu.net.
and an initial prompt will appear:
220 uunet FTP server (Version 5.100 Mon Feb 11 17:13:28 EST 1991) ready.
Name (ftp.uu.net:jm):
to which you should respond with anonymous:
220 uunet FTP server (Version 5.100 Mon Feb 11 17:13:28 EST 1991) ready.
Name (ftp.uu.net:jm): anonymous
The system will then prompt you for a password; as noted previously, a
good response is your email address:
331 Guest login ok, send ident as password.
Password: [email protected]
230 Guest login ok, access restrictions apply.
ftp>
The password itself will not echo. This is to protect a user's
security when he or she is using a real account to FTP files between
machines. Once you reach the ftp> prompt, you know you're
logged in and ready to go.
Notice the ftp.uu.net:joe in the Name: prompt? That's
another clue that anonymous FTP is special: FTP expects a normal user
accounts to be used for transfers.
dir
At the ftp> prompt, you can type a number of commands to perform
various functions. One example is dir---it will list the files
in the current directory. Continuing the example from above:
ftp> dir
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 3116
drwxr-xr-x 2 7 21 512 Nov 21 1988 .forward
-rw-rw-r-- 1 7 11 0 Jun 23 1988 .hushlogin
drwxrwxr-x 2 0 21 512 Jun 4 1990 Census
drwxrwxr-x 2 0 120 512 Jan 8 09:36 ClariNet
... etc etc ...
-rw-rw-r-- 1 7 14 42390 May 20 02:24 newthisweek.Z
... etc etc ...
-rw-rw-r-- 1 7 14 2018887 May 21 01:01 uumap.tar.Z
drwxrwxr-x 2 7 6 1024 May 11 10:58 uunet-info
226 Transfer complete.
5414 bytes received in 1.1 seconds (4.9 Kbytes/s)
ftp>
The file newthisweek.Z was specifically included because we'll
be using it later. Just for general information, it happens to be a
listing of all of the files added to UUNET's archives during the past
week.
The directory shown is on a machine running the Unix operating
system---the dir command will produce different results on other
operating systems (e.g. TOPS, VMS, et al.). Learning to recognize
different formats will take some time. After a few weeks of
traversing the Internet, it proves easier to see, for example, how
large a file is on an operating system you're otherwise not acquainted
with.
With many FTP implementations, it's also possible to take the output
of dir and put it into a file on the local system with
ftp> dir n* outfilename
the contents of which can then be read outside of the live FTP
connection; this is particularly useful for systems with very long
directories (like ftp.uu.net). The above example would put the
names of every file that begins with an n into the local file
outfilename.
cd
At the beginning of an FTP session, the user is in a "top-level"
directory. Most things are in directories below it (e.g. /pub). To
change the current directory, one uses the cd command. To change to
the directory pub, for example, one would type
ftp> cd pub
which would elicit the response
250 CWD command successful.
Meaning the "Change Working Directory" command (cd) worked
properly. Moving "up" a directory is more system-specific---in Unix
use the command cd .., and in VMS, cd [-].
get and put
The actual transfer is performed with the get and put
commands. To get a file from the remote computer to the local
system, the command takes the form:
ftp> get filename
where filename is the file on the remote system. Again using
ftp.uu.net as an example, the file newthisweek.Z can be
retrieved with
ftp> get newthisweek.Z
200 PORT command successful.
150 Opening ASCII mode data connection for newthisweek.Z (42390 bytes).
226 Transfer complete.
local: newthisweek.Z remote: newthisweek.Z
42553 bytes received in 6.9 seconds (6 Kbytes/s)
ftp>
The section below on using binary mode instead of ASCII will describe
why this particular choice will result in a corrupt and subsequently
unusable file.
If, for some reason, you want to save a file under a different name
(e.g. your system can only have 14-character filenames, or can only
have one dot in the name), you can specify what the local filename
should be by providing get with an additional argument
ftp> get newthisweek.Z uunet-new
which will place the contents of the file newthisweek.Z in
uunet-new on the local system.
The transfer works the other way, too. The put command will
transfer a file from the local system to the remote system. If the
permissions are set up for an FTP session to write to a remote
directory, a file can be sent with
ftp> put filename
As with get, put will take a third argument, letting you
specify a different name for the file on the remote system.
ASCII vs Binary
In the example above, the file newthisweek.Z was transferred, but
supposedly not correctly. The reason is this: in a normal ASCII
transfer (the default), certain characters are translated between
systems, to help make text files more readable. However, when binary
files (those containing non-ASCII characters) are transferred, this
translation should not take place. One example is a binary
program---a few changed characters can render it completely useless.
To avoid this problem, it's possible to be in one of two modes---ASCII
or binary. In binary mode, the file isn't translated in any way.
What's on the remote system is precisely what's received. The
commands to go between the two modes are:
ftp> ascii
200 Type set to A. (Note the A, which signifies ASCII mode.)
ftp> binary
200 Type set to I. (Set to Image format, for pure binary transfers.)
Note that each command need only be done once to take effect; if the
user types binary, all transfers in that session are done in
binary mode (that is, unless ascii is typed later).
The transfer of newthisweek.Z will work if done as:
ftp> binary
200 Type set to I.
ftp> get newthisweek.Z
200 PORT command successful.
150 Opening BINARY mode data connection for newthisweek.Z (42390 bytes).
226 Transfer complete.
local: newthisweek.Z remote: newthisweek.Z
42390 bytes received in 7.2 seconds (5.8 Kbytes/s)
Note: The file size (42390) is different from that done
in ASCII mode (42553) bytes; and the number 42390 matches the one
in the listing of UUNET's top directory. We can be relatively sure
that we've received the file without any problems.
mget and mput
The commands mget and mput allow for multiple file
transfers using wildcards to get several files, or a whole set of
files at once, rather than having to do it manually one by one. For
example, to get all files that begin with the letter f, one
would type
ftp> mget f*
Similarly, to put all of the local files that end with .c:
ftp> mput *.c
Rather than reiterate what's been written a hundred times before,
consult a local manual for more information on wildcard matching
(every DOS manual, for example, has a section on it).
Normally, FTP assumes a user wants to be prompted for every file in a
mget or mput operation. You'll often need to get a whole set of
files and not have each of them confirmed---you know they're all
right. In that case, use the prompt command to turn the queries off.
ftp> prompt
Interactive mode off.
Likewise, to turn it back on, the prompt command should simply
be issued again.