Columbia Kermit/kermit.zip/protocol/whatami.msg

Text File | 2020-01-01 | 19KB | 449 lines

 6-Jun-94 14:09:32-GMT,3716;000000000001
Received: by watsun.cc.columbia.edu id AA07316
  (5.65c+CU/IDA-1.4.4/HLK); Mon, 6 Jun 1994 10:09:19 -0400
Date: Mon, 6 Jun 94 10:09:19 EDT
From: Frank da Cruz <[e-mail]>
To: Joe Doupnik <[e-mail]>
Subject: Idea
Message-Id: <[e-mail]>

A big problem with Kermit protocol & software is that it can be in so many
different (combinations of) "modes" -- local, remote, client, server, etc etc,
and users are understandably confused about where to give which command under
what conditions -- the sender determines the file type, the receiver
determines the packet length, I can't send a GET or REMOTE or FINISH command
unless the other Kermit is in server mode, etc.

I wonder if there are some simple things we can do to alleviate the situation.

Suppose the negotiation string included a new field, "What I Am".  It might
contain information like:

Local vs Remote mode?
  No, you've got to get this right first before they can communicate at all.

Client vs Server mode?
  Yes: I am in server mode; I am not in server mode - 1 bit.

Default (global) file transfer mode, text vs binary:
  Yes: 1 bit.

Suppose we have two Kermit programs that can do this.

 . Client sends a REMOTE, GET, FIN, etc, command to another Kermit that is not
   in server mode.  Remote Kermit is unprepared for an I packet, and so
   responds with an Error packet "Unexpected packet type" (not very
   informative to the untrained user), and worse, the client stays in protocol
   mode because of the (old, obscure) rule that says an E-packet in response
   to an I-packet should be ignored because I-packets are optional items.
   Thus the remote Kermit went back to its prompt and the local Kermit is
   timing out and resending packets to it for several minutes.  Recovering
   from this one would be possible if we allow Kermit in RECEIVE mode to
   accept an I packet, responding with an I-Ack that says "I'm not a server",
   which the client interprets as "Oops, forget it.".

 . User tells client to SET FILE TYPE BINARY and then gives a GET command,
   expecting a binary-mode transfer, but the file comes in text mode because
   nobody told the server.  This is a big one, that bites people all the time.
   This way, the server can switch to binary mode automatically before
   starting to send.  Note: We could not use the same mechanism in
   SEND/RECEIVE transfers because in case of disagreement we'd have no
   criterion for deciding which one to believe, other than the current one
   ("the sender's mode takes precedence").

 . (think of more...)

Once having exchanged I or S packets, each Kermit knows which mode the other
is in.  If the client knows it's talking to a server and (a) the connection is
still open, and (b) a BYE or FINISH command has not been given, and maybe (c)
a CONNECT command has not been given, the client can act more like a client --
SET commands affecting certain parameters (block check, ...) can take effect
at both ends simultaneously, just like with an FTP client and server.  A
RECEIVE command can give an error message right away.  We could even have a
way to set or change the default destination for commands like DIR, DEL, TYPE,
CD, etc -- to have them take effect locally (as now) or at the server (as in
FTP).

This is still a very rough sketch of an idea, but I think it should be pretty
simple to design and implement, and would score big in the "user friendliness"
department.

Just background noise while doing real work...  Maybe I'll fool with it in
C-Kermit to see how it feels.  Hopefully (at least at first) no changes in
commands -- just better behavior based on additional behind-the-scenes smarts.

- Frank

 6-Jun-94 14:29:07-GMT,1047;000000000015
Received: from grumpy.usu.edu by watsun.cc.columbia.edu with SMTP id AA08924
  (5.65c+CU/IDA-1.4.4/HLK for <[e-mail]>); Mon, 6 Jun 1994 10:29:01 -0400
