home *** CD-ROM | disk | FTP | other *** search
/ AmigActive 13 / AACD13.ISO / AACD / Online / fsp / ChangeLog next >
Text File  |  1992-04-08  |  9KB  |  191 lines

  1. Version 1.0 -- Dec 91.  Original source created.
  2.  
  3. Version 2.0 -- Dec 91.  Added man pages.  Server bug fix.  In 1.0, files
  4.            in a directory that is protected from deletion can still
  5.            be written over. In 2.0, it is prohibited as well. 
  6.  
  7. Version 2.1 --    Jan 1, 92.
  8.  
  9.         1) The maximum length of a name in pre-2.1 server is
  10.            both limited by the 1k-byte udp packet size and, in
  11.            some cases more severely, by the OS it is running in.
  12.            On some systems, the OS imposes a limite of 14 chars.
  13.            For those systems, the server can now be made to hash
  14.            long names into short ones.  The effect is transparent
  15.            to the clients except when two long names gets hashed
  16.            into the same value.  In that case, they will refer
  17.            to the same file during downloading, and they will
  18.            displace each others during uploading.
  19.  
  20.         2) Since directories, unlike files, have undisputable
  21.            ownership, removal of a directory owned by a client
  22.            should depends only on the ownership of the directory
  23.            itself, and not on that of its parent directory.  In
  24.            pre-2.1 server, the client must have delete permission
  25.            to the parent directory before it is allowed to delete
  26.            the subdirectory.  In 2.1, the permission is not needed.
  27.  
  28. Version 2.2 --    Feb 15, 92.
  29.  
  30.         1) The fput and fgetcmd utilities will now accept a list of
  31.            files from its standward input.  See their man pages for
  32.            this expanded usage.  This is useful if you don't want
  33.            file names to show on 'ps' output.
  34.  
  35.         2) The retransmit timer for client code has been changed
  36.            to use an adaptive algorithm.  In pre-2.2 versions of
  37.            FSP, clients will retransmit if it has not received a
  38.            response from the server after a delay of 3 seconds.
  39.            In version-2.2, two separate delays are used.  The
  40.            "busy" delay is used when waiting for a reply for the
  41.            first try and the second try.  Any time a second try
  42.            is necessary, the delay is increased by 50%.  Every
  43.            first try brings the delay 12.5% closer to the initial
  44.            delay setting (3 seconds by default, settable by the
  45.            FSP_DELAY variable).  For the third try and beyond,
  46.            the "idle" delay is used.  For each try, the delay is
  47.            doubled.
  48.  
  49.         3) Makes available FSP request code space 0x80 - 0xff for
  50.            future user extensions.  Each such extension will begin
  51.            with a code byte in that range, and followed by a control
  52.            block, which is likely to be different from the existing
  53.            one.  The basic operations of FSP will not require the
  54.            use of such extensions.
  55.  
  56.         Note:  2.2 does not involve changes to the server itself.
  57.                The server is been checked out and added to by a
  58.                few people on the net.  I will wait until the
  59.                modifications stabilize before I consolidate them.
  60.  
  61. Version 2.3 -- Mar 9, 92
  62.  
  63.         1) The bsd_src/glob.c file has a bug in blkfree function
  64.            in that it tries to free something that is actually
  65.            on the stack of the glob function. The last call to
  66.            free has been commented out to fix the bug. 
  67.  
  68.         2) The fspd has a bug whoes only visible manifestation
  69.            is the that protection can't be changed.  The fix has
  70.            required a moderate amount of code change in fspd.
  71.  
  72.         3) .FSP_NO_DEL and .FSP_NO_ADD mechanism has been replaced
  73.            by .FSP_OK_DEL and .FSP_OK_ADD mechanism.  Thus by
  74.            default, a directory is no delete and no add.
  75.  
  76.         4) fprocmd is modified to relax option checking, allowing
  77.            arbitrary option characters be passed to the fsp server.
  78.  
  79.         5) A fls bug is fixed so that a "fls /" in a directory other
  80.            than the root directory will not cause an error.
  81.  
  82.         6) A -DDIRENT switch is added in Makefile to help support
  83.            those machines that does not have /usr/include/dirent.h.
  84.  
  85. Version 2.3a -- March 20, 1992
  86.  
  87.         1) In a few places, non-critical errors of the form:
  88.                if(errno = EINTR) ....
  89.            was made.  It obviously should have been == instead.
  90.            The problem is fixed.
  91.  
  92.         2) In the previous versions there is a potential problem
  93.            such that if the first reply packet is dropped or is
  94.            messed up, making a retransmit necessary, fspd will
  95.            make the client utility wait for a 1 minute timeout.
  96.            A potential loop hole for this happening has been
  97.            closed by modifying server_lib.c where the packet key
  98.            is checked. 
  99.  
  100. Version 2.4 -- March 27, 1992
  101.  
  102.         1) fgrab/fgrabcmd client utility is added.  It is like
  103.            fget except it also deletes the named files in such a
  104.            way that if there are multiple fgrabs for the same
  105.            file, only one will succeed. One bug/mis-feature of
  106.            fgrab is that when fgrab is terminated abnormally, the
  107.            file is not restored. This command is useful for things
  108.            like sharing bone files for modified versions of nethack. 
  109.  
  110.         2) FSP now allows multiple client programs to run at the
  111.            same time if one of the three multiplexing mechanisms
  112.            are chosen during compile time.  It is likely that at
  113.            least one of them will work for your system.  The
  114.            multiplexing is done at the client side, and does not
  115.            allow the client machine to issue request messages at
  116.            a higher rate compared to the previous versions.  The
  117.            FSP_LOCALPORT variable is no longer needed.  However,
  118.            if used, it will force serialization of client programs,
  119.            which might be desireable if none of the multiplexing
  120.            mechanisms are suitable for your machine.  In order to
  121.            accommodate this change, the server code has been
  122.            changed to store temporary upload files with a different
  123.            name from the previous version.  The names now have to
  124.            identify sender's port as well as sender's internet id.
  125.            Change is necessary to keep it under 14-character limit
  126.            of some OS.
  127.  
  128.         3) Progress report mechanism enabled by FSP_TRACE variable
  129.            now try to update the kbyte display more promptly.
  130.  
  131.         4) fcat/fcatcmd will now turn off FSP_TRACE during its
  132.            file transfer if its stdout is a tty.
  133.  
  134. Version 2.5 -- April 8, 1992
  135.  
  136.         1) A bug introduced during the last release --- fspd will
  137.            not timeout and exit when running under inetd mode.
  138.            This bug is now fixed.  It was introduced because it
  139.            is more convienent at one time for it not to exit when
  140.            it is still being debugged.  The patch to stop it from
  141.            exiting was not removed before release time. 
  142.  
  143.         2) A very rarely seen bug in some OS is circumvented. UDP
  144.            packet's headers contain a checksum field.  If the
  145.            checksum option is disabled, the OS will set the
  146.            checksum field to 0 before sending, and will not check
  147.            the checksum field when message is received. If the
  148.            option is enabled, the OS will stuff the checksum into
  149.            the checksum field.  When a packet is received, the
  150.            checksum field is checked.  If the checksum field is 0,
  151.            then the OS assume that the sender does not have option
  152.            enabled, and therefore the checking is skipped.
  153.  
  154.            Problem arises when a packet's computed checksum is
  155.            zero.  Some OS will stuff 0xffff into the checksum
  156.            field before sending such a message to distinguish it
  157.            from the case for which checksum is disabled.  Other
  158.            OS couldn't recognize 0xffff as an indication that the
  159.            actual checksum could be either 0 or 0xffff, and
  160.            subsequently reject the message. The client can thus
  161.            get stuck forever in retransmitting a request that
  162.            happens to have 0 for the computed checksum, but
  163.            0xffff for the checksum field.
  164.  
  165.            To get around the problem, the sequence number field
  166.            of the request message (which has meaning only to the
  167.            client software), is partitioned such that 2 of the
  168.            bits reflect the retry sequence, and the remaining 14
  169.            bits reflect the request sequence.  This will ensure
  170.            that if one request got ignored because it happens to
  171.            have a checksum of 0, the next retry will result in
  172.            a packet that does not have a checksum of 0.  The only
  173.            file affected here is client_lib.c.
  174.  
  175.         3) In response to those who have severely limited UDP
  176.            packet sizes, the environment variable FSP_BUF_SIZE
  177.            is supplied to set the data size of file and directory
  178.            information transfers. The default is 1024.  You cannot
  179.            set it to be bigger than 1024, but you can set it to
  180.            be smaller if you find that your system cannot pass
  181.            UDP packets that includes 1024 bytes of data.  This
  182.            requires changes both in the server and the client
  183.            code.  The first parameter field of get-file and
  184.            get-directory requests contains the path of the file
  185.            or directory.  The second parameter field was unused,
  186.            but it is now used to hold the number of bytes to read.
  187.            This change is backward compatible in the sense that
  188.            if the second field is empty (old client code), the
  189.            new server code will default to 1024.  Changes to the
  190.            client code is confined to client_util.c.
  191.