12-Sep-88 16:02:20-GMT,6920;000000000001 Received: by cunixc.cc.columbia.edu (5.54/5.10) id AA28860; Mon, 12 Sep 88 12:02:16 EDT Date: Mon, 12 Sep 1988 12:02:15 EDT From: Christine M Gianone To: Frank da Cruz Subject: [Frank da Cruz : Messages in ACKs, etc. ] Message-Id: ... --------------- Received: by cunixc.cc.columbia.edu (5.54/5.10) id AA02888; Thu, 8 Sep 88 21:56:36 EDT Date: Thu, 8 Sep 1988 21:56:34 EDT From: Frank da Cruz To: Joe Doupnik Cc: Christine M Gianone , RAF@NIHCU.BITNET, TUB@NIHCU.BITNET, WJS@NIHCU.BITNET Subject: Messages in ACKs, etc. Message-Id: Just got back from vacation a couple days ago, and have been looking at your messages about putting text in ACK data fields. I think this could be added to the Kermit protocol pretty easily. This discussion can only apply to ACKs in reply to Data packets. ACKs to S, I, or A packets have special data, and ACKs to F or X packets may contain free-form text, normally a filename or heading. ACKs to Data packets may contain an X or a Z to request the sender to quit sending the current file, or the entire group. Currently, any data other than X or Z as the first character in the ACK to a Data packet is ignored. Therefore, as you've pointed out, adding a new protocol character in this position would not affect existing Kermits. So let's make the character M for Message, and any following text may be displayed, or stored in a message box for later perusal, or put into the transaction log, or any combination of these. As Joe points out, the text should be encoded -- that's the rule for all packets except S, I, and A packets and the ACKs to these packets. About the message length... The file sender tells the receiver the maximum length packet it's prepared to receive, so that should also be the limit (allowing for control fields) on the length of the ACK message. The same deal as for E packets, which can also go from receiver to sender. Joe thinks messages shouldn't be longer than 40 characters, but that's due to a peculiarity in MS-DOS Kermit's file transfer screen display, and we shouldn't hold the world to that. A good project for somebody (other than Joe, who has more important things to worry about!) would be to reorganize this display into separate windows, scrolling regions for debug display, messages, warnings, etc. Of course the problem here is that you lose portability to non-IBM-compatible machines. E packets are always guaranteed to contain a "complete" message, in the sense that it's the last packet you'll ever get. Therefore, the data field contains only the text of the error message. But now we're allowing for the possibility of longer, "continued" messages, so should these contain formatting characters, like CR and LF? This would allow multiline messages, even paragraphs to be sent down the "reverse channel". If so, then a short one-liner should be terminated with CRLF, which seems wasteful and is inconsistent with E-packet format. We could also stipulate that CRLF should separate lines, but need not terminate the last one... If we carry this idea one step further, we could even have bidirectional file transfer. A fairly useless feature, but one which certain commercial packages love to brag about. Actually it's useful in certain situations, like in UUCP or FIDO networks, where computers call each other up late at night and exchange a day's worth of queued up mail. This is a really silly idea, but it's worth thinking about for a minute... If we somehow specify that we're transferring files in both directions at once, how could this work? Well, the Send-Init exchange is symmetrical and does all we want -- both sides tell each other their parameters and features. With the F-packet and its ACK, each side tells the other the name of the file that is coming (this is obviously different from the current meaning of a filename in the F-packet ACK). And during the data transfer phase, the file receiver sends its file back in ACK packets with, say, a "D" as the first character. The ACKs to the Z and B packets would act just like the Z and B packets themselves. Pretty screwy, huh? What about problems? How would the "sender" be able to "NAK" bad data from the "receiver"? No problem, the same way as now. Just resend its previous packet. The only real headache comes from the fact that the files will not be the same size, and therefore one side finishes sending before the other. What if the sender has the bigger file? Then the receiver runs out of data to send in its ACKs. So big deal, it just sends empty ACKs, and no harm is done. But what if the receiver has the bigger file? When the sender has sent its final data packet, it checks whether the acknowledgment has any data in it. If so, it keeps sending empty data packets until it gets an empty ACK (by empty I mean a non-D ACK), bumping the packet number each time to indicate acknowledgement, or failing to bump it if bad data arrived. Upon receiving the empty ACK, the sender would send its Z packet. If the sender had more files to send than the receiver, again, no problem. If the receiver has more files than the sender... too bad, maybe it should have been the sender after all. Other problems include Attribute packets (the exchange is not symmetrical), how to handle file cancellation, etc... I don't know how I got off on this tangent... Joe, this sounds like a good project for one of your students! Now back to reality. Are we agreed on the ACK message business? I like "M" rather than blank for the message indicator, because it looks more like a real protocol item, and allows for other extensions, like the aforementioned "D". Also, maybe it should be stated formally somewhere (like in the next edition of the book?) that the ACK to the F packet may be used to return the name under which the file will be stored. And shall we allow for imbedded CRLFs in ACK-messages, but not require a CRLF at the end? By the way, another reason for using "M" is that someone in the UK (Chris Kennington) once inveigled me into agreeing that there should also be allowance for messages in the SAME direction as the data (we also agreed that ACKs could be used in the reverse direction). After some discussion, we concluded that a separate packet type was necessary, and called it "M". M-packets can be interleaved with data packets. But, of course, since this is a new packet type, its use must be negotiated, and capability bit #6 (which overflows into the second capability byte) was assigned for this. Another item for the second edition... This was fun, haven't invented new Kermit stuff for a long time! - Frank