| 楼主 |
2004-10-30 13:05:00 |
积分：0分
|
有人要我在发 联系我qq54484047
Network Working Group A. McKenzie
RFC # 601 BBN-NET
NIC # 20905 14 December 1973
Updates: RFC # 586
Traffic Statistics (November 1973)
Attached are the Host traffic statistics for the month of November 1973.
AAM/jm
Attach.
McKenzie [Page 1]
RFC 601 Traffic Statistics (November 1973) December 1973
HOST THROUGHPUT SUMMARY
(PACKETS OUTPUT)
NOVEMBER 1973
INTER- INTRA- AVG. DAILY
NODE NODE TOTAL INTERNODE DAYS
UCLA HOST 0 241273 30480 271753
UCLA HOST 1 1536918 56526 1593444
UCLA HOST 2 26253 4954 31207
-------- -------- --------
1804444 91960 1896404 60148 30
SRI HOST 0 6519907 208536 6728443
SRI HOST 1 574488 162319 736807
-------- -------- --------
7094395 370855 7465250 236480 30
UCSB HOST 0 2549879 76826 2626705
UCSB HOST 1 313615 2751 316366
-------- -------- --------
2863494 79577 2943071 95450 30
UTAH HOST 0 1304159 203988 1508147
UTAH HOST 2 87741 187693 275434
-------- -------- --------
1391900 391681 1783581 46397 30
BBN HOST 0 10 26935 26945
BBN HOST 1 5933376 336528 6269904
BBN HOST 2 52098 55531 107629
BBN HOST 3 247706 17072 264778
-------- -------- --------
6233190 436066 6669256 207773 30
M-MAC HOST 0 405008 78836 483844
M-MAC HOST 1 1139680 248773 1388453
M-MAC HOST 2 1071807 755648 1827455
M-MAC HOST 3 855130 755184 1610314
-------- -------- --------
3471625 1838441 5310066 115721 30
RAND HOST 0 1626780 36341 1663121 54226 30
SDC HAD NO TRAFFIC 30
McKenzie [Page 2]
RFC 601 Traffic Statistics (November 1973) December 1973
HARV HOST O 1363275 1084755 2448030
HARV HOST 1 969135 1294673 2263808
-------- -------- --------
2332410 2379428 4711838 77747 30
LINC HOST 0 28913 15009 43922
LINC HOST 1 45842 19861 65703
LINC HOST 2 4772 19698 24470
-------- -------- --------
79527 54568 134095 2651 30
STAN HOST 0 1812959 6692 1819651 60432 30
ILL HOST 0 1944572 240 1944812
ILL HOST 1 34288 257 34545
ILL HOST 2 163 5 168
-------- -------- --------
1979023 502 1979525 65967 30
CASE HOST 0 2569407 36272 2605679 85647 30
CARN HOST 0 979677 451688 1431365
CARN HOST 1 592226 494991 1087217
-------- -------- --------
1571903 946679 2518582 52397 30
AMES HOST 0 3550158 27201 3577359 118339 30
AMEST HOST 0 129967 19797 149764
AMEST HOST 2 5340672 37480 5378152
-------- -------- --------
5470639 57277 5527916 182355 30
MITRE HOST 2 2939264 218 29394282 97975 30
ROME HOST 2 1248304 196 1248500 41610 30
NBS HOST 2 2343085 27095 2370180 78103 30
ETAC HOST 0 1150626 10 1150636 38354 30
LLL HOST 0 163639 319 163958 5455 |
 回复
