Columbia Kermit/kermit.zip/protocol/message-packets.txt

Text File | 2020-01-01 | 7KB | 123 lines

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 <[e-mail]>
To: Frank da Cruz <[e-mail]>
Subject: [Frank da Cruz <[e-mail]> : Messages in ACKs, etc.
        ]
Message-Id: <[e-mail]>

...
                ---------------

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 <[e-mail]>
To: Joe Doupnik <[e-mail]>
Cc: Christine M Gianone <[e-mail]>, [e-mail],
        [e-mail], [e-mail]
Subject: Messages in ACKs, etc.
Message-Id: <[e-mail]>

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