Copy Link
Add to Bookmark
Report
Phrack Inc. Volume 02 Issue 23 File 05
==Phrack Inc.==
Volume Two, Issue 23, File 5 of 12
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
<> <>
<> Foundations Upon The Horizon <>
<> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <>
<> Chapter Two of The Future Transcendent Saga <>
<> <>
<> Using Servers And Services In The World Of Bitnet <>
<> <>
<> Presented by Knight Lightning <>
<> January 2, 1989 <>
<> <>
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Welcome to the second chapter of The Future Transcendent Saga. In this file,
I will present the servers and services of Bitnet (although there are some
services and servers on other networks as well). You will learn what the
servers are, how they differentiate, how to use them, and come to a better
understanding of how these Foundations Upon The Horizon help make Bitnet a
virtual Utopia.
_______________________________________________________________________________
What Is A Server?
~~~~~~~~~~~~~~~~~
One of most useful features of Bitnet is the variety of file servers, name
servers, relays, and so on. They might be described as "virtual machines" or
"server machines."
A "server" is a userid a lot like yours. It may exist on your computer (node)
or on some other BITNET node. The people who set up this userid have it
running a program that will respond to your commands. This is a "server." The
commands you send and the way in which the server responds to them depends on
the particular program being run. For example, the servers UMNEWS@MAINE and
107633@DOLUNI1 offer different types of services, and require different
commands. The various kinds of servers are described later in this document.
You can send your commands to most servers in one of two formats: MAIL or
MESSAGE.
Not all servers accept commands via both formats, but this information is
included in the document BITNET SERVERS which can be obtained from
LISTSERV@BITNIC. Because there are so many servers I will not even begin to
list them here. Different servers are created and disconnected everyday so it
would be difficult to name them all.
People on VM/CMS systems would send commands something like this:
TELL userid AT node command (AT = @)
For example:
TELL NETSERV@MARIST HELP
People on VAX/VMS systems using the JNET networking software would use this
syntax:
SEND userid@node "command"
For example:
SEND NETSERV@MARIST "HELP"
Many servers can also accept commands via mail. Indeed, some will only accept
your commands in that format, such as the servers on the non-Bitnet nodes. The
syntax for the commands you send remain the same. You send mail to the server
as if you were sending the mail to a person. The text of your message would be
the command. Some servers will take the command as the first line of a text
message, others require it in the "Subject:" line. Some servers will accept
more than one command in a mail message, others will take only one. Here is
an example of a mail message sent to LISTSERV@BITNIC requesting a list of
files:
Date: Fri, 30 Dec 88 23:52:00 EDT
From: Taran King <SYSOP@MSPVMA>
To: Listserv <LISTSERV@BITNIC>
========================================================================
INDEX
Throughout this file I will use examples where commands are sent to servers via
message. However, for many of the cases we will present you have option of
using mail. The choice is yours.
There are two particularly confusing aspects of servers of which you should be
aware. First, servers in the same category (say, file servers) do not always
accept the same commands. Many of them are extremely different. Others are
just different enough to be annoying. There are many approaches to setting up
a server, and everyone is trying to build a better one.
The second problem is that there are many servers that fill two, sometimes
three categories of server. For example, LISTSERV works as a list server and a
file server. Many LISTSERVs have been modified to act as name servers as well,
but they are rather inefficient in this capacity. If you do not understand
this terminology, bear with me. The best is yet to come.
File Servers
~~~~~~~~~~~~
Remember that a server runs on a userid much like yours. Like your userid, it
has many capabilities, including the ability to store files (probably with a
much greater storage capacity though). The program that a file server runs
enables it to send you files from its directory, as well as a list of files
available. These may be programs or text files. You might look at these
servers as Bitnet versions of dial-up bulletin boards or AE Lines.
You can generally send three types of commands to a file server. The first
type is a request for a list of files the server offers. The second is a
request that a specific file be sent to your userid. The third, and most
important is a HELP command.
The HELP command is very important because it is one of the few commands that
almost all servers accept, no matter what the type. Because the commands
available differ from server to server, you will often find this indispensable.
Sending HELP to a server will usually result in a message or file sent to your
userid listing the various commands and their syntax. You should keep some
of this information handy until you are comfortable with a particular server.
To request a list of files from a server, you will usually send it a command
like INDEX or DIR. The list of files will be sent to you via mail or in a
file. For example:
VM/CMS: TELL LISTSERV@BITNIC INDEX
VMS/JNET: SEND LISTSERV@BITNIC "INDEX"
To request a specific file from the list you receive, you would use a command
like GET or SENDME. For example to request the file BITNET TOPOLOGY from
LISTSERV@BITNIC you would type on of the following:
VM/CMS: TELL LISTSERV@BITNIC SENDME BITNET TOPOLOGY
VMS/JNET: SEND LISTSERV@BITNIC "SENDME BITNET TOPOLOGY"
In many cases the files are organized into subdirectories or filelists. This
can make requesting a file more complicated. This makes it even more essential
that you keep documentation about a particular server handy. Some file servers
offer programs that you can run which will send commands to the server for you.
Name Servers
~~~~~~~~~~~~
Name servers serve two purposes; to assist you in finding an address for
someone or to help you find people with specific interests. I doubt you are
going to care about tracking down people by their interests, so I am not going
to discuss those aspects of nameservers. The servers that actually let you
look up people are few and far between. Because there are so few I have
composed this list;
Columbia University FINGER @ CUVMA
Cork University INFO @ IRUCCIBM
Drew University NAMESERV @ DREW
North Dakota State University FINGER @ NDSUVM1
Ohio State University WHOIS @ OHSTVMA
Pennsylvania State University IDSERVER @ PSUVM
Rochester Institute Of Technology INFO @ RITVAXD
LOOKUP @ RITVM
State University of New York (SUNY) at Albany WHOIS @ ALBNYVM1
University of Calgary NAMESERV @ UNCAMULT
University of Kentucky WHOIS @ UKCC
University of Illinois at Urbana-Champagne PHSERVE @ UIUCVMD
University of Louisville (Kentucky) WHOIS @ ULKYVM
University of Regina VMNAMES @ UREGINA1
University of Tennessee UTSERVER @ UTKVM1
Weizmann Institute of Science VMNAMES @ WEIZMANN
So as not to be misleading, these servers do not necessarily cover the entire
school. Example: The server at University of Louisville covers people on the
node ULKYVM, but not the nodes ULKYVX0x (x = 1 - 8 I believe). ULKYVX is a
VAXcluster of nodes at University of Louisville, but the people on those
systems are NOT indexed on the server at ULKYVM. In contrast, the nameserver
at University of Illinois contains online listings for every student and staff
member whether they have accounts on the computer or not. You can get phone
numbers and addresses using this. Please note that the above list is only to
the best of my knowledge and others may exist.
There are also many Listservs that have a command to search for people, but
with Listserv, signing up is by choice and not mandatory. You also will end up
getting listings for people from nodes other than the one you are searching.
Ok, lets say I am trying to find an account for Oryan QUEST and I am told by a
friend that he is going to school at Ohio State University. Ohio State
University has a nameserver and if he has an account on their computer I should
be able to find him.
VM/CMS: TELL WHOIS@OHSTVMA Quest
VMS/JNET: SEND WHOIS@OHSTVMA "Quest"
This particular nameserver only requires that you enter the persons name with
no "search" command. Some servers require this. Your best bet is to send the
command "HELP" first and you'll receive documentation.
Ok, back to the example... unfortunately, there is no entry for "Quest" and I
am out of luck. I should have been smart enough to realize that no college
would be likely to let Oryan QUEST enroll in the first place -- my mistake.
In any case, I highly recommend that you register yourself with UMNEWS@MAINE
and BITSERVE@CUNYVM. These are popular nationwide servers that are often used
to locate people.
Forums, Digests, and Electronic Magazines
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The concept of mailing lists has been given new life with the creation of
computer networks. Let me explain what I mean. Almost everyone is on some
sort of mailing list; magazines, bills or even pamphlets from your congressman..
The computer networks have brought a whole new degree of speed and
functionality to mailing lists, as you will see.
In Bitnet, mailing lists are used mainly to keep people with similar interests
in contact. There are several formats in which this contact can take place.
These are "forums," "digests," and "electronic magazines".
FORUMS are a good example of how the utility of mailing lists has been expanded
in Bitnet. Let's say that you have subscribed to a forum for people interested
in Cyberpunks. How you could subscribe to such a list will be described later.
Another person on the mailing list sends mail to a server where the list is
kept. This server forwards the mail to all of the people in the forum. When
mail from a forum arrives in your computer mailbox, the header will look much
like this:
Date: Fri, 10 Sep 88 23:52:00 EDT
Reply-To: CYBER Discussion List <CYBER-L@PUNKVM>
Sender: CYBER Discussion List <CYBER-L@PUNKVM>
From: Sir Francis Drake <DRAKE@WORMVM>
Subject: Invasion From X-Neon!
To: Solid State <SEKER@PLPVMA>
========================================================================
This may look a little confusing, but there really isn't much to it. In this
example, Sir Francis Drake ("From:") sent mail to the CYBER-L list address.
This server then forwarded the mail to everybody on the list, including Solid
State ("To:"). Note the line named "Reply-To:". This line tells your mail
software that when you reply to the note (if you reply) that the reply should
go to the list... meaning *everybody* on the list. People will in turn reply
to your mail, and you have a forum.
Some forums are very interesting, but using the digests can lead to problems.
First among these is the volume of mail you can receive. If you are in a very
active forum, you can get 50 or more pieces of electronic mail in a single day.
If you are discussing a controversial or emotional topic, expect more.
Many people have a tendency to "flame" (the Bitnet term for ragging). The
speed and immediacy of electronic mail makes it very easy to whip out a quick,
emotional response, to which there will be similar replies. I advise you to
take some time and think out your responses to forum postings before
inadvertently starting a "flame war." Hopefully anyone able to gain access to
college computers will be mature enough to have outgrown these battles.
DIGESTS provide a partial solution to the these problems. In this case, mail
that is sent to a mailing list is stored rather than sent out immediately. At
some point the "Moderator" for the list organizes and condenses all of the
correspondence for the day or week. He then sends this out to the people on
the mailing list in one mailing.
The drawback with this setup is that it requires a lot of human intervention.
If the moderator gets sick, goes on vacation, or quits, activity for a
particular digest can come to a screeching halt.
ELECTRONIC MAGAZINES take the digest concept a step further. These mailing
lists actually duplicate the organization and format of "real" magazines.
Bitnet is used as a convenient and inexpensive distribution method for the
information they contain. The frequency of distribution for these electronic
magazines ranges ranges from weekly to quarterly to "whenever the editor feels
like it" (sort of like Phrack releases). This is the most formal, structured
form of Bitnet communication. Where a digest is simply a group of letters
organized by topic, an electronic magazine includes articles, columns, and
features. Perhaps the only feature of paper magazines that they do *not*
include is advertisements. Bitnet NetMonth and NetWeek are two of the better
magazines on Bitnet and they contain useful information if you know what you're
looking for. I will discuss how to subscribe to these magazines as well as the
other forms of media in the next part of this file.
List Servers
~~~~~~~~~~~~
In the previous section, I mentioned that some servers are used to control
mailing lists. A server that performs this function is called a "list server."
Almost all of these listservers have the userid of LISTSERV, such as
LISTSERV@BITNIC. One of these servers can control subscriptions to many
mailing lists. The other concept behind Listservs are the list-ids, but as
these are rather unimportant and vary from server to server I am not going to
discuss them here. If you would like to learn about these, consult your local
listserv and request documentation with the HELP command.
To subscribe to a mailing list, you would send a LISTSERV a SUBSCRIBE command,
which has the following syntax:
SUBscribe listname (whatever name you want)
In this example, SpyroGrya is sending LISTSERV@BITNIC the command to
subscribe to ETHICS-L:
VM/CMS: TELL LISTSERV@BITNIC SUB ETHICS-L SpyroGyra
VMS/JNET: SEND LISTSERV@BITNIC "SUB ETHICS-L SpyroGyra"
If you misspell your name when entering a SUBscribe command, simply resend it
with the correct spelling. To delete his name from the mailing list,
SpyroGyra would enter an UNSUBscribe command:
VM/CMS: TELL LISTSERV@BITNIC UNSUB ETHICS-L
VMS/JNET: SEND LISTSERV@BITNIC "UNSUB ETHICS-L"
In many cases the SIGNOFF command is used instead of UNSUB, but those are the
basic commands you need to know in order to access Listserv controlled mailing
lists. However, Listserv has a multitude of features, so it would be a good
idea to read the Listserv documentation.
*Note* If you are on a VAXcluster, you should send SUBSCRIBE and UNSUBSCRIBE
commands to LISTSERV via MAIL.
Relays
~~~~~~
Relay might be one of the easier types of servers to understand. If you have
used the CB Simulator on CompuServe or are familiar with Diversi-Dials (or
maybe even ALTOS Chat) you will catch on to the concept quickly. The idea
behind Relay is to allow more than two people to have conversations by
interactive message. Without Relay-type servers, this would not be possible.
Let's set up a scenario:
Sluggo, Taran, and Mentor are at different nodes. Any two of them can have
a conversation through Bitnet. If the three of them want to talk, however,
they have a problem. Sluggo can send Mentor messages, but Taran can't see
them. Likewise, Taran can send Sluggo messages, but then Mentor is in the
dark. What they need is a form of teleconferencing. Alliance doesn't exist on
Bitnet so they created Relays.
Each of these users "signs on" to a nearby Relay. They can pick a channel
(0-999 although there are more, but they are reserved for special use).
Instead of sending messages to Taran or Sluggo, Mentor sends his commands to
the Relay. The Relay system then sends his message to *both* Taran and Sluggo.
The other users can do the same. When they are done talking, they "sign off."
Relays can distinguish commands from the text of your messages because commands
are prefixed with a slash "/". For example, a HELP command would look like
this:
VM/CMS: TELL RELAY@UIUCVMD /HELP
VMS/JNET: SEND RELAY@UIUCVMD "/HELP"
A message that is part of a conversation would be sent like so:
VM/CMS: TELL RELAY@UIUCVMD Hello there!
VMS/JNET: SEND RELAY@UIUCVMD "Hello there!"
When you first start using Relay, you must register yourself as a Relay user
using the /SIGNUP or /REGISTER commands:
VM/CMS: TELL RELAY@UIUCVMD /REGISTER (Choose a name)
VMS/JNET: SEND RELAY@UIUCVMD "/REGISTER (Choose a name)"
They want you to use your real name, do so if you want, but they really have no
way to check unless one of the operators is a user consultant at your node and
looks up your account. Just use names that look real and you'll be fine.
You can then sign on. You can use a nickname or handle. In the following
example, I am signing on to Channel 260 with a nickname of "KLightning":
VM/CMS: TELL RELAY@UIUCVMD /SIGNON KLightning 260
VMS/JNET: SEND RELAY@UIUCVMD "/SIGNON KLightning 260"
You can then start sending the Relay the text of your messages:
VM/CMS: TELL RELAY@UIUCVMD Good evening.
VMS/JNET: SEND RELAY@UIUCVMD "Good evening."
Relay messages will appear on your screen like this. Note the nickname near
the beginning of the message. When you send conversational messages to the
Relay, it automatically prefixes them with your nickname when it forwards it to
the other users:
FROM UIUCVMD(RELAY): <Taran_King> Hello KLightning.
You can find out who is on your channel with a /WHO command. In the following
example, someone is listing the users on Channel 260.
VM/CMS: TELL RELAY@UIUCVMD /WHO 260
VMS/JNET: SEND RELAY@UIUCVMD "/WHO 260"
The response from the Relay would look like this:
FROM UIUCVMD(RELAY): Ch UserID @ Node Nickname
FROM UIUCVMD(RELAY): 260 C483307@UMCVMB (KLightning)
FROM UIUCVMD(RELAY): 260 MENTOR@PHOENIX (The_Mentor)
FROM UIUCVMD(RELAY): 260 C488869@UMCVMB (Taran_King)
FROM UIUCVMD(RELAY): 260 PROPHET@PHOENIX ( Prophet )
FROM UIUCVMD(RELAY): 260 DRAKE@WORMVM ( Sfd )
FROM UIUCVMD(RELAY): 260 JESTER@NDSUVM1 ( Sluggo )
FROM UIUCVMD(RELAY): 260 TUC@RACS3VM ( Tuc )
FROM UIUCVMD(RELAY): 260 VINNY@LODHVMA (Lex_Luthor)
When you are done with your conversation, you can sign off the Relay:
VM/CMS: TELL RELAY@UIUCVMD /SIGNOFF or /BYE
VMS/JNET: SEND RELAY@UIUCVMD "/SIGNOFF" or "/BYE"
There are several commands for listing active channels, sending private
messages, and so on. When you first register as a Relay user, you will be sent
documentation. You can also get this information with the /INFO command. To
determine which Relay serves your area, send any of the Relays listed in
BITNET SERVERS the /SERVERS command. Also, because of Bitnet message and file
traffic limits, many Relays are only available during the evening and weekends.
To help illustrate how the Relays work I have included this map;
[United States of America locations only]
----------------------
Non-USA Relays | RELAY @ CLVM |
^ | (TwiliteZne) |
/|\ | Potsdam N.Y. |
| ----------------------
| |
---------------------- ---------------------- ----------------------
| RELAY @ VILLVM | | RELAY @ ORION | | RELAY @ YALEVM |
| (Philadelph) |-----| (New_Jersey) |-----| (Yale) |
| Villanova PA. | | New Jersey | | New Haven CT. |
---------------------- ----------------------\ ----------------------
| | \
---------------------- | \ \ ----------------------
| RELAY @NDSUVM1 | | \ \ | RELAY @NYUCCVM |
| (No_Dakota ) |\ | \ \| ( Nyu ) |
| North Dakota | \ | \ | New York |
---------------------- \ | \ ----------------------
\ | \
---------------------- \---------------------- | ----------------------
| RELAY @JPNSUT10 | | RELAY @ BITNIC | | | CXBOB @ASUACAD |
| ( Tokyo ) |-----| ( NewYork ) | | | (Tempe_Ariz) |
| Japan | | New York-Singapore | | | Arizona |
---------------------- ---------------------- | ----------------------
| | |
---------------------- \ | ----------------------
| MASRELAY@ UBVM | \ | | RELAY @ USCVM |
| ( Buffalo ) |\ --+--| (LosAngeles) |
| New York (N) | \ / | California |
---------------------- \ / ----------------------
\ / |
---------------------- \ / ----------------------
| RELAY @ WATDCS | \ / | RELAY @ UWAVM |
| ( Waterloo ) | \ / | ( Seattle ) |
| Ontario/E. Canada | | / | Washington |
---------------------- | / ----------------------
| | | |
---------------------- ---------------------- ----------------------
| RELAY @CANADA01 | | RLY @CORNELLC | | 556 @OREGON1 |
| ( Canada01 ) |-----| (Ithaca_NY ) | | ( Oregon ) |
| Ontario (Guelph) | | New York | | Oregon |
---------------------- ----------------------\ ----------------------
| | \
---------------------- | \ ----------------------
| RELAY @UREGINA1 | | \ | RELAY @ VTVM2 |
| ( Regina_Sk ) | | \| ( Va_Tech ) |
| Saskatoon/Manitoba | | | Virginia |
---------------------- | ----------------------
| | |
---------------------- | ----------------------
| RELAY @UALTAVM | | | RELAY @ UWF |
| ( Edmonton ) | | | (Pensacola ) |
| Alberta/B.C. | | | Florida |
---------------------- | ----------------------
|
---------------------- ---------------------- ----------------------
| RELAY @PURCCVM | | RELAY @CMUCCVMA | | RELAY @ UTCVM |
| ( Purdue ) |-----| (Pittsburgh) |-----| (Tennessee ) |
| Lafayette IN. | | Pennsylvania | | Tennessee |
---------------------- ---------------------- ----------------------
| |
---------------------- | ----------------------
| RELAY @TECMTYVM | | | RELAY @ GITVM1 |
| (Monterrey ) | | | ( Atlanta ) |
| Mexico | | | Georgia |
---------------------- | ----------------------
| |
---------------------- ---------------------- ----------------------
| RELAY @ TAMVM1 | | RELAY @UIUCVMD | | RELAY @ TCSVM |
| (Aggieland ) |-----| (Urbana_IL ) |-----| ( Tulane ) |
| Texas | | Illinois | | New Orleans LA. |
---------------------- ---------------------- ----------------------
Conclusion
~~~~~~~~~~
So what lies beyond the boundaries of Bitnet? There are many other networks
that are similar to Bitnet both in function and in services. How to mail to
these networks will be discussed in the next chapter of The Future Transcendent
Saga -- Limbo To Infinity.
:Knight Lightning
_______________________________________________________________________________
