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 To: Joe Doupnik Subject: Idea Message-Id: 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 ); Mon, 6 Jun 1994 10:29:01 -0400 Received: from cc.usu.edu by cc.usu.edu (PMDF V4.2-13 #4757) id <01HD7RGKJKS0BWFK3U@cc.usu.edu>; Mon, 6 Jun 1994 08:28:48 MDT Date: Mon, 06 Jun 1994 08:28:48 -0600 (MDT) From: Joe Doupnik Subject: Re: Idea To: fdc@watsun.cc.columbia.edu Message-Id: <01HD7RGKJRDEBWFK3U@cc.usu.edu> X-Vms-To: IN%"fdc@watsun.cc.columbia.edu" 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 To: Joe Doupnik Subject: Re: Idea In-Reply-To: Your message of Mon, 06 Jun 1994 08:28:48 -0600 (MDT) Message-Id: > 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 ); Mon, 6 Jun 1994 20:28:53 -0400 Date: Mon, 6 Jun 94 20:28:53 EDT From: Frank da Cruz To: Joe Doupnik Subject: WHATAMI Message-Id: (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 ); Mon, 6 Jun 1994 20:42:35 -0400 Received: from cc.usu.edu by cc.usu.edu (PMDF V4.2-13 #4757) id <01HD8CVGFI80C1BN8J@cc.usu.edu>; Mon, 6 Jun 1994 18:42:18 MDT Date: Mon, 06 Jun 1994 18:42:18 -0600 (MDT) From: Joe Doupnik Subject: Re: WHATAMI To: fdc@watsun.cc.columbia.edu Message-Id: <01HD8CVGFJ6AC1BN8J@cc.usu.edu> X-Vms-To: IN%"fdc@watsun.cc.columbia.edu" 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 To: Joe Doupnik Subject: Re: WHATAMI In-Reply-To: Your message of Mon, 06 Jun 1994 18:42:18 -0600 (MDT) Message-Id: > 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 ); Tue, 7 Jun 1994 10:12:09 -0400 Date: Tue, 7 Jun 94 10:12:08 EDT From: Frank da Cruz To: Joe Doupnik Subject: Re: WHATAMI In-Reply-To: Your message of Mon, 06 Jun 1994 18:42:18 -0600 (MDT) Message-Id: > ... 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 To: Joe Doupnik Subject: WHATAMI Message-Id: 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)