📄 rfc122.txt
字号:
Network Working Group James E. WhiteRequest for Comments: 122 UC Santa BarbaraNIC 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........................... 16J. 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........................... 19J. White [Page 2]RFC 122 Simple-Minded file System April 1971I. 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 notas 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 SetsJ. 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 + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -