home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / protocol / whatami.draft1 < prev    next >
Text File  |  2020-01-01  |  4KB  |  107 lines
  1. WHATAMI
  2.  
  3. A big problem with Kermit protocol & software is that it can be in so many
  4. different (combinations of) "modes" -- local, remote, client, server, etc etc,
  5. and users are understandably confused about where to give which command under
  6. what conditions -- the sender determines the file type, the receiver
  7. determines the packet length, the client can't send a GET or REMOTE or FINISH
  8. command unless the other Kermit is in server mode, etc.
  9.  
  10. Suppose the negotiation string (S and I packet + ACK) included a new field,
  11. "WHATAMI" containing the following information:
  12.  
  13. Client vs Server mode?
  14.   I am in server mode; I am not in server mode - 1 bit.
  15.  
  16. Current (global) file transfer mode
  17.   Text or binary - 1 bit.
  18.  
  19. Once having exchanged I or S packets, each Kermit knows which mode the other
  20. is in.  If the client knows it's talking to a server and (a) the connection is
  21. still open, and (b) a BYE or FINISH command has not been given, and maybe (c)
  22. a CONNECT command has not been given, the client can act more like a client --
  23. SET commands affecting certain parameters (block check, ...) can take effect
  24. at both ends simultaneously, just like with an FTP client and server.  A
  25. RECEIVE command can give an error message right away.  We could even have a
  26. way to set or change the default destination for commands like DIR, DEL, TYPE,
  27. CD, etc -- to have them take effect locally (as now) or at the server (as in
  28. FTP).
  29.  
  30. Implementation: The following remain reserved for Checkpoint/Restart:
  31.  
  32.   CAPAS+4, CHKPNT, 1 byte: WILL (1), WONT (0), DO (2)
  33.   CAPAS+5, CHKINT, 3 bytes: Checkpoint interval
  34.  
  35. In the absence of Checkpoint/Restart capability, these fields should be
  36. filled in as follows:
  37.  
  38.   CHKPNT: "0"      (Character 0)
  39.   CHKINT: "___"    (Three underscores)
  40.  
  41. CAPAS+8 will be the WHATAMI field, with room for 6 bits of information.
  42. This is a binary 6-bit quantity which will be encoded for transmission
  43. by adding 32 (SP).  The items here are simple on/off items corresponding
  44. to commands that, in a client-server environment, one would expect to take
  45. effect for forthcoming transfers:
  46.  
  47.   SET FILE TYPE { TEXT, BINARY }
  48.   SET FILE NAMES { CONVERTED, LITERAL }
  49.  
  50. The layout of the of the WHATAMI field is like this:
  51.  
  52.     Bit 5    Bit 4    Bit 3    Bit 2    Bit 1    Bit 0
  53.   +--------+--------+--------+--------+--------+--------+
  54.   | xxxxxx | xxxxxx | xxxxxx | SERVER | NAMES  | BINARY |
  55.   +--------+--------+--------+--------+--------+--------+
  56.  
  57. where:
  58.  
  59. xxxxxx = Reserved, and:
  60.  
  61. BINARY:
  62.   My global file transfer mode (SET FILE TYPE):
  63.     0 = TEXT
  64.     1 = BINARY
  65.  
  66. NAMES:
  67.   My SET FILE NAMES setting
  68.     0 = LITERAL (unconverted)
  69.     1 = CONVERTED (normal)
  70.  
  71. SERVER:
  72.     0 = I am not in server mode
  73.     1 = I am in server mode
  74.  
  75. ------------------------------
  76.  
  77. Whenever a Kermit transaction takes place, each Kermit makes a note of the
  78. other's "modes", and...
  79.  
  80.  1. Local Kermit client, remote Kermit server in text mode.
  81.     Client user says SET FILE TYPE BINARY, GET OOFA.ZIP.
  82.     At I-packet time, server sees that client wants a binary transfer,
  83.     and so saves its global mode, switches to binary, sends the requested
  84.     file(s) in binary mode, then restores its global mode, user gets the
  85.     expected binary transfer.
  86.  
  87.  2. Like (1), but with SET FILE NAMES LITERAL, same deal.
  88.  
  89.  3. Local Kermit client, remote Kermit in RECEIVE mode.
  90.     Client user says REMOTE HELP or other command-for-server.
  91.     Client Kermit sends I-packet, remote Kermit sends ACK saying I Am Not
  92.     A Server, local Kermit knows immediately to give up and can tell the
  93.     user why.
  94.  
  95.  4. Local Kermit client, remote Kermit in SEND mode.
  96.     Client user says GET blah, thinking that GET is the same as RECEIVE.
  97.       Remote sends S.
  98.       Local sends I.
  99.       Remote sends E and quits, which is proper.
  100.       Local ignores E because of "the rule", and sends R.
  101.       There is no response, so local times out & resends R lots of times.
  102.     WHATAMI doesn't help here.  But the SENDer could retransmit the S
  103.     packet instead of sending an E-packet, which would make the GETter
  104.     diagnose a fatal error.
  105.  
  106.  
  107.