|
|
| 1楼 |
2004-10-30 12:45:00 |
|
积分：0分
|
Network Working Group Jon Postel
RFC # 604 MITRE
NIC # 21186 26 December 1973
Assigned Link Numbers
This announcement modifies the official host-to-host protocol, and
updates the defining documents [NIC 8246, NIC 9347]. Please note that
the information on page 28 of "Host/Host Protocol for the ARPA Network"
about link number assignments is updated by this note, and that a
previous update [RFC 317, NIC 9347] is completely replaced. The
modification is minor and should have no effect on existing network
programs or usage. Four of the reserved link numbers are hereby
assigned for experimental use in the testing of an internetworking
protocol defined by Kahn and Cerf.
Description:
Control Link
Link 0 is assigned for use as the host-to-host protocol control
link.
Data Links
Links 2-71 are available for use in connections as provided by
the host-to-host protocol.
Internetworking Protocol
Links 155-158 are to be used for experiments with the
Internetworking Protocol.
Measurements
Links 159-191 are assigned for use in measurements under the
direction of the Network Measurement Center at UCLA.
Message Switching
Links 192-195 are to be used for experiments with the Message
Switching Protocol.
Private Experiments
Links 196-255 are available for private experimental use.
Postel [Page 1]
RFC 604 Assigned Link Numbers December 1973
Reserved
Link 1, and links 72-154 are reserved for future developments
and experiments and currently are not to be used.
Table:
Link Number Assignment
0 Control Link
1 Reserved
2-71 Connections
72-154 Reserved
155-158 Internetworking Protocol
159-191 Measurements
192-195 Message Switching Protocol
196-255 Experimental
References:
Host-to-host Protocol NIC 8246
Internetworking Protocol NIC 18764
Message Switching Protocol NIC 9926
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alex McKenzie with ]
[ support from GTE, formerly BBN Corp. 10/99 ]
Postel [Page 2]
|
| 回复
|
|
| 2楼 |
2004-10-30 12:45:00 |
|
积分：0分
|
Network Working Group J.D. Burchfiel
RFC # 603 BBN-TENEX
NIC # 21022 31 December, 1973
Response to RFC # 597: Host Status
I have several questions about the November 1973 ARPANET
topographical map:
1. AMES is 4-connected, i.e. four network connections will go down
if the IMP fails. Is there some aspiration that IMPs should be
no more than three connected?
2. The seven IMPS in the Washington area are arranged into a loop.
This guarantees that local communication can take place even if
one connection fails, and is probably a worthwhile preparation
for area routing. On the other hand, for example, a break
between MIT-IPC and MIT-MAC will require them to communicate
through a 12-hop path through Washington. This can be remedied
by a short (inexpensive) connection between Harvard and Lincoln
Labs. Is there a plan to pull the Boston area, the San
Francisco area, and the Los Angeles area into loops like the
Washington area?
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alex McKenzie with ]
[ support from GTE, formerly BBN Corp. 10/99 ]
Burchfiel [Page 1]
|
| 回复
|
|
| 3楼 |
2004-10-30 12:45:00 |
|
积分：0分
|
Arpa Network Working Group Bob Metcalfe (PARC-MAXC)
Request for Comments: 602 Dec 1973
NIC #21021
"The Stockings Were Hung by the Chimney with Care"
The ARPA Computer Network is susceptible to security violations for at least
the three following reasons:
(1) Individual sites, used to physical limitations on machine access, have
not yet taken sufficient precautions toward securing their systems
against unauthorized remote use. For example, many people still use
passwords which are easy to guess: their fist names, their initials,
their host name spelled backwards, a string of characters which are
easy to type in sequence (e.g. ZXCVBNM).
(2) The TIP allows access to the ARPANET to a much wider audience than
is thought or intended. TIP phone numbers are posted, like those
scribbled hastily on the walls of phone booths and men's rooms. The
TIP required no user identification before giving service. Thus,
many people, including those who used to spend their time ripping off
Ma Bell, get access to our stockings in a most anonymous way.
(3) There is lingering affection for the challenge of breaking
someone's system. This affection lingers despite the fact that
everyone knows that it's easy to break systems, even easier to
crash them.
All of this would be quite humorous and cause for raucous eye
winking and elbow nudging, if it weren't for the fact that in
recent weeks at least two major serving hosts were crashed
under suspicious circumstances by people who knew what they
were risking; on yet a third system, the system wheel password
was compromised -- by two high school students in Los Angeles
no less.
We suspect that the number of dangerous security violations is
larger than any of us know is growing. You are advised
not to sit "in hope that Saint Nicholas would soon be there".
RMV:rmv
|
| 回复
|
|
| 4楼 |
2004-10-30 12:45:00 |
|
积分：0分
|
30
ISI HOST 1 11056000 145966 11201970 368533 30
McKenzie [Page 3]
RFC 601 Traffic Statistics (November 1973) December 1973
USC HOST 0 165622 2291501 2457123
USC HOST 2 4178240 2168615 6346855
-------- -------- --------
4343862 4460116 8803978 144795 30
GWC HOST 2 3671911 56 3671967 122397 30
DOCB HOST 2 127876 2706 130582 4263 30
SDAC HOST 0 35717 0 35717
SDAC HOST 2 807398 36 807434
-------- -------- --------
843115 36 843151 28104 30
BELV HOST 0 4895 126 5021
BELV HOST 1 1162 51 1213
-------- -------- --------
6057 177 6234 202 30
ARPA HOST 0 29820 387317 417137
ARPA HOST 2 1976769 382267 2359036
-------- -------- --------
2006589 769584 2776173 66886 30
ABER HAD NO TRAFFIC 30
BBN T HOST 2 2240310 674 2240975 74677 30
CCA HOST 0 781493 834094 1615587
CCA HOST 2 2956749 451325 3408074
-------- -------- --------
3738242 1285419 5023661 124608 30
XEROX HOST 0 2056013 415370 2471383
XEROX HOST 1 0 9736768 9736768
-------- -------- --------
2056013 10152140 12208150 68534 30
FNWC HOST 0 33 986 1019
FNWC HOST 2 63856 35 63891
-------- -------- --------
63889 1021 64910 2130 30
LBL HAD NO TRAFFIC 30
UCSD HOST 0 653614 46348 699962 21787 30
McKenzie [Page 4]
RFC 601 Traffic Statistics (November 1973) December 1973
HAW T HOST 0 1 1398 1399
HAW T HOST 2 768335 109011 877346
HAW T HOST 3 6686 12 6698
-------- -------- --------
775022 110421 885443 25834 30
RML HOST 2 532132 173 532305 17738 30
NCC-T HOST 0 126 12559 12685
NCC-T HOST 2 540407 18493 558900
NCC-T HOST 3 16999 54771 71770
-------- -------- --------
557532 85823 643355 46461 12
NORSR HOST 2 146110 20 146130 4870 30
ULOND HOST 0 36630 25629 62259
ULOND HOST 2 527040 69483 596523
-------- -------- --------
563670 95112 658782 18789 30
TYMSH HOST 0 1484 23245 24729
TYMSH HOST 2 49015 18 49033
-------- -------- --------
50499 23263 73762 1683 30
M-IPC HOST 0 145 11083 11228 5 30
MOFF HAD NO TRAFFIC 30
RUTGS HOST 2 99059 117 99176 6191 16
WRPAT HOST 2 85688 41 85729 2856 30
----------------------------------------
TOTAL 85314100 23971670
DAILY AVERAGE 2843803 799056
AVERAGE PER 64730 18188
NODE-DAY
PACKETS/MESSAGES (INTERNODE) 1.08
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alex McKenzie with ]
[ support from GTE, formerly BBN Corp. 1/2000 ]
McKenzie |
| 回复
|
|
| 5楼 |
2004-10-30 12:46:00 |
|
积分：0分
|
Upcoming Move of NIC/NLS Services
RFC # 609 Bill Ferguson
NIC # 21339 SRI-ARC
Jan. 10, 1974
Statement of Upcoming Move of NIC/NLS Services
Within the next few weeks we will be transferring computer services for
our ROME, ARPA, and NIC users from the ARC/NIC system to a new system we
are installing at TYMSHARE in Cupertino, Ca. The name of this system is
OFFICE-1 and is site 53 (oct) when talking to TELNET or site 43 (dec)
when talking to a TIP. Currently we are experiencing hardware
difficulties on this system, but we and the staff at TYMSHARE are
working diligently to solve the problems. Once the hardware is solid and
reliable, the above users will have their directories transferred to the
OFFICE-1 facility, and receive their NLS power from that site. Watch for
upcoming announcements as to the exact date when your directory will be
moved to OFFICE-1.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alex McKenzie with ]
[ support from GTE, formerly BBN Corp. 10/99 ]
|
| 回复
|
|
| 6楼 |
2004-10-30 12:46:00 |
|
积分：0分
|
Network Working Group M.D. Kudlick
RFC # 608 SRI-ARC
NIC # 21256 January 10, 1974
HOST NAMES ON-LINE
We at the NIC agree with Peter Deutsch's suggestion (in RFC# 606 / NIC#
21246) that the NIC maintain an online ASCII text file of Host names,
addresses, and attributes. That suggestion corresponds to one made by
Vint Cerf recently, and evidently receives ARPA/IPT support.
Jake Feinler at the NIC designed and maintains a source file, in NLS
format, that can be used to generate the ASCII file Peter outlined. A
program to generate an up to date version of the ASCII file needs to be
written at the NIC, and run periodically (weekly, or as the situation
warrants). Such a mechanism would allow us, of course, to maintain one
source of data and use it for this and other purposes.
Our present data includes official Host name, Host address, Host status
(user, server, TIP) and certain other information like Technical
Liaison, Host computer, operating system, etc.
Provisions exist for including attributes of the type Peter suggested
(for example FTP byte size, TELNET duplex mode, echoing mode, and
nicknames), but these data are currently NOT in our source file.
To get things moving, therefore, we propose to do the following things:
1) We shall write a program to generate the ASCII file in the
syntax described in RFC# 606, namely:
<host-name-file> ::= <entry> / <host-name-file> <entry>
<entry> ::= <data-part> <end-of-line>
Note that this produces a blank line after the <data-part>.
<data-part> ::= <basic-part> / <data-part> <attribute-item>
<basic-part> ::= <host-name> , <host-address> <end-of-line>
<attribute-item> ::= <attribute-name> = <attribute-value> <end-
of-line>
Kudlick [Page 1]
RFC 608 Host Names On-Line January 1974
2) We shall initially include only the following items in each
<entry>:
a) <basic-part>
in which <host-address> will be a decimal host address,
relative to the Host's own Network, and
in which <host-name> will be the official Host Name, a
string obtained through negotiation between the Host and the
NIC, governed by these constraints:
up to 48 characters drawn from the alphabet (A-Z),
digits (0-9), and the minus sign (-) ... specifically,
no blank or space characters allowed;
no distinction between upper and lower case letters;
the first character is a letter;
the last character is NOT a minus sign;
no other restrictions on content or syntax.
Note: The Host Name may be prefixed with an Official
Network Name of up to 24 characters enclosed in parentheses
(). The Network Name designates the Network in which the
Host resides.
(The characters used in the Network Name are drawn from
the same character set as those in the Host Name, with
the same constraints [except the length] as listed
above.)
The ASCII text file will only contain the Official
Network name for Hosts NOT on the ARPANET; for ARPANET
Hosts there will be no Network Name prefix.
b) <attribute-item>
in which <attribute-name> initially will have the single
possible value STATUS, and the corresponding value of
<attribute-value> for STATUS will be one of these:
SERVER
USER
TIP
UNKNOWN
Kudlick [Page 2]
RFC 608 Host Names On-Line January 1974
c) <end-of-line>
this will be carriage return followed by line feed (octal
015 followed by octal 12).
3) Attributes other than those for which <attribute-name> is STATUS
will be added in the above format at a later date (to be
announced) as the data becomes available to us.
We agree with Peter that the attribute list should not be
construed as replacing option negotiation or any other means by
which one Host discovers the properties of another, but merely
as an alternative source of information that is simply and
easily accessible, in machine-readable form.
Suggestions for attributes that are worthy of inclusion in the
ASCII file of Hostnames are welcome. Please send your
suggestions and/or data to Jake Feinler
FEINLER @ SRI-ARC, or NIC Ident = JAKE
For completeness, we record here the attribute suggestions given
in RFC# 606:
NICKNAMES -- value is a list of acceptable nicknames for the
host. Any system that provides name-to-address translation
is encouraged (although of course not required) to accept
these names as alternatives to the official host name.
FTP-BYTE-SIZES -- value is a list of the byte sizes
supported by the FTP server. The first byte size is the one
which leads to the least computational overhead (e.g. 36 for
PDP-10's, 32 for 360's).
ECHOING -- value is L or R depending on whether the host
expects the terminal to echo (Remote) or expects to do its
own echoing (Local).
The ASCII file generated by the NIC will reside at Host OFFICE-1 (Host
Address = 43 decimal), and will have the pathname
<NETINFO>HOSTS.TXT
Using this pathname with an FTP process will enable anyone, of course,
to retrieve the file for use at any Network Host.
The login username for FTP can be GUEST,
password ARPA,
account 1.
Kudlick [Page 3]
RFC 608 Host Names On-Line January 1974
The file will be in alphanumeric sequence by Host Name.
The date after which the file will be available at OFFICE-l will be
announced via RFC as soon as the file is ready.
We welcome comments on this RFC, on RFC# 606, or on any other aspect of
this problem. And we wish to acknowledge the contributions of Vint
Cerf, Peter Deutsch, Jake Feinler, and Nancy Neigus in getting the
Official Host Name list to happen.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alex McKenzie with ]
[ support from GTE, formerly BBN Corp. 11/99 ]
Kudlick [Page 4]
|
| 回复
|
|
| 7楼 |
2004-10-30 12:46:00 |
|
积分：0分
|
end-of-record markers
(EOR) are explicit, including the final one." This prohibits sending data
between the final end of record and the end of file, but does not specify
what the receiver of data is to do if this rule is broken. That is, should
the intervening data be discarded or treated as a new (final) record?
SOLUTION: specify that if an end-of-file marker is not immediately preceded
by an end-of-record marker, the intervening data is to be discarded.
A major complaint about the protocol concerns the fact that the writer of
an FTP user process must handle a considerable number of special cases
merely to determine whether or not the last command sent was successful. It
is admitted that the protocol is well-defined in all the following areas,
but it is important to realize that the characteristic "well-defined" is
necessary, but not sufficient; for many reasons, it is very desirable to
employ the simplest mechanism that satisfies all the needs. Following is a
list of those drawbacks that unduly complicate the flow chart of an FTP
user process:
9. Different commands have different success reply codes. A successful
"USER" command, for example, returns a "230" whereas a successful "BYTE"
command returns a "200". The concept that success replies should have an
even first digit and failure replies an odd first digit does not apply, as
"100, means success for "STAT", and "402" means failure for "BYTE".
SOLUTION: specify that any command must return a reply code beginning with
some unique digit, such as "2", if successful, and anything other than that
digit if not successful.
10. Some commands have multiple possible success reply codes, e.g., "USER",
"REIN", and "BYE". It is undesirable for an FTP user to be required to keep
a list of reply codes for each command, all of which mean "command
accepted, continue". SOLUTION: same as for (9.) above. The desire to
communicate more specific information than simply "yes" or "no", such as
the difficulty in the login procedure that some sites do not need all the
parameters, may be solved by having, for example, "238" mean "PASSWORD
ACCEPTED, YOU ARE NOW LOGGED IN", and "237" mean "PASSWORD ACCEPTED,
ACCOUNT NOW NEEDED" The important point is that the idea of "command
accepted" is conveyed by the initial "2", and that finer gradations of
meaning can be deduced by the user process, if desired.
-2-
11. There are several types of replies that are extraneous from the point
of view of a user FTP process, and their reply codes have no characteristic
that makes them easily distinguishable. For example, "010 message from
operator" and "050 FTP commentary" are superfluous to a user process, and
"000 announcing FTP" (in place of "300" greeting) is not. SOLUTION: specify
that any reply that has meaning only to a human user and not to a user
process must have a reply code beginning with a unique digit, such as "0".
The continuation line reply code proposed in (8.) above falls into this
category, and therefore must start with the same unique digit.
12. The notion of a server sending a "000 announcing FTP" or a "020
expected delay" immediately after completion of the ICP if input cannot be
accepted right away is another instance of multiple reply codes having the
same meaning to a user process. SOLUTION: require that the server send a
reply with a "020" reply code in the situation cited. If it is desired to
communicate more detailed information, the text of the reply may used for
this purpose.
In addition to the above mentioned weaknesses in the protocol, the
following is believed to be a typographical error:
13. Reply code "331" is cited as a possible success reply code for the
commands "BYTE", "SOCK", "PASV", "TYPE", "STRU", "MODE", "ALLO", "REST",
"SITE", AND "STAT". This reply code means "ENTER ACCOUNT" (if required as
part of login sequence), and perhaps should be "332 LOGIN FIRST, PLEASE".
This is especially indicated by the fact that "332" is not listed anywhere
in the command-reply correspondence table.
-3- |
| 回复
|
|
| 8楼 |
2004-10-30 12:46:00 |
|
积分：0分
|
Request for Comments: 607 Mark Krilanovich
NIC # 21255 George Gregg
references: RFC #542 UCSB Jan 1974
Comments on the File Transfer Protocol
There are several aspects of the File Transfer Protocol that constitute
serious drawbacks. Some of these are quite basic in nature, and imply
substantial design changes; these will be discussed in a later RFC.
Others could be remedied with very little effort, and this should be done
as soon as possible.
Following is a list of those problems that can be easily solved, together
with their proposed solutions:
1. Once a server has been told to be "passive" with regard to establishment
of data connections, there is no way for the user to make him "active"
again. SOLUTION: define a new command, with a command verb of "ACTV", to
mean that the server is to issue a CONNECT rather than a LISTEN on the data
socket. If the server is already "active", the command is a no op. "ACTV"
is to have the same reply codes as "PASV".
2. Design of an FTP server would be simpler if all command verbs were the
same length, and design of an FTP user would be simpler if either all
command verbs were the same length, or if multiple blanks were allowed
following the verb. SOLUTION: replace the only three-letter verb, "BYE",
with a four-letter one, such as "QUIT", and constrain future command verbs
to be four letters long.
3. The order of the handshaking elements following a file transfer command
is left unspecified. After sending a STOR command, for example, a user
process has no way of knowing which to wait for first, the "250 FILE
TRANSFER STARTED" reply, or establishment of the data connection. SOLUTION:
specify that the server is to send a "250" reply before attempting to
establish the data connection. If it is desired to check if the user is
logged in, if the file exists, or if the user is to be allowed access to
the file, these checks must be made before any reply is sent. The text of
the "250" reply would perhaps be more appropriate as "250 OPENING DATA
CONNECTION", since it comes before actual data transfer begins. If the
server wishes to send an error reply in the event that the data connection
cannot be opened, it is to be sent in lieu of the "252 TRANSFER COMPLETE"
reply.
4. Some hosts currently send an error reply on receipt of a command
that is unimplemented because it is not needed (e.g., "ACCT" or "ALLO").
Even though the text of the reply indicates that the command has been
ignored, it is obviously impossible for a user process to know that there
is no real "error". SOLUTION: require that any server that does not support
a particular command because it is not needed in that system must return a
success reply.
5. There is no specified maximum length of a TELNET line, user name,
password, account, or pathname. It is true that every system implementing
an FTP server likely has different maxima for its own parameters, but it is
nearly impossible for the writer of an FTP user (which must converse with
many FTP servers) to construct an indefinite length buffer. Typically some
-1-
arbitrary maximum must be chosen. SOLUTION: specify a maximum length for
TELNET lines, user names, passwords, account numbers, and pathnames. This
is to be done after conducting a poll of serving sites concerning their
individual maxima.
6. The notion of allowing continuation lines to start with arbitrary text
solves a minor problem for a few server FTP implementers at the expense of
creating a major problem for all user FTP implementers. The logic needed to
decode a multi-line reply is unnecessarily complex, and made an order of
magnitude more so by the fact that multi-line replies are allowed to be
nested. SOLUTION: assign a unique (numeric) reply code, such as "009", to
be used on all lines of a multi-line reply after the first.
7. Given that multi-line replies are allowed to be nested, the fact that
the maximum allowed level of nesting is left unspecified creates a hardship
for implementers of user FTPs. This hardship is somewhat easily solved on a
machine that has hardware stacks, but not so for other machines. SOLUTION:
specify a maximum level of nesting of multi-line replies.
8. In blocked mode, the protocol states that "all |
| 回复
|
|
| 9楼 |
2004-10-30 12:46:00 |
|
积分：0分
|
Netork Working Group L. Peter Deutsch
Request For Comments: 606 PARC-MAXC
December 1973
Host Names On-line
Now that we finally have an official list of host names, it seems
about time to put an end to the absurd situation where each site
on the network must maintain a different, generally out-of-date,
host list for the use of its own operating system or user
programs.
For example, each of the TENEX sites to which I have access
( SRI-ARC, BBN-TENEX, USC-ISI, and PARC-MAXC) has a slightly
different mapping between host names and host addresses: none
is complete, and I believe each one differs in some way from
the official List.
Since the NIC has responsibility for maintaining the official
list, lt seems appropriate for them to maintain an on-line file,
accessible to anyone, which Lists names and host addresses ( and
certain other information which I will suggest in a moment) in an
easily machine-readable form.
This rules out, in my opinion, providing this information only
in the form of an NLS structured file, since there are no
facilities for accessing such files from the network and since
many sites would not want to accommodate themselves to this
structure even if there were.
The file I have in mind would be devoted principally to that
information needed by programs, as opposed to people, since the ;
former want their information in compact, easily parsed form,
whereas the latter appreciate more verbose expression and more
sophisticated facilities for browsing or querying. Therefore, I
propose that the following information be included in such a file:
Of course, the official name and host address for each host.
This would be the primary content of each entry.
Some information about the options of the various protocols
supported by the host, including ( for FTP ) the preferred byte
size and ( for TELNET) the preferred duplex mode. The former
can have an enormous effect on the efficiency of file
transfers. Since the new TELNET allows negotiation of options,
the list need not be complete or accurate.
The function o f the host vis-a-vis the network ( user, server,
TIP, etc.). This may aid NCPs in deciding whether to poll the
host or give useful information for statistical purposes ( e.g.
I would like to make my NCP collect statistics on traffic with
TIPs vs. other hosts).
Since the file will be generated centrally by a single program,
but used widely by a variety of programs, it follows that its
format should be organized for ease of interrogation at the
expense of ease of construction. I feel a reasonable way to
achieve this is to store it as an ASCII text file with the logical
structure of a "property list".
-1-
In other words, aside from the two basic facts in each entry
( name and address), the information will be expressed in the
form of <attribute, value> pairs rather than having the
attribute be recognized by format, position, etc.
l don't believe it matters a great deal exactly how this file is
formatted, so I will make a suggestion in the hope that no one
cares enough to protest it. ( This has never worked before in the
history of the network, but it' s still worth a try ) The
following is the proposed syntax of the file.
<host-name-file> ::= <entry> | <host-name-file> <entry>
<entry> ::= <data-part> <end-of-line>
Note that this produces a blank line after the <data-part>.
<data-part> ::= <basic-part> | <data-part> <attribute-item>
<basic-part> ::= <host-name> , <host-address> <end-of-line>
<attribute-item> ::= <attribute-name> = <attribute-value>
<end-of-line>
This leaves the following terms undefined:
<end-of-line>: I don't know what end-of-line indication is in
favor in the network community these days. I personally favor
carriage-return followed by line-feed. TENEX tends to use the
single character octal 37, which is totally non-standard and
inappropriate for this application.
<host-name>: an official host name as specified in the recent
RFC 597 (NIC 20826) by NJN and JAKE. It is my understanding
that these names are restricted to letters, digits, hyphens,
and parentheses ( including the network name).
<host-address>: a decimal host address, relative to its own
network ( I would assume). There has been no general discussion
of multi-network addressing -- although there is apparently an
unpublicized Internetworking Protocol experiment in progress --
and some other convention may be more desirable.
<attribute-name>: an arbitrary name containing only letters,
digits, and hyphens. We will have to agree on some names like
BEST-FTP-BYTE-SIZE (?), but I am willing to let the NIC pick
them.
<attribute-value>: an arbitrary string not containing
<end--of-line>, whose interpretation depends in general on the
attribute. For example, there might be an attribute SERVERS
whose value was a list of the servers customarily run by the
site.
The following are some specific attributes that I think would be
worthwhile:
NICKNAMES -- value is a list of acceptable nicknames for the
host. Any system that provides name-to-address translation is
encouraged ( although of course not required) to accept these
names as alternatives to the official host name.
-2-
FTP-BYTE-SIZES -- value is a list of the byte sizes supported
by the FTP server. The first byte size is the one which leads
to the least computational overhead ( e.g. 36 for PDP-1O's, 32
for 36O's).
ECHOING -- value is L or R depending on whether the host
expects the terminal to echo ( Remote) or expects to do its own
echoing (Local).
Note that no attribute is actually required and that the values
under a given attribute need not be complete. In other words,
this list is meant not to replace option negotiation,
word-of-mouth, or any other means bo which one host discovers
the properties of another, but merely to provide an alternate
source of information which can be accessed in a simple and
uniform way.
I realize that there is a time-honored pitfall associated with
suggestions such as the present one: it represents a specific
solution to a specific problem, and as such may not be compatible
with or form a reasonable basis for more general solutions to more
general problems. However, ( 1) this particular problem has been
irking me and others I have spoken to for well over a year, and it
is really absurd that it should have gone unsolved this Long; (2)
no one seems particularly interested in solving any more general
problem.
Except the Datacomputer: PLEASE, if there is an easy way to
accomplish the same function through the Datacomputer, someone
write un RFC specifying it.
-3- |
| 回复
|
|
| 10楼 |
2004-10-30 12:47:00 |
|
积分：0分
|
conventional systems). As a result, there is considerable incentive to
consider solutions involving cooperating processes on specialized
systems.
To summarize: the datacomputer must be prepared to function as a
component of small networks of specialized processes, in order that it
can be used effectively in a network in which there are many specialized
nodes.
2.3.3 Common Network Data Handling
A large network can support enough data management hardware to construct
more than one datacomputer. While this hardware can be combined into
one even larger datacomputer, there are advantages to configuring it as
two (or possibly more) systems. Each system should be large enough to
obtain economies of scale in data storage and to support the data
management software. Important data bases can be duplicated, with a
copy at each datacomputer; if one datacomputer fails, or is cut off by
Winter, Hill & Greiff [Page 8]
RFC 610 Further Datalanguage Design Concepts December 1973
network failure, the data is still available. Even if duplicating the
file is not warranted, the description can be kept at the different
datacomputers so that applications which need to store data constantly
can be guaranteed that at least one datacomputer is available to receive
input.
These kinds of failure protection involve cooperation between a pair of
datacomputers; in some sense, they require that the two datacomputers
function as a single system. Given a system of datacomputers (which one
can think of as a small network of datacomputers), it is obviously
possible to experiment with providing additional services on the
datacomputer-network level. For example, all requests could be
addressed simply to the datacomputer-network; the datacomputer-network
could then determine where each referenced file was stored (i.e., which
datacomputer), and how best to satisfy the request.
Here, two kinds of cooperation in the network environment have been
mentioned: cooperation among processes to solve a given problem, and
cooperation among datacomputers to provide global optimizations in the
network-level data handling problem. These are only two examples,
especially interesting because they can be implemented in the near term.
In the network, much more general kinds of cooperation are possible, if
a little farther in the future. For example, eventually, one might want
the datacomputer(s) to be part of a network-wide data management system,
in which data, directories, services, and hardware were generally
distributed about the network. The entire system could function as a
whole under the right circumstances. Most requests would use the data
and services of only a few nodes. Within this network-wide system,
there would be more than one data management system, but all systems
would be interfaced through a common language. Because the
datacomputers represent the largest data management resource in the
network, they would certainly play an important role in any network-wide
system. The language of the datacomputer (datalanguage) is certainly a
convenient choice for the common language of such a system.
Thus a final, albeit futuristic, requirement imposed by the network on
the design of the datacomputer system, is that it be a suitable major
component for network-wide data management systems. If feasible, one
would like datalanguage to be a suitable candidate for the common
language of a network-wide group of cooperating data management systems.
2.4 Different Modes of Datacomputer Usage
Within this network environment, the datacomputer will play several
roles. In this section four such roles are described. Each of them
imposes constraints on the design of datalanguage. We can analyze them
in terms of four overlapping advantages which the datacomputer provides:
Winter, Hill & Greiff [Page 9]
RFC 610 Further Datalanguage Design Concepts December 1973
1. Generalized data management services
2. Large file handling
3. Shared access
4. Economic volume storage
Of course, the primary reason for using the datacomputer will be the
data management services which it provides. However, for some
applications size will be the dominating factor in that the datacomputer
will provide for online access to files which are so large that
previously only offline storage and processing were possible. The
ability to share data between different network sites with widely
different hardware is another feature provided only by the datacomputer.
Economies of scale make the datacomputer a viable substitute for tapes
in such applications as operating system backup.
Naturally, a combination of the above factors will be at work in most
datacomputer applications. The following subsections describe some
possible modes of interaction with the datacomputer.
2.4.1 Support of Large Shared Databases
This is the most significant application of the datacomputer, in nearly
every sense.
Projects are already underway which will put databases of over one
hundred billion bits online on the Arpanet datacomputer. Among these
are a database which will ultimately include 10 years of weather
observations from 5000 weather stations located all over the world. As
online databases, these are unprecedented in size. They will be of
international interest and be shared by users operating on a wide
variety of hardware and in a wide variety of languages.
Because these databases are online in an international network, and
because they are expected to be of considerable interest to researchers
in the related fields, it seems obvious that there will be extremely
broad patterns of use. A strong requirement, then, is a flexible and
general approach to handling them. This requirement of providing
different users of a database with different views of the data is an
overriding concern of the datalanguage design effort. It is discussed
separately in Section 2.5.
2.4.2 Extensions of Local Data management Systems
We imagine local data handling systems (data management systems,
applications-oriented packages, text-handling systems, etc.) wanting to
take advantage of the datacomputer. They may do so because of the
Winter, Hill & Greiff [Page 10]
RFC 610 Further Datalanguage Design Concepts December 1973
economics of storage, because of the data management services, or
because they want to take advantage of data already stored at the
datacomputer. In any case, such systems have some |
| 回复
|
|
| 11楼 |
2004-10-30 12:47:00 |
|
积分：0分
|
the opposite end, developing the
primitives from which to construct the language. Section 4 presents our
work in this area: a model datacomputer which will ultimately provide a
precise semantic definition of datalanguage. Section 4 explains that
part of the model which is complete, and relates this to our other work.
Section 5 discusses work that remains, both on the model and in our
top-down analysis.
Winter, Hill & Greiff [Page 5]
RFC 610 Further Datalanguage Design Concepts December 1973
2. Considerations for Language Design
2.1 Introduction
Data management is the task of managing data as a resource, independent
of hardware and applications programs. It can be divided it into five
major sub-tasks:
(1) _creating_ databases in storage,
(2) making the data _available_ (e.g., satisfying queries),
(3) _maintaining_ the data as information is added, deleted and
modified,
(4) assuring the _integrity_ of the data (e.g., through backup and
recovery systems, through internal consistency checks),
(5) _regulating_access_, to protect the databases, the system, and
the privacy of users.
These are the major data-related functions of the datacomputer; while
the system will ultimately provide other services (such as accounting
for use, monitoring performance) these are really auxiliary and common
to all service facilities.
This section presents global considerations for the design of
datalanguage, based on our observations about the problem and the
environment in which it is to be solved. The central problem is data
management, and the datacomputer shares the same goals as many currently
available data management systems. Several aspects of the datacomputer
create a unique set of problems to be solved.
2.2 Hardware Considerations
2.2.1 Separate Box
The datacomputer is a complete data management utility in a separate,
closed box. That is, the hardware, the data and the data management
software are segregated from any general-purpose processing facilities.
There is a separate installation dedicated to data management.
Datalanguage is the only means users have for communicating with the
datacomputer and the sole activity of the datacomputer is to process
datalanguage requests.
Dedicating hardware provides an obvious advantage: one can specialize it
for data management. The processor(s) can be modified to have data
management "instructions"; common low-level software functions can be
built into the hardware.
Winter, Hill & Greiff [Page 6]
RFC 610 Further Datalanguage Design Concepts December 1973
A less obvious, but possibly more significant, advantage is gained from
the separateness itself. The system can be more easily protected. A
fully-developed datacomputer on which there is only maintenance activity
can provide a very carefully controlled environment. First, it can be
made as physically secure as required. Second, it needs to execute only
system software developed at CCA; all user programs are in a high-level
language (datalanguage) which is effectively interpreted by the system.
Hence, only datacomputer system software processes the data, and the
system is not very vulnerable to capture by a hostile program. Thus,
since there is the potential to develop data privacy and integrity
services that are not available on general-purpose systems, one can
expect less difficulty in developing privacy controls (including
physical ones) for the datacomputer than for the systems it serves.
2.2.2 Mass Storage Hardware
The datacomputer will store most of its data on mass storage devices,
which have distinctive access characteristics. Two examples of such
hardware are Precision Instruments' Unicon 690 and Ampex Corporation's
TBM system. They are quite different from disks, and differ
significantly from one another.
However, almost all users will be ignorant of the characteristics of
these devices; many will not even know that the data they use is at the
datacomputer. Finally, as the development of the system progresses,
data may be invisibly shunted from one datacomputer to another, and as a
result be stored in a physical format quite different from that
originally used.
In such an environment, it is clear that requests for data should be
stated in logical, not physical terms.
2.3 Network Environment
The network environment provides additional requirements for
datacomputer design.
2.3.1 Remote Use
Since the datacomputer is to be accessed remotely, the requirement for
effective data selection techniques and good mechanisms for the
expression of selection criteria is amplified. This is because of the
narrow path through which network users communicate with the
datacomputer. Presently, a typical process-to-process transfer rate
over the Arpanet is 30 kilobits per second. While this can be increased
through optimization of software and protocols, and through additional
Winter, Hill & Greiff [Page 7]
RFC 610 Further Datalanguage Design Concepts December 1973
expenditure for hardware and communications lines, it seems safe to
assume that it will not soon approach local transfer rates (measured in
the megabits per second).
A typical request calls for either transfer of part of a file to a
remote site, or for selective update to a file already stored at the
datacomputer. In both of these situations, good mechanisms for
specifying the parts of the data to be transmitted or changed will
reduce the amount of data ordinarily transferred. This is extremely
important because with the low per bit cost of storing data at the
datacomputer, transmission costs will be a significant part of the total
cost of datacomputer usage.
2.3.2 Interprocess Use of the Datacomputer System
Effective use of the network requires that groups of processes, remote
from one another, be capable of cooperating to accomplish a given task
or provide a given service. For example, to solve a given problem which
involves array manipulation, data retrieval, interaction with a user at
a terminal, and the generalized services of a language like PL/I, it may
be most economical to have four cooperating processes. One of these
could execute at the ILLIAC IV, one at the datacomputer, one at MULTICS,
and one at a TIP. While there is overhead in setting up these four
processes and in having them communicate, each is doing its job on a
system specialized for that job. In many cases, the result of using the
specialized system is a gain of several orders of magnitude in economy
or efficiency (for example, online storage at the datacomputer has a
capital cost two orders of magnitude lower than online costs on
|
| 回复
|
|
| 12楼 |
2004-10-30 12:47:00 |
|
积分：0分
|
Network Working Group Richard Winter, Jeffrey Hill, Warren Greiff
RFC # 610 CCA
NIC # 21352 December 15, 1973
Further Datalanguage Design Concepts
Richard Winter
Jeffrey Hill
Warren Greiff
Computer Corporation of America
December 15, 1973
Winter, Hill & Greiff [Page 1]
RFC 610 Further Datalanguage Design Concepts December 1973
Acknowledgment
During the course of the Datacomputer Project, many people have
contributed to the development of datalanguage.
The suggestions and criticisms of Dr. Gordon Everest (University of
Minnesota), Dr. Robert Taylor (University of Massachusetts), Professor
Thomas Cheatham (Harvard University) and Professor George Mealy (Harvard
University) have been particularly useful.
Within CCA, several people in addition to the authors have participated
in the language design at various stages of the project. Hal Murray,
Bill Bush, David Shipman and Dale Stern have been especially helpful.
Winter, Hill & Greiff [Page 2]
RFC 610 Further Datalanguage Design Concepts December 1973
1. Introduction
1.1 The Datacomputer System
The datacomputer is a large-scale data utility system, offering data
storage and data management services to other computers.
The datacomputer differs from traditional data management systems in
several ways.
First, it is implemented on dedicated hardware, and comprises a separate
computing system specialized for data management.
Second, the system is implemented on a large scale. Data is intended to
be stored on mass storage devices, with capacities in the range of a
trillion bits. Files on the order of one hundred billion bits are to be
kept online.
Third, it is intended to support sharing of data among processes
operating in diverse environments. That is, the programs which share a
given data base may be written in different languages, execute on
different hardware under different operating systems, and support end
users with radically different requirements. To enable such shared use
of a data base, transformations between various hardware representations
and data structuring concepts must be achieved.
Finally, the datacomputer is designed to function smoothly as a
component of a much larger system: a computer network. In a computer
network, the datacomputer is a node specialized for data management, and
acting as a data utility for the other nodes. The Arpanet, for which
the datacomputer is being developed, is an international network which
has over 60 nodes. Of these, some are presently specialized for
terminal handling, others are specialized for computation (e.g., the
ILLIAC IV), some are general purpose service nodes (e.g., MULTICS) and
one (CCA) is specialized for data management.
1.2 Datalanguage
Datalanguage is the language in which all requests to the datacomputer
are stated. It includes facilities for data description and creation,
for retrieval of or changes to stored data, and for access to a variety
of auxiliary facilities and services. In datalanguage it is possible to
specify any operation the datacomputer is capable of performing.
Datalanguage is the only language accepted by the datacomputer and is
the exclusive means of access to data and services.
Winter, Hill & Greiff [Page 3]
RFC 610 Further Datalanguage Design Concepts December 1973
1.3 Present Design Effort
We are now engaged in developing complete specifications for
datalanguage; this is the second iteration in the language design
process.
A smaller, initial design effort developed some concepts and principles
which are described in the third working paper in this series. These
have been used as the basis of software implementations resulting in an
initial network service capability. A user manual for this system was
published as working paper number 7.
As a result of experience gained in implementation and service, through
further study of user requirements and work with potential users, and
through investigation of other work in the data management field, quite
a few ideas have been developed for the improvement of datalanguage.
These are being assimilated into the language design in the iteration
now in progress.
When the language design is complete, it will be incorporated into the
existing software (requiring changes to the language compiler, but
having little impact on the rest of the system).
Datacomputer users will first have access to the new language during
1975.
1.4 Purpose of this Paper
This paper presents concepts and preliminary results, rather than a
completed design. There are two reasons for publishing now.
The first is to provide information to those planning to use the
datacomputer. They may benefit from knowledge of our intentions for
development.
The second is to enable system and language designers to comment on our
work before the design is frozen.
1.5 Organization of the Paper
The remainder of the paper is divided into four sections.
Section 2 discusses the most global considerations for language design.
This comprises our view of the problem; it has influenced our work to
date and will determine most of our actions in completion of the design.
This section provides background for section 3, and reviews some
Winter, Hill & Greiff [Page 4]
RFC 610 Further Datalanguage Design Concepts December 1973
material that will be familiar to those who have been following our work
closely.
Section 3 discusses some of the specific issues we have worked on. The
emphasis is on solutions and options for solution.
In sections 2 and 3 we are presenting our "top-down" work: this is the
thinking we have done based on known requirements and our conception of
the desirable properties of datalanguage.
We have also been working from |
| 回复
|
|
| 13楼 |
2004-10-30 12:48:00 |
|
积分：0分
|
struct
is 'male' then the number of pregnancies component must be 0.
Data validation is only half of the data integrity picture. Data
integrity involves methods of restoring damaged data. This requires
maintenance of redundant information. Features will be provided which
will make the datacomputer system responsible for the maintenance of
redundant data and possibly even automatic restoration of damaged data.
In section 2 we discussed possible uses of the datacomputer for file
backup. All features which are provided for this purpose will also be
available as methods of maintaining backup information for restoration
of files residing at the datacomputer.
3.6 Privacy
Datalanguage will have to provide extensive privacy and protection
capabilities. In its simplest form a privacy lock is provided at the
file level. The lock is opened with a password key. Associated with
this key is a set of privileges (reading, updating, etc.). Two degrees
of generality are sought. Privacy should be available at all levels of
data. Therefore, groups of related data, including groups of files
could be made private by creating private directories. Also, specific
fields of records could be made private by having private components of
a struct where other components of the struct are visible to a wider (or
different) class of users. We would also like the user to be able to
define his own mechanism. In this way, very personalized, complex, and
hence secure mechanisms can be defined. Also features such as 'everyone
can see his own salary' might be possible.
Winter, Hill & Greiff [Page 27]
RFC 610 Further Datalanguage Design Concepts December 1973
3.7 Conversion
Many types of data are related in that some or all of the possible
values of one type of data have an "obvious" translation to the values
of another. For example, the character '6' has a natural translation to
the integer 6, or the six character string 'abc ' (three trailing
blanks) has a natural translation to the four character string 'abc '
(one trailing blank). Datalanguage will provide conversion capabilities
for the standard, commonly called for, translations. These conversions
can be explicitly invoked by the user or implicitly invoked when data of
one type is needed for an operation but data of another type is
provided. In the case of implicit invocation of conversion of data the
user will have control over whether conversion takes place for a given
data item. More generally we would like to provide a facility whereby
the user could specify conditions which determine when an item is to be
converted. Also, the user should be able to define his own conversion
operations, either for a conversion between types which is not provided
by the datacomputer system or to override the standard conversion
operation for some or all items of a given type.
3.8 Virtual and Derived Data
Often, information important to users of data is embedded in that data
rather than explicitly maintained. For example, the dollar value of an
individual's interest in a company in a file of stock holders. Since
the value of the company changes frequently, it is not feasible to
maintain this information with each record. It is useful to be able to
use the file as if information of this type was part of each record.
When referencing the dollar value field of a record, the datacomputer
system would automatically use information in the record, such as
percentage of ownership in the company, possibly in conjunction with
information which is not part of the record but is maintained elsewhere,
such as company assets, to compute the dollar value. In this way the
data user need not be concerned with the fact that this information is
not actually maintained in the record.
The _set_, which is a specific type of virtual container in
datalanguage, deserves special mention. A set is a virtual list. For
example, suppose there is a real list of people representing some
population sample. By real (or actual) data we mean data which is
physically stored at the datacomputer. A set could be defined to
contain all members of this list who are automobile owners. The set
concept provides a powerful feature for viewing data as belonging to
more than one collection without physical duplication. Sets are also
useful, in that, they can be dynamically formed. Given an actual list,
sets based on that list can be created without having been previously
described.
Winter, Hill & Greiff [Page 28]
RFC 610 Further Datalanguage Design Concepts December 1973
As mentioned above | |
