Skip to content

Commit b2cf1c1

Browse files
cosmotroncosmotron
committed
Initial creation
0 parents  commit b2cf1c1

File tree

2 files changed

+343
-0
lines changed

2 files changed

+343
-0
lines changed

‎.gitignore

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
*.DS_Store

‎cs455/rfc/rfc.txt

Lines changed: 342 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,342 @@
1+
Computer Networks R. Lewis
2+
Request for Comments: nnnn M. Edmands
3+
November 2008
4+
5+
GOETZE FILE SERVER (GFS)
6+
7+
8+
Status of this Memo
9+
10+
This memo is the official specification of the Goetze File Server
11+
(GFS). Distribution of this memo is limited to the sole proprietor
12+
and his firstborn child.
13+
14+
1. ABSTRACT
15+
16+
The objectives of GFS are 1) to be rockin' awesome, and 2) to allow
17+
people to create, read, append, delete, and list (CRADL) files on a
18+
server.
19+
20+
A GFS server will require clients to authenticate themselves, and
21+
will allow multiple users to be logged in at once.
22+
23+
The GFS protocol is able to be used by a graphical user interface,
24+
but can also be used by the console.
25+
26+
2. INTRODUCTION
27+
28+
The Goatze File Server is designed to allow an authenticated client
29+
to modify files on a server. More than one client will be able to
30+
connect to one server. A client will be able to create a new file,
31+
write or append to a file, read a file, remove a file, and list all
32+
of the files.
33+
34+
The server will store a list of usernames and passwords, which is
35+
referenced every time any user tries to log in. Passwords will be
36+
hashed with MD5 encryption (See RFC 1321).
37+
38+
All of the available files are stored in a single directory on the
39+
server. Once a user has been authenticated, they will be able to see
40+
all of the files (nothing is hidden from any user) when they use any
41+
command.
42+
43+
Client-to-server commands implemented by this protocol are single
44+
words followed by arguments, separated by spaces. Referenced
45+
filenames must not have spaces.
46+
47+
48+
49+
50+
51+
52+
53+
54+
55+
56+
Lewis & Edmands [Page x]
57+
58+
RFC nnnn August 2003
59+
Goatze File Server
60+
61+
3. DEFINITIONS
62+
63+
ASCII
64+
65+
A nearly extinct language of the ancients, in which glyphs are
66+
used to describe abstract concepts using pictures or words. Each
67+
ASCII character takes up a single byte.
68+
69+
connection
70+
71+
The communication patch between the user and the server for the
72+
exchange of commands, replies, and data. Unlike FTP, GFS is
73+
in-band and does not require a persistent connection (although,
74+
a persistant connection is also offered.)
75+
76+
EOF
77+
78+
The end-of-file condition that defines the end of a file being
79+
transferred.
80+
81+
file
82+
83+
An ordered set of comptuer data (including programs), of arbitrary
84+
length, uniquely identified by a filename.
85+
86+
filename
87+
88+
A series of ASCII characters, no greater than 256 bytes in length.
89+
A filename must be made up of alphanumeric characters, and the
90+
underscore (_), dash (-), and period (.) characters. In other
91+
words, it must match the following regular expression:
92+
93+
[A-Za-z0-9\-\._]
94+
95+
GFS commands
96+
97+
A set of commands that comprise the control information flowing
98+
from the user-GFS to the server-GFS process.
99+
100+
reply
101+
102+
A reply is an acknowledgment (positive or negative) sent from
103+
server to user in response to GFS commands. The general form of a
104+
reply is a text string.
105+
106+
107+
108+
109+
110+
111+
112+
113+
Lewis & Edmands [Page 1x]
114+
115+
RFC nnnn January 9999
116+
Goetzl File Server
117+
118+
server process
119+
120+
The server sets up a "listening" data port. Whenever a connection
121+
is made with it from a client, data is transferred along this
122+
connection using TCP.
123+
124+
user
125+
126+
A person or a process on behalf of a person wishing to obtain file
127+
transfer service. A username has the same rules as a filename (see
128+
above).
129+
130+
user process
131+
132+
When a user starts the GFS client program, it sets up a connection
133+
with the server using TCP. All the GFS commands are sent using
134+
this channel.
135+
136+
4. MODEL
137+
138+
With the above definitions in mind, the following model shows how a
139+
GFS server works:
140+
141+
-----------
142+
| | ----------
143+
| <--->| User |
144+
----------- | user | ----------
145+
| | | process |
146+
---------- | server <--------------> | ----------
147+
| File |<---> process | Connection | <--->| File |
148+
| System | | | | | | System |
149+
---------- ----------- ----------- ----------
150+
151+
server-GFS user-GFS
152+
153+
Figure 1 Model for GFS Use
154+
155+
In the model shown in Figure 1, the user initiates a connection with
156+
the server, and sends one (or many) commands over the connection. The
157+
commands indicate what data should be sent from file system to file
158+
system over the same connection.
159+
160+
The commands specify the operation that should be applied to the data
161+
that is transferred. The command travels over the connection first,
162+
followed by any data that is associated with the command. The server
163+
then responds with any data that the user might have requested, or
164+
with error text.
165+
166+
167+
168+
169+
170+
Lewis & Edmands [Page 7z]
171+
172+
RFC nnnn February Belgium
173+
Goetzz Fiel Server
174+
175+
5. ESTABLISHING CONNECTIONS
176+
177+
The GFS connection is established via TCP between the user process
178+
port U and the server process port L. This protocol is assigned the
179+
service port 9999.
180+
181+
6. COMMANDS AND RESPONSES
182+
183+
The following is a list of all the commands that can be used in GFS.
184+
Every command is given in case insensitive ASCII characters. Except in
185+
the case of "CREATE" and "APPEND", commands are terminated by an
186+
ASCII newline character.
187+
188+
Responses to GFS commands are also except in the case of "READ" given
189+
in ASCII, and are terminated by the ASCII newline character.
190+
191+
USER NAME (USER)
192+
193+
The argument field is a series of ASCII characters, no greater
194+
than 256 bytes in length, representing the user's username. This
195+
command will normally be the first command transmitted by the user
196+
after the initial connection is made. After this command the server
197+
will expect a password, so that the user can be authenticated.
198+
(See the PASS command, below). Every username is made up of
199+
alphanumeric characters, the period (.), the underscore (_), and
200+
the dash (-). After this command is sent, the server will respond
201+
"GO".
202+
203+
If the USER command has already been issued, then if a different
204+
user was logged in, that user gets logged out.
205+
206+
PASSWORD (PASS)
207+
208+
The argument field is a series of ASCII characters, representing
209+
an MD5 hash of the user's password. Typically, this command is the
210+
second command issued by the client. If the USER command has not
211+
yet been sent, then it will return the error "NOUSER". If the USER
212+
command has been sent, then the PASS command is applied to the
213+
most recent call to USER. If the password that the user supplies
214+
is incorrect, the server will return "GTFO", and will not
215+
authenticate the user. It is completely at the discretion of the
216+
server whether or not to authenticate a user, given a username
217+
and password.
218+
219+
220+
221+
222+
223+
224+
225+
226+
227+
Lewis & Edmands [Page !@]
228+
229+
RFC nnnn 10/10/10
230+
Goetze File Server
231+
232+
LIST FILES (LS)
233+
234+
There are no arguments for this command. The server will respond
235+
with a list of all the files on the server. After the name of each
236+
file, there will be a space, then the size of the file (in bytes),
237+
then another space, then the UNIX timestamp of when the file was
238+
last modified. Each item in the list is separated by a newline
239+
character. The end of the list will be denoted by two newline
240+
characters in a row. If there are no files in the list, the LS
241+
command will just return two newline characters. If the user is
242+
not authenticated, then return with the "GTFO" error.
243+
244+
DELETE FILE (DELETE)
245+
246+
The argument field is a series of ASCII characters that represent
247+
the name of the file on the server to be deleted. If the delete
248+
option is successful, the server will respond with "OK". If the
249+
file does not exist, the server will respond with "NO SUCH FILE".
250+
If the user is not authenticated, then return with the "GTFO"
251+
error.
252+
253+
READ FILE (READ)
254+
255+
The argument field is a series of ASCII characters that represent
256+
the name of the file on the server that the user wants to read.
257+
If the file exists on the server, the server responds with the
258+
ASCII representation of the number of bytes that are in the file,
259+
followed by an ASCII newline, followed by all of the data in the
260+
file. If this file does not exist on the server, the server
261+
responds with a "NO SUCH FILE" error. If the user is not
262+
authenticated, then return with the "GTFO" error.
263+
264+
CREATE NEW FILE (CREATE)
265+
266+
The argument field is a series of ASCII characters that represent
267+
the name of the file that the user wants to create on the server,
268+
followed by a space, followed by the number of bytes that are in
269+
the file that is to be created on the server. If a file exists on
270+
the server with that name, the server responds with the "FILE
271+
ALREADY EXISTS" error. Otherwise, the server responds with "OK".
272+
If the user is not authenticated, of course, the server will
273+
respond with the "GTFO" error.
274+
275+
Next, the server will expect the client to send exactly the number
276+
of bytes that were specified at the time the command was issued.
277+
After this amount of bytes have been transmitted, the server will
278+
respond "OK", or "WRITE ERROR" if there was a problem writing the
279+
file to the server. Then, the server will expect another command,
280+
like normal.
281+
282+
283+
284+
Lewis & Edmands [Page 6]
285+
286+
RFC nnnn November 2007
287+
Goetzl File Server
288+
289+
APPEND TO FILE (APPEND)
290+
291+
The argument field is a series of ASCII characters that represent
292+
the name of the file on the server that the user wants to append
293+
to, followed by a space, followed by the number of bytes that are
294+
to be appended to the file. The server will respond with "OK". If
295+
the file does not already exist, the server should create a new
296+
file with the same name.
297+
298+
Next, the server will expect the client to send exactly the number
299+
of bytes that were specified at the time the command was issued.
300+
After this amount of bytes have been transmitted, the server will
301+
respond "OK", or "WRITE ERROR" if there was a problem writing the
302+
file to the server. Then, the server will expect another command,
303+
like normal.
304+
305+
7. AUTHORS ADDRESS
306+
307+
Ryan Lewis - [email protected] (518) 755-1738
308+
Max Edmands - [email protected] (845) 750-1068
309+
310+
8. CONCLUSION
311+
312+
Good luck, intrepid implementers of the Goatze! EOF
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+
Lewis & Edmands [Page 6]
342+

0 commit comments

Comments
 (0)