home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 2 BBS / 02-BBS.zip / FSC.ZIP / FSC-0016.TXT < prev    next >
Text File  |  1988-03-18  |  4KB  |  70 lines
  1. FSC-0016
  2.  
  3.                        FidoNet mail session startup
  4.                                     by
  5.                           Bob Hartman, 1:132/101
  6.  
  7.      Presently, FSC001  contains no  provisions for  what actually  happens
  8. when a  call is received.  All it says is that the baud rate is determined,
  9. and a netmail session starts.  Currently, this is one of the most difficult
  10. sections of  a netmail program to get working.  All programs have different
  11. timeouts, different ways of determining baud rates, not to mention the fact
  12. that MNP  modems talking  to non-MNP  modems can cause problems.  For these
  13. reasons, I  propose the following "standard" for netmail programs that deal
  14. with the beginning of a netmail session:
  15.  
  16. 1. When  carrier is  detected, all  input should be deleted by the receiver
  17.      for a period of 2 seconds (I would even be comfortable with 5 seconds,
  18.      but it  makes human  callers a  bit unhappy).   This  enables most MNP
  19.      modems to  send their  string of  MNP "garbage" and not cause spurious
  20.      characters to impact the netmail startup logic.
  21.  
  22. 2. The  sender should  send ONLY  carriage return  and space  characters as
  23.      "whacking return"  until the receiver acknowledges by sending a string
  24.      containing a carriage return or space character.
  25.  
  26. 3. The  sender should whack return at the rate of one character per second.
  27.      This gives Fido 11w and other implementations time to purge buffers if
  28.      line noise  is received  which would  screw up the baud rate detection
  29.      logic.
  30.  
  31. 4. After  recognizing the  "whack"  of  the  sender,  the  receiver  should
  32.      disregard all characters except the following:
  33.  
  34.      TSYNC -  start of  an FSC001  session (a  delay of at least one second
  35.           should appear  here so  the sender  can recognize  a valid  NAK -
  36.           otherwise, it  could still  be the  banner file being displayed).
  37.           WaZOO mailers  should disregard the first TSYNC in the hopes that
  38.           a YooHoo  will appear.   If  a YooHoo  is not  received within  2
  39.           seconds, or  a second  TSYNC appears, an FSC001 session should be
  40.           started.
  41.  
  42.      YooHoo - signals the start of a WaZOO netmail session.  FSC001 mailers
  43.           should just ignore this character as noise.
  44.  
  45.      Carriage return,  space -  Send  message  containing  carriage  return
  46.           and/or space.   The  sender may  have missed  it the  first  time
  47.           around and is still "whacking return".
  48.  
  49.      Line feed  - This  is probably a user, and a message explaining things
  50.           to him/her should be sent out.
  51.  
  52.      Escape - This character is currently used by at least one front end as
  53.           a quick  method for users to enter the BBS.  If received in "mail
  54.           mode", it  should always  be ignored.    (I  propose  this  as  a
  55.           "standard" so that all front-ends can use this feature.  If it is
  56.           not  standardized  now,  all  front-ends  could  conceivably  use
  57.           different characters  and  further  muddle  the  picture  when  a
  58.           netmail session is starting.)
  59.  
  60. 5. After  the sender has started sending TSYNC and/or YooHoo, the responses
  61.      must be  looked at  very carefully.   A  line with  no activity for at
  62.      least .5  seconds must  be seen.   Otherwise,  it is  possible that  a
  63.      banner file is still being displayed and a 'C' is meaningless.
  64.  
  65.      If  all   FidoNet  compatible  mail  programs  were  to  follow  these
  66. conventions, I  believe that  the start  of a netmail session would be much
  67. more reliable  than it  is right  now.  Too often we see front end packages
  68. fall through  to the  underlying BBS because of MNP negotiation, or one end
  69. taking longer than the other to give a connect message.
  70.