		FSP-2.7.1 for IBMRT running AIX-2.2.1
		=====================================


fsp271bin1.tgz		distribution with normal clients
fsp271bin2.tgz		distribution with merged clients


Francois Normant (fn@mathappl.polymtl.ca).
--------------------------------------------------------------------------


Installation
------------
1) Unpack this archive in /usr/local.
2)

Client utilities:
        All inter-command states are kept in these three shell environment
        variables.

            FSP_PORT            Port number of the fspd you wish to contact.
            FSP_HOST            Host name or number of the fspd.
            FSP_DIR             Your current working directory in the archive.

        When multiple client utilities are run at the same time on the
        same client machine, packet multiplexing mechanisms can be used
        to enable concurrent access to the same fsp database.  If none
        of the mechanisms are selected at compile time, FSP_LOCALPORT
        can be used to ensure that only once client utility can run at
        any time.  In this case, FSP_LOCALPORT can be set to any port
        number not current used on the client machine.

        FSP_TRACE can be set if you want status reports be printed while
        files are being transferred.

	FSP_DELAY variable can be used to set the retransmit interval for
	client utilities (in thousandth of a second).  The retransmit rate
	is adjusted in an exponential manner, until the retry rate reaches
	5 minutes per retry.  This delay cannot be set below 250 usecs.

        FSP_BUF_SIZE can be set to a positive number less than or equal
        to 1024.  When set, it determines the size of data to be send for
        each request during file and directory information transfer.  The
        default is 1024.  Some sites are connected via links that cannot
        transmit buffers containing 1024 bytes of data in addition to the
        header information.  Setting FSP_BUF_SIZE to a lower value will
        allow these sites to access fsp archives.

        FSP_LOCAL_DIR can be set to a local working directory from/to which
        all data will be transferred.

Server Administration:
	The only things you need for setting up a FSP server is a work
        directory for the service the FSP server itself (fspd) and
	an fspd.conf file in the place you specified in include/server_conf.h.

	To create an fspd.conf file, copy the example.conf file
	provided to the correct place and edit to suit your tastes.

        fspd can run independently or it can be run under inetd.  When
        running independently, fspd waits for messages through a UDP
        socket whoes port number is defined in the fspd.conf file. 
	When runing under inetd, fspd is invoked as in.fspd.  Inetd will
	spawn fspd when a message arrives for the FSP socket.  The fspd
	process will take over and stick around to wait on additional
	messages.  After 2 minutes pass with no messages, fspd will exit
	and return control to inted.

        Sample setup for inetd operation:

            In /etc/services file:

                fsp             21/udp          fspd

            In /etc/inetd.conf file:

                fsp dgram   udp wait ftp /usr/etc/fspd in.fspd

            In this sample, the same port number for ftp is used for the
            fsp socket.  There will not be a conflict because ftp uses
            stream protocol, and fsp uses UDP protocol.  The fspd program
            in this example is ran under user 'ftp'.

	Many other options controlling the behavior of fspd can be set in
	the fspd.conf file.  Please read the comments in the example.conf
	file for details.

	FSPD provides directory security through a series of . files created
	in the directories serviced by fspd.  These files are invisible to
	the clients, and can (mostly) be changed via the fprocmd client
	utility (or by the server administrator manually).  The only file
	that can not be changed in this manner is the ownership of a
	directory.  The files and their meanings are:

	.OWN.XXXXXXXX	specifies that the machine whose IP number is
			encoded as XXXXXXXX owns the directory.  The owner
			of a directory automatically has all other rights to
			a directory and is the only one that can change the
			other protections.  It is created when a directory
			is initially created in the archive via fmkdir.

	.FSP_OK_DEL	Grants any client the permission to delete any file
			from the current directory.

	.FSP_OK_ADD	Grants any client the permission to add new files to				the current directory.

	.FSP_OK_MKDIR	Grants any client the permission to create new sub-
			directories under the current directory owned by
			the client creating the directory.

	.FSP_PRIVATE	If this file exists, only the owner of the directory
			is allowed to read the contents of the files in the
			directory.  Subdirectories of this directory will
			inherit the privacy protection.

        Clients do not get to read the directory information directly.
        Instead, fspd maintains a directory listing for each directory
        in a cache file.  If the directory is writable by fspd, or if a
        writable file in it is prepared beforehand, fspd will store the
        directory information in .FSP_CONTENT file in that directory.
        Otherwise, it will store the information in a pair of files (with
        hashed names) in a special directory specified in the fspd.conf
	file.  The latter allows read-only directories to be exported.

        When a client requests information for a directory, the cache
        file is created if it doesn't exist, and it is rebuilt if it is
        out of date.  The information is accessed by having the client
        read the directory listing file. Care is taken so that the client
        will not get corrupted entries when the directory is changed while
        the listing is being read.

        Files being uploaded are first written to a temporary file in the
        work directory: .TXXXXXXXXYYYY where XXXXXXXX is the inet number
        of the client, and YYYY is the port number of the client program.
        When upload is compelete, the file is moved into the intended
        location.

        Sending it an 'alarm' signal will cause fspd to dump its current
        client database into the file .HTAB_DUMP in the work directory.
        This can be useful for debugging and for catching rogue clients.


=========================== INFO =================================

					     Interested party please email
					       jtraub@cs.cmu.edu
    What is the purpose of FSP (V2.7):

	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, flucturations 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 mailing list for the discussion of the FSP software is now available
    (started Oct 2, 1992.)  To get on the list, send an email stating
    that you want to be on the FSP list to the following address:

        listmaster@Germany.EU.net

    Articles to be distributed to the subscribers should be sent to the
    following email address:

        fsp-discussion@Germany.EU.net
