File: INFO

package info (click to toggle)
fsp 2.81.b3-2
  • links: PTS
  • area: main
  • in suites: potato
  • size: 1,072 kB
  • ctags: 1,264
  • sloc: ansic: 7,764; makefile: 357; sh: 312
file content (115 lines) | stat: -rw-r--r-- 5,429 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
					     Interested parties please email
					           A.J.Doherty@reading.ac.uk
    What is the purpose of FSP (V2.8.1):

	FSP is a set of programs that implements a public-access archive
	similar to an anonymous-FTP archive.  It is not meant to be a
	replacement for ftp; it is only meant to do what anonymous-ftp
	does, but in a manner more acceptible to the provider of the
	service and more friendly to the clients. 

	Providing anonymous-FTP service can be costly --- each active
	session consumes one process slot in the OS and one stream socket
	entry in the network sub-system.  The servers can also run
	concurrently, adding to the system load.  A popular archive site
	can easily be overwhelmed as a result.  Some were forced to
	shutdown and some impose inconvenient access restrictions. 

	Unlike FTP, FSP is connection-less and virtually state-less.  One
	server handles requests from all clients machines.  Each active
	client machine takes up 16-bytes in a dynamically extensible
	table.  Since only one server exists on a server machine at any
	time, the load added to the server machine is no more than one. 

	In exchange for allowing site operators to keep their sites open
	and do away with cumbersome access restrictions, this is what the
	clients accept with FSP: 

	 1) Lower transfer rate.  The maximum rate is 1 kbyte per UDP
	    message round-trip time between the client and the server.
	
	In addition to the potential for more abundant sites and more
	accessible sites, this is what the clients gain with FSP:

	 1) Robustness.  Since FSP is connectionless, fluctuations in
	    the network will not abort a FSP transaction.  Furthermore,
	    the 16-bytes of data for each client can be regenerated at
	    any point during any transaction.  Thus, if the server goes
	    down at any point during a transaction, the transaction will
	    resume when the server is restarted.  (like NFS) 

	 2) Friendlier user interface.  FSP does not have its own command
	    interpretor like FTP.  Since it is connectionless, there is
	    no reason to carry much information from one command to the
	    next, and the commands can all be made into individual unix
	    programs.  For instance, there is one program you run to list
	    the directory and another you run to download a file. 

	 3) Client protection.  FSP oversees a directory structure similar
	    to that of an anonymous-FTP.  However, a directory created
	    via FSP transaction is owned by the client machine that issued
	    the creation request.  The client can create and delete files
	    and subdirectories in that directory.  In addition, the client
	    can enable any of the four attributes for that directory: 

		A) Give all other clients the permission to create files.

		B) Give all other clients the permission to delete files
		   or subdirectories.

		C) Give all other clients the permission to read files.
		   (this is true by default)

		D) Give all other clients the permission to create sub-
		   directories.

	    Note: A subdirectory can be deleted if it is empty and the
		  client owns the subdirectory.

	 4) Server protection.  FSP server does not spawn sub-programs.
	    It will accept only paths that are downward relative to its
	    designated working directory.  On systems with symbolic links,
	    the server will follow symbolic links, but it does not follow
	    uplinks ("..").  Clients cannot create symbolic links and
	    care should be taken so that other users on the server machine
	    cannot create symbolic links in the server's work space. 

	    It is also fairly difficult to formuate an attack to force a
	    shutdown of a FSP site by actions of a rogue site.  About the
	    only way to distrupt a FSP service is to flood the FSP site
	    with network packets.  FSP server prevents itself from
	    'counter-flooding' by filtering for legitimate requests using
	    the following method:

		A) Each request message contains a key.  For each client,
		   server database contains the keys to be used for the
		   next client request and for the previous client request.

		B) If the next request does not contain a key that matches
		   either of the two keys, it is accepted only if at least
		   one minute has elapsed since the last time a request
		   is accepted.  If the key does match the old key
		   (retransmit by client) it is accepted if the elapse time
		   is greater than 3 seconds.

		C) Every request message accepted is acknowledged with
		   one reply message.  The reply message contains a new
		   key to used for the next request.  The new key is
		   computed by the server with a pseudo-random number
		   generator. 

	    Flooding is a blatant violation of network etiquette because
	    a site can be subjected to flooding attack whether it has FSP
	    running or not, and flooding congests every link and gateway
	    between the rogue client and the server.  As a further measure
	    of protection, the server loads a table of rogue clients on
	    startup.  The server will not respond to requests from any of
	    those clients.

    ***********************************************************************

    This is a free software.  Be creative; make your own macros and tools
    and let me know of any bugs and suggestions.

    A newsgroup for the discussion of the use and development of the FSP
    software is now available (alt.comp.fsp)