Home

Main
FSP Servers
FSP Software
FSP Downloads
FSP project
Testers needed
FSP Team
Open tasks
Bazaar
Mailing lists
Bug Tracker
FSP Documents
Purpose
History
Articles
Today
Future
INFO
FAQ Old | New
FSP Protocol
Quotes
FSP suite
Browse
Copyright
Changelog
Todo
Bazaar
Freshmeat page
Ohloh page
Java library
Browse
API
READ.ME
Changelog
Freshmeat page
Ohloh page
FSP proxy
Browse
READ.ME
Changelog
Freshmeat page
PyFSP
Browse
C library
Browse
README
NEWS
Changes
TODO
Freshmeat page
Ohloh page
Misc
Wizards vs CSH
FSP entry in
GNU dir
Wikipedia
Stats
CNW
My projects
FSP Client
Download Machine
Smart Cache
SC Loader
FSP Suite
Other programs
![[CNW:Counter]](http://counter.cnw.cz/cnwikonka.cgi?fsp&on)
|
What is the purpose of FSP
Written by A.J.Doherty@reading.ac.uk
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 acceptable 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:
- 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:
- 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)
- 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.
- 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:
- Give all other clients the permission to create files.
- Give all other clients the permission to delete files or subdirectories.
- Give all other clients the permission to rename files or subdirectories.
- Give all other clients the permission to read files. (this is true by default)
- Give all other clients the permission to list directory files. (this is true by default)
- Give all other clients the permission to create subdirectories.
- 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 formulate an attack to force a
shutdown of a FSP site by actions of a rogue site. About the
only way to disrupt 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:
- 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.
- 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.
- 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.
|