rfc122.txt
来自「RFC 的详细文档!」· 文本 代码 · 共 1,180 行 · 第 1/4 页
TXT
1,180 行
Network Working Group James E. White
Request for Comments: 122 UC Santa Barbara
NIC 5834 26 April 1971
NETWORK SPECIFICATIONS FOR UCSB's
SIMPLE-MINDED FILE SYSTEM
CONTENTS
Page
I. Preface........................................ 3
II. Implementation................................. 3
III. Login.......................................... 3
IV. Service Offered................................ 4
V. Primitive File Operations...................... 6
V.A. Allocate File (ALF)...................... 6
V.B. Update File (UDF)........................ 7
V.C. Replace File (RDF)....................... 8
V.D. Retrieve File (RTF)...................... 9
V.E. Space File (SPF)......................... 9
V.F. Delete File (DLF)........................ 10
V.G. Rename File (RNF)........................ 10
V.H. File No Operation (FNO).................. 10
V.I. No Operation (NOP)....................... 11
VI. Input Stream Format............................ 11
VII. Output Stream Format........................... 16
J. White [Page 1]
RFC 122 Simple-Minded file System April 1971
FIGURES
Page
Figure 1. Filename/Password Character Sets........... 5
Figure 2. Command Op Codes........................... 12
Figure 3. Defined Command Fields..................... 13
Figure 4. Definition of Command FLAGS Bits........... 14
Figure 5. Defined Command Response Fields............ 18
Figure 6. Completion Codes........................... 19
J. White [Page 2]
RFC 122 Simple-Minded file System April 1971
I. Preface
UCSB will provide file storage for Network users. UCSB's Simple
Minded File System (SMFS) is addressed as socket number X'401', site
3. No accounting parameters are required. This document is intended
to provide programmers with the information necessary to communicate
with SMFS which conducts all Network transactions trough its NCP
which operates under the Host-Host protocol of August 3, 1970.*
II. Implementation
The following information is not essential to use of SMFS but may be
of interest. SMFS will store user's files on IBM 2316 disk packs,
each with 29M 8-bit bytes of storage capacity. UCSB has two 2314
units, each with eight drives on-line. Initially, one drive will be
allocated for Network storage, and the appropriate pack will always
be mounted an that drive, and hence accessible to SMFS without
operator intervention. UCSB estimates that for the next year it will
have up to four drives that it can devote to Network use. The
second, third, and fourth drives will be allocated only as the need
arises. SMFS is written to accommodate any number of on-line drives
without modification.
If necessary, UCSB will investigate the possibility of making one of
the four drives a come-and-go drive on which one of a number of packs
can be mounted as required. Hence, the potential exists for
increased storage capacity with an accompanying increase in access
time.
Files stored with SMFS will be backed up to tape daily. The back-up
tape(s) will be off-line and available only in case the on-line
copies are destroyed.
In no sense does USB expect to become _the_ file storage node of the
Network; it hasn't the capacity. UCSB _is_ equipped, however, to
make a limited amount of secondary storage immediately available to
the Network community.
III. Login
SMFS can simultaneously service any number of Network users up to
some assembly-parameters maximum (currently ten). A potential user
must establish a pair of Network connections
*At the time of this writing, the NCP modifications of RFC #107 have not
as yet been implemented at UCSB.
J. White [Page 3]
RFC 122 Simple-Minded file System April 1971
(i.e., one full-duplex connection) to SMFS by executing a standard
ICP to socket X'401', site 3. SMFS always listens on that socket.
It will accept any call it receives -- say from the user's receive
socket 'm' -- and over the connection thus established transmit a
32-bit receive socket number (call it 'n'), and then close the
connection. SMFS will then issue two connection requests -- one
involving its receive socket 'n' and the user's send socket 'm+l', in
other involving its send socket 'n+l' and the user's receive socket
'm'. Once these two connections have been established, the user will
be considered logged in. A deviation from the Initial Connection
Protocol will occur only if SMFS or its NCP has insufficient
resources to support another connection.
SMFS will maintain its connections to the user indefinitely. It will
voluntarily terminate its connections to the user only if (1) a bad
op code is encountered in a user command (see Section VI), or (2)
closing one of the connections is required to signal end-of-data (see
Section V.D.). Barring such an occurrence, the user should close his
connections to SMFS when through, at which time SMFS will consider
the user logged out.
In the discussion to follow, the following terms are used. The
connections on which the user transmits data to and receives data
from SMFS are designated the input and output connections,
respectively (i.e., SMFS's rather than the user's point of view is
adopted). The string of bits which passes from the user to SMFS over
the input connection during the life of that connection is called the
_input stream_; the string of bits which passes from SMFS to the user
over the output connection during the life of that connection is
called the _output stream_.
IV. Service Offered
SMFS will provide storage for sequential, binary files of length
greater than or equal to an assembly-parameter minimum (currently one
bit) and less than or equal to an assembly-parameter maximum
(currently 25 million bits). There is no restriction on the contents
of the file.
Every file stored with SMFS has a _filename_, which may be any string
of from one to 36, 8-bit characters chosen from the set:
{ A,...,Z,0,...9,blank }
J. White [Page 4]
RFC 122 Simple-Minded file System April 1971
Graphic EBCDIC Code (Hex) ASCII Code (Hex)
UC LC UC LC UC LC
A a C1 81 41 61
B b C2 82 42 62
C c C3 83 43 63
D d C4 84 44 64
E e C5 85 45 65
F f C6 86 46 66
G g C7 87 47 67
H h C8 88 48 68
I i C9 89 49 69
J j D1 91 4A 6A
K k D2 92 4B 6B
L l D3 93 4C 6C
M m D4 94 4D 6D
N n D5 95 4E 6E
O o D6 96 4F 6F
P p D7 97 50 70
Q q D8 98 51 71
R r D9 99 52 72
S s E2 A2 53 73
T t E3 A3 54 74
U u E4 A4 55 75
V v E5 A5 56 76
W w E6 A6 57 77
X x E7 A7 58 78
Y y E8 A8 59 79
Z z E9 A9 5A 7A
0 - F0 - 30 -
1 - F1 - 31 -
2 - F2 - 32 -
3 - F3 - 33 -
4 - F4 - 34 -
5 - F5 - 35 -
6 - F6 - 36 -
7 - F7 - 37 -
8 - F8 - 38 -
9 - F9 - 39 -
blank - 40 - 20 -
Figure 1
Filename/Password Character Sets
J. White [Page 5]
RFC 122 Simple-Minded file System April 1971
Filenames may be specified by the user in either EBCDIC or ASCII (see
Figure 1), and the characters A,...,Z may be either upper- or lower-
case. However, the acceptance by SMFS of both upper- and lower-case,
and both EBCDIC and ASCII, is provided only as a convenience to the
user. In particular, such distinctions don't increase the number of
unique filenames that can be generated; the filenames 'FILE NUMBER 1'
and 'file number 1', in EBCDIC or ASCII, designate the same file.
Every file stored with SMFS may optionally be protected against
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?