Received: from cc.usu.edu by cc.usu.edu (PMDF V4.2-13 #4757) id
 <[e-mail]>; Mon, 6 Jun 1994 08:28:48 MDT
Date: Mon, 06 Jun 1994 08:28:48 -0600 (MDT)
From: Joe Doupnik <[e-mail]>
Subject: Re: Idea
To: [e-mail]
Message-Id: <[e-mail]>
X-Vms-To: IN%"[e-mail]"
X-Vms-Cc: JRD
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Frank,
    Yeah! Whatami info swap: long overdue.
    Maybe the I packet, as you suggest, includes mode settings (binary
etc).

    Goto: fixed. The old code distinguished line terminators as CR or
LF depending on whether macro or disk file. I've canonized (canonicalized
in American) this stuff to be just CR internally. Maybe that's canoned.
    New msk314.exe to watsun in a couple of minutes so we have something
to test today.
    Joe D.

 6-Jun-94 14:35:51-GMT,779;000000000001
Received: by watsun.cc.columbia.edu id AA09525
  (5.65c+CU/IDA-1.4.4/HLK); Mon, 6 Jun 1994 10:35:39 -0400
Date: Mon, 6 Jun 94 10:35:39 EDT
From: Frank da Cruz <[e-mail]>
To: Joe Doupnik <[e-mail]>
Subject: Re: Idea
In-Reply-To: Your message of Mon, 06 Jun 1994 08:28:48 -0600 (MDT)
Message-Id: <[e-mail]>

> Yeah! Whatami info swap: long overdue.
> Maybe the I packet, as you suggest, includes mode settings (binary etc).
>
Good, then I'll start thinking about it a little more organizedly (?).

> Goto: fixed.
>
Great!

> The old code distinguished line terminators as CR or
> LF depending on whether macro or disk file. I've canonized (canonicalized
> in American)...
>
Only the Pope can canonize...:-)

- Frank

 7-Jun-94  0:29:02-GMT,1667;000000000001
Received: by watsun.cc.columbia.edu id AA20684
  (5.65c+CU/IDA-1.4.4/HLK for Frank da Cruz <[e-mail]>); Mon, 6 Jun 1994 20:28:53 -0400
Date: Mon, 6 Jun 94 20:28:53 EDT
From: Frank da Cruz <[e-mail]>
To: Joe Doupnik <[e-mail]>
Subject: WHATAMI
Message-Id: <[e-mail]>

(which sounds like a kind of Japanese mustard...)  I've been ruminating
about this on and off today, and so far I can only think of one use for it:
to make Kermit act like FTP.  In this regard, there are only two commands
I can think of that you would give to a Kermit client, which you also wanted
to affect the Kermit server:

  SET FILE TYPE { TEXT, BINARY }

and:

  SET FILE NAMES { CONVERTED, LITERAL }

Everything else is either handled already (like block check type, window size,
character set, etc), or is not common to both (like packet length).

So, assuming I'm not terminally stupid, I can cobble together a spec for this
in about 5 minutes, and code it in another 20 (after you get backwards GOTO
fixed :-)

As a sanity check, I looked at FTP, and as far as I can tell, the only true
"bimodal" command is TYPE.  All the others (like name conversion, etc) are
hacks executed unilaterally by the client.

Can you see something big that I missed?

- Frank

