Columbia Kermit/kermit.zip/protocol/ackmsg.txt

Text File | 2020-01-01 | 6KB | 100 lines

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?  Well, the
sender finishes with its file and sends a Z packet, but the receiver still has
lots more data to send, but can only send it in ACKs, which make the sender
(who just sent a Z packet) think that the receiver is finished sending too...
But if the ACK to the Z packet had data in it, then the sender, instead of
sending the B packet or the next F packet, could (and this requires a "minor
change" to the protocol) keep on sending Z packets (bumping the packet number
each time to indicate acknowledgement, or failing to bump it if bad data
arrived) until an ACK arrived with no data, and then the sender would send its
B or F packet, and the whole process would terminate (or repeat).

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.

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.  After some
discussion, I agreed that a separate packet type was necessary, and called it
"M".  M-packets can be interleaved with data packets.  But, of course, since
it's 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...

- Frank