home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / c / ucaaaa.bwr < prev    next >
Text File  |  2020-01-01  |  2KB  |  55 lines
  1. To: cu20b.cc.columbia.edu!sy.fdc@ucbvax.berkeley.edu,
  2.         cu20b.cc.columbia.edu!Info-Kermit@ucbvax.berkeley.edu
  3. Subject: Bugs in existing Kermit-UCSD versions: UCIBMPC & UCMICRO
  4. Date: Sat Aug 13 14:04:28 1988
  5. X-Origin: The Portal System (TM)
  6. X-Possible-Reply-Path: R_Tim_Coslet@cup.portal.com
  7. X-Possible-Reply-Path: sun!portal!cup.portal.com!R_Tim_Coslet
  8.  
  9. This file discribes some SERIOUS bugs with the UCIBMPC & UCMICRO versions
  10. of Kermit-UCSD (and probably most of the other Kermit-UCSD versions).
  11. Please place copies of it in distribution as UCIBMPC.BWR and UCMICRO.BWR,
  12. and anywhere else you think appropriate.
  13.  
  14. These bugs have been fixed in my new UCPECAN version (in addition to
  15. adding many new features). I expect to have UCPECAN ready in about a week.
  16.  
  17.  
  18.                                         R. Tim Coslet
  19.  
  20. Usenet: R_Tim_Coslet@cup.portal.com
  21. BIX:    r.tim_coslet
  22.  
  23. -----------------------------------------------------------------------------
  24. Known SERIOUS bugs:
  25.  
  26. 1) Any error while sending WILL cause loss of data in the transfer.
  27.  
  28.         This bug is caused by an attempt in "sdata" to prepare the
  29.         next packet while waiting for the ACK packet. If an error
  30.         occurs "sdata" a) resends the current packet, b) discards the
  31.         next packet, c) prepares another new next packet.
  32.         
  33.         The bug may be fixed by using a boolean to keep track if there
  34.         is already a next packet available and skipping the call to
  35.         "bufill" if there is.
  36.  
  37. 2) Timeout errors in tranfers MAY cause the transfer to abort.
  38.  
  39.         This bug is caused by several of the "s*" and "r*" functions
  40.         not assigning a value to themselves prior to returning if the
  41.         packet type returned by "rpack" is NUL {chr(0)}. This leaves
  42.         the returned value unknown and thus may cause the state machine
  43.         in "sendsw" or "recsw" to abort the transfer because of illegal
  44.         state.
  45.         
  46.         The bug may be fixed by adding statements to assign the correct
  47.         state to each function following the...
  48.         
  49.                 else if (ch = chr(0)) then
  50.                 
  51.         ...line in all "s*" and "r*" functions except "sdata" and "rdata"
  52.         (which use a while loop instead of returning to the state machine
  53.         after every packet).
  54.  
  55.