P.S. Btw, a guy named James Huggins at the U of Michigan has written,
for publication, a 40-page mathematical correctness proof of the Kermit
protocol.  (Phew!)  I don't have his permission to distribute it yet, so
don't show it to your students.  It's in ~jrd/kermit.ps on watsun.  (Next,
maybe he'd like to have a crack at the command parser...)


 7-Jun-94  0:42:37-GMT,1376;000000000015
Received: from grumpy.usu.edu by watsun.cc.columbia.edu with SMTP id AA21279
  (5.65c+CU/IDA-1.4.4/HLK for <[e-mail]>); Mon, 6 Jun 1994 20:42:35 -0400
Received: from cc.usu.edu by cc.usu.edu (PMDF V4.2-13 #4757) id
 <[e-mail]>; Mon, 6 Jun 1994 18:42:18 MDT
Date: Mon, 06 Jun 1994 18:42:18 -0600 (MDT)
From: Joe Doupnik <[e-mail]>
Subject: Re: WHATAMI
To: [e-mail]
Message-Id: <[e-mail]>
X-Vms-To: IN%"[e-mail]"
X-Vms-Cc: JRD
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Frank,
    SET FILE TYPE, and maybe the common GET/RECEIVE mixup. I know the
long Server Ready message boggles the minds of mere users, so they tend
to say Send on one side and many times try GET on the other. Certainly
TYPE ranks well above everything else.
    Protocol verification. I wonder if he used the Petri net program
which appeared on News a year or so ago. Clearly, the MSK command parser
would cause it to exhaust memory from excessive numbers of states.
        I added handling of literal  OUT  AT\B  by using triple \, as
in OUT AT\\\B. Bob Babcock needed it and reminded me this afternoon.
I understand that means CK and MSK use the same notation for this.
    Backward jumps in scripts. It's in the works now as a matter
of fact.
        Joe D.

 7-Jun-94  1:37:00-GMT,1135;000000000001
Received: by watsun.cc.columbia.edu id AA23378
  (5.65c+CU/IDA-1.4.4/HLK for fdc); Mon, 6 Jun 1994 21:36:44 -0400
Date: Mon, 6 Jun 94 21:36:43 EDT
From: Frank da Cruz <[e-mail]>
To: Joe Doupnik <[e-mail]>
Subject: Re: WHATAMI
In-Reply-To: Your message of Mon, 06 Jun 1994 18:42:18 -0600 (MDT)
Message-Id: <[e-mail]>

> Protocol verification. I wonder if he used the Petri net program
> which appeared on News a year or so ago. Clearly, the MSK command parser
> would cause it to exhaust memory from excessive numbers of states.
>
No, it's something new they've developed at Michigan called Evolving Algebra;
this paper is one of many on the subject to be published in a book
"Specification and Validation Methods".

Anyway, I gave it a quick scan (40 pages!) and learned a few things.  For
example, his discussion of sliding windows seemed to contain an error (he said
the maximum window size was 32 rather than 31) -- luckily, before I pointed
out the error to him, I thought about it first, and he's right.  So, hurray,
we get another window slot.  Stupid me.

- Frank

 7-Jun-94 14:12:26-GMT,1796;000000000005
Received: by watsun.cc.columbia.edu id AA20551
  (5.65c+CU/IDA-1.4.4/HLK for Frank da Cruz <[e-mail]>); Tue, 7 Jun 1994 10:12:09 -0400
Date: Tue, 7 Jun 94 10:12:08 EDT
From: Frank da Cruz <[e-mail]>
To: Joe Doupnik <[e-mail]>
Subject: Re: WHATAMI
In-Reply-To: Your message of Mon, 06 Jun 1994 18:42:18 -0600 (MDT)
Message-Id: <[e-mail]>

> ... and maybe the common GET/RECEIVE mixup.  I know the long Server Ready
> message boggles the minds of mere users, so they tend to say Send on one
> side and many times try GET on the other.
>
This is the only one I haven't been able to apply the new scheme to, because
we never reach the point where the two Kermits exchange initialization data.
There are actually two scenarios:

 1. User escapes back and says GET, local Kermit sends I.
    Remote, after its DELAY expires, sends S.
    Local gets S and errors out, sends E to other Kermit.

When it works this way, it's not so bad.  Just as likely, however:

 2. Remote sends S, but user didn't escape back in time to read it.
    Local (having been told to GET) sends I.
    Remote sends E and quits - as it should.
    Local ignores E because of "the rule" and sends the R (GET) packet.

But the remote Kermit has already left protocol mode, so the local Kermit
keeps timing out and retransmitting the R packet.

It doesn't make sense for Kermit to accept I packets when in SEND mode (as
we did yesterday for RECEIVE mode), because the directionality is wrong --
the sender would have to send an ACK.

One possible way out of this would be if the sender retransmitted the S
packet instead of sending an E packet.  This would turn scenario 2 into 1.

Maybe I'll play with this later (after long meetings...)

- Frank

 9-Jun-94  1:50:12-GMT,7652;000000000401
Received: by watsun.cc.columbia.edu id AA12186
  (5.65c+CU/IDA-1.4.4/HLK for fdc); Wed, 8 Jun 1994 21:50:04 -0400
Date: Wed, 8 Jun 94 21:50:00 EDT
From: Frank da Cruz <[e-mail]>
To: Joe Doupnik <[e-mail]>
Subject: WHATAMI
Message-Id: <[e-mail]>

Well, Joe, I've spent most of today thinking about this one, and it's hard to
imagine how to stretch it beyond my original idea.  So here is a scaled-down
and deflated draft spec.  If you have any inspirational thoughts, let me know.
You'll find an implementation in my kermit subdirectory on netlab1; the
changes are small, confined to ckcker.h, ckcfns.c, and ckcpro.w -- just a few
lines of code.  Look for the strings "WHATAMI" and "WM_".

- Frank

WHATAMI  -  FIRST DRAFT

Those who are accustomed to using client/server applications such as FTP
expect that certain kinds of commands, when given to the client, will affect
the server correspingly.  Most notable among these commands (in FTP's case)
are those that set the transfer mode: BINARY, ASCII, TENEX, etc.

In Kermit, however, the transfer mode is determined by the file sender, a
concept totally unrelated to the client/server distinction, and
counterintuitive to most people.  Furthermore, Kermit programs do not always
have a client/server relationship -- there is also the send/receive
arrangement.

It might be desirable, when two Kermits are indeed client-and-server, for the
CLIENT's file-transfer mode to be used rather than the FILE SENDER's.

On the positive side, this would make Kermit more like FTP and, for that
matter, "less astonishing" to most users -- in English, one expects a "server"
to honor the wishes of a "client".  We have had many complaints from users who
put the remote Kermit in server mode, escaped back, told the local Kermit to
"set file type binary", then "get foo.zip", and were rudely surprised to find
the file was transferred in text mode.

On the other hand, this would be a change in behavior.  There might be users
who actually depend on the current behavior, e.g. so that files will be sent
to the server in binary mode, but retrieved *from* the server in text mode or
vice versa.

On balance, it seems better to make the change -- another case of doing what
the majority of users would expect, rather than catering to a small (perhaps
nonexistent) minority.  Should the minority exist at all, they can still
determine the transfer mode by giving SET FILE TYPE commands to the client.

Would it be desirable to extend this notion to the send/receive relationship?
No, it would not.  In that case, there would be no criterion at all for
settling a disagreement.  So in this case, traditional rules should prevail.

FEATURES

Two settings could be handled by WHATAMI: the file transfer mode (text or
binary) and the filename conversion method (converted [analogous to text] and
literal [analogous to binary]).

All other settings are either negotiated or conveyed already, or else they
are not appropriate for this type of treatment (because, for example, there is
no reason that they should always be the same in both Kermits).

The WHATAMI information will allow two Kermit programs to tell whether they
have a client/server relationship, and if so, to allow the file transfer mode
and name conversion to be determined by the client rather than the file sender.

IMPLEMENTATION

The following following fields remain reserved in the initialization string
for Checkpoint/Restart:

  CAPAS+4, CHKPNT, 1 byte: WILL (1), WONT (0), DO (2)
  CAPAS+5, CHKINT, 3 bytes: Checkpoint interval

In the absence of Checkpoint/Restart capability, these fields should be
filled in as follows:

  CHKPNT: "0"      (Character 0 = WONT)
  CHKINT: "___"    (Three underscores)

CAPAS+8 will be the WHATAMI field, with room for 6 bits of information.  This
is a binary 6-bit quantity which will be encoded for transmission via tochar()
and decoded after reception via unchar() (functions which add and subtract 32,
respectively).  The items are simple on/off items corresponding to commands
that, in a client-server environment, one would expect to take effect for
subsequent file transfers:

  SET FILE TYPE { TEXT, BINARY }
  SET FILE NAMES { CONVERTED, LITERAL }

The layout of the (unencoded) WHATAMI field is:

    Bit 5    Bit 4      Bit 3      Bit 2    Bit 1    Bit 0
  +--------+----------+----------+--------+--------+--------+
  |     1  | FLAG3    | reserved | FNAMES | FMODE  | SERVER |
  +--------+----------+----------+--------+--------+--------+

where:

  FLAG3  = 0, meaning that Bit 3 is undefined and should be ignored,

  BINARY:
    My global file transfer mode (SET FILE TYPE):
      0 = TEXT
      1 = BINARY

  NAMES:
    My SET FILE NAMES setting
      0 = LITERAL (unconverted)
      1 = CONVERTED (normal)

  SERVER:
      0 = I am not in server mode
      1 = I am in server mode

When we think of a use for Bit3, then we'll set Bit4 to 1 to indicate that
Bit3 contains a value to be used.  (Alternatively, if anybody can think of a
good use for these two bits before we go public with this, we can define them
now.)  Bit 5 is always set to 1; you'll see why in a second.

Thus, the valid values for the WHATAMI field are currently @ABCDEFG.

ACTIONS

Every Kermit program that implements the WHATAMI feature shall set its WHATAMI
field (as well as the intervening, but as-yet-unused, checkpoint-related
fields) in the initialization string.  This is purely a matter of reporting:
Here's What I Am.

Kermit programs that implement this feature shall keep a "What Are You"
variable that contains the WHATAMI information most recently received from
the other Kermit.  This variable is initialized to zero at the beginning of
each protocol transaction.

When a Kermit program receives an initialization string containing a WHATAMI
field, it saves the value of this string in its "What Are You" variable.
Since Bit 5 of a valid WHATAMI field is always set, this distinguishes the
initial value of zero from any legitimate WHATAMI value.

Now, when a Kermit server receives a GET (R) packet, it checks its What Are
You variable, and if Bit 5 is set, then it sets its global file transfer mode
and name conversion according to bits 1 and 2, respectively.  Note that these
global modes can still be overridden on a per-file basis in the normal way;
the server will always respond to REMOTE commands in text mode, no matter what
its global transfer mode; a VMS C-Kermit server will always determine a file's
transfer mode based on its RMS characteristics, etc.

That's about it.  When the client gives SEND or MSEND commands, everything
behaves well already, and WHATAMI won't change that.  Ditto for REMOTE
commands.  Other uses can be imagined for WHATAMI (besides as a condiment for
sushi) but they are only frills -- detecting mode mismatches and issuing more
intelligent error messages, etc.  Nothing earthshaking.

Finally, here is a sample dialog between two Kermits who have the WHATAMI
feature.  The remote Kermit starts out in server mode and in text mode, the
local Kermit client is in binary mode, seen from the client's point of view:

  s-^A5 I~* @-#Y3~^$5$0___FO    F = Names converted, binary mode, client
  r-^A5 Y~* @-#Y3~^$5$0___E^    E = Names converted, text mode, server
  s-^A& Rx.xX                   Client says "get x.x"
  r-^A5 S~* @-#Y3~^$5$0___GZ    G = Names converted, binary mode, server
  s-^A5 Y~* @-#Y3~^$5$0___F_    F = Names converted, binary mode, client
  r-^A(!FX.X+ /
  s-^A(!Yx.x.-N
  r-^AG"A."U1""B8#119940608 21:02:22!!11"98,1/   <--  Note "B8".
  s-^A%"Y.5!

etc etc.

(End of WHATAMI DRAFT 1)