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

Text File | 2020-01-01 | 14KB | 309 lines

12-Sep-97  5:53:41-GMT,3305;000000000011
Return-Path: <[e-mail]>
Received: from CUVMB.CC.COLUMBIA.EDU (cuvmb.cc.columbia.edu [128.59.40.129])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with SMTP id BAA15800
    for <[e-mail]>; Fri, 12 Sep 1997 01:53:40 -0400 (EDT)
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP V2R1)
   with BSMTP id 3818; Fri, 12 Sep 97 01:53:43 EDT
Received: from CUVMB.CC.COLUMBIA.EDU (JCHBN) by CUVMB.CC.COLUMBIA.EDU (Mailer
 R2.07) with BSMTP id 8970; Fri, 12 Sep 97 01:53:43 EDT
Date: Thu, 11 Sep 1997   23:06 EDT
From: "John F. Chandler"   <[e-mail]>
To: Frank da Cruz   <[e-mail]>,
        Joe Doupnik   <[e-mail]>
Subject: Re: Some new Kermit protocol tweaks
In-reply-to: [e-mail] message
   <[e-mail]> of Thu, 11 Sep 97 20:59:18
   EDT
Message-id: <[e-mail]>

> You probably already take care of all this in K370, but due to a recent
> "situation", I finally also do so in C-Kermit, and Joe does in MSK:

Only in part.  In practice, really short packet limits are not realistic
for sending from a mainframe, since the transfer goes over the same
channel that the system uses for ordinary output to the terminal.
Nonetheless...

> 4.8.1. Multiple Attribute Packets

I implemented this long ago, since the potential for really long bunches
of attribute info was implied by the wide variety of available
attributes.

> particular attribute (such as file creation date-time) does not fit within the
> negotiated length, it is not sent at all.

This is a possibility that I considered, but handled differently -- I
took the view that the attribute couldn't be skipped and so sent it
despite its length.  After all, quietly suppressing part of a transfer
is the most insidious thing I can imagine.  In the context of a 30-byte
limit (as mentioned later), there aren't any attributes that wouldn't
fit.  The time tag is only 17 plus packet overhead.  Are you serious
about the possibility of a 20-byte limit?

>  1. Parameter negotiation packets (I, S, and their ACKs) are truncated to
>     the negotiated length.

Wait a minute.  At the time of the I and S packets, the negotiation has
not yet begun.  The packet length is technically undefined (except in
K370 the user can manually set the limit pending the first negotation).
hmmmm.

>  2. File header packets (containing the filename) are simply truncated.
>     There is no provision in the Kermit protocol for fragmentation and
>     reassembly of filenames.

Surprisingly enough, this was implemented long ago.

>  4. Data packets and other packets are unaffected -- they can be as short
>     as they need to be, within reason.

That's the key -- "within reason".  You need room for at least three
data bytes in every packet (or five if repeat-counting is turned on).

> P.S. Any progress on K-370 4.3.2?  The Year-2000 Hordes are beating down
> the door...

Well, there's this problem that a tester has run into...  I'm hoping it
was just a faulty installation, but the symptoms are pretty serious.
Everything is ready to go, in principle, but I'd like to get this laid
to rest before making the release official.

                                               John

12-Sep-97  0:59:20-GMT,2343;000000000001
Return-Path: <fdc>
Received: (from fdc@localhost)
    by watsun.cc.columbia.edu (8.8.5/8.8.5) id UAA02245;
    Thu, 11 Sep 1997 20:59:18 -0400 (EDT)
Date: Thu, 11 Sep 97 20:59:18 EDT
From: Frank da Cruz <[e-mail]>
To: John Chandler <[e-mail]>
Subject: Some new Kermit protocol tweaks
Cc: Joe Doupnik <[e-mail]>
Message-ID: <[e-mail]>

You probably already take care of all this in K370, but due to a recent
"situation", I finally also do so in C-Kermit, and Joe does in MSK:

4.8.1. Multiple Attribute Packets

6.0.193 will now send more than one Attribute packet if a file's attributes
do not fit into into a single packet of the negotiated length.  If a
particular attribute (such as file creation date-time) does not fit within the
negotiated length, it is not sent at all.

4.8.2. Very Short Packets

There are certain situations where extremely short packets must be used;
20 or 30 bytes at most.  This can happen when one or more devices along the
communication path have very small buffers and lack an effective means of
flow control.  Examples are sometimes cited involving radio modems.

When the maximum packet length is shorter than certain packets that would be
sent, those packets are either truncated or else broken up into multiple
packets.  Specifically:

 1. Parameter negotiation packets (I, S, and their ACKs) are truncated to
    the negotiated length.  Any parameters that do not fit are reset to
    their default values.  There is no provision in the Kermit protocol for
    fragmentation and reassembly of parameter strings.

 2. File header packets (containing the filename) are simply truncated.
    There is no provision in the Kermit protocol for fragmentation and
    reassembly of filenames.

 3. Attribute packets are fragmented and reassembled as described in 4.8.1
    without loss of data, except in case a field will not fit at all in
    the negotiated length (the longest attribute is usually the date and
    time of file creation/modification) because of the rule that attributes
    may not be broken across packets.

 4. Data packets and other packets are unaffected -- they can be as short
    as they need to be, within reason.

- Frank

P.S. Any progress on K-370 4.3.2?  The Year-2000 Hordes are beating down
the door...

12-Sep-97  5:53:41-GMT,3305;000000000011
Return-Path: <[e-mail]>
Received: from CUVMB.CC.COLUMBIA.EDU (cuvmb.cc.columbia.edu [128.59.40.129])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with SMTP id BAA15800
    for <[e-mail]>; Fri, 12 Sep 1997 01:53:40 -0400 (EDT)
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP V2R1)
   with BSMTP id 3818; Fri, 12 Sep 97 01:53:43 EDT
Received: from CUVMB.CC.COLUMBIA.EDU (JCHBN) by CUVMB.CC.COLUMBIA.EDU (Mailer
 R2.07) with BSMTP id 8970; Fri, 12 Sep 97 01:53:43 EDT
Date: Thu, 11 Sep 1997   23:06 EDT
From: "John F. Chandler"   <[e-mail]>
To: Frank da Cruz   <[e-mail]>,
        Joe Doupnik   <[e-mail]>
Subject: Re: Some new Kermit protocol tweaks
In-reply-to: [e-mail] message
   <[e-mail]> of Thu, 11 Sep 97 20:59:18
   EDT
Message-id: <[e-mail]>

> You probably already take care of all this in K370, but due to a recent
> "situation", I finally also do so in C-Kermit, and Joe does in MSK:

Only in part.  In practice, really short packet limits are not realistic
for sending from a mainframe, since the transfer goes over the same
channel that the system uses for ordinary output to the terminal.
Nonetheless...

> 4.8.1. Multiple Attribute Packets

I implemented this long ago, since the potential for really long bunches
of attribute info was implied by the wide variety of available
attributes.

> particular attribute (such as file creation date-time) does not fit within the
> negotiated length, it is not sent at all.

This is a possibility that I considered, but handled differently -- I
took the view that the attribute couldn't be skipped and so sent it
despite its length.  After all, quietly suppressing part of a transfer
is the most insidious thing I can imagine.  In the context of a 30-byte
limit (as mentioned later), there aren't any attributes that wouldn't
fit.  The time tag is only 17 plus packet overhead.  Are you serious
about the possibility of a 20-byte limit?

>  1. Parameter negotiation packets (I, S, and their ACKs) are truncated to
>     the negotiated length.

Wait a minute.  At the time of the I and S packets, the negotiation has
not yet begun.  The packet length is technically undefined (except in
K370 the user can manually set the limit pending the first negotation).
hmmmm.

>  2. File header packets (containing the filename) are simply truncated.
>     There is no provision in the Kermit protocol for fragmentation and
>     reassembly of filenames.

Surprisingly enough, this was implemented long ago.

>  4. Data packets and other packets are unaffected -- they can be as short
>     as they need to be, within reason.

That's the key -- "within reason".  You need room for at least three
data bytes in every packet (or five if repeat-counting is turned on).

> P.S. Any progress on K-370 4.3.2?  The Year-2000 Hordes are beating down
> the door...

Well, there's this problem that a tester has run into...  I'm hoping it
was just a faulty installation, but the symptoms are pretty serious.
Everything is ready to go, in principle, but I'd like to get this laid
to rest before making the release official.

                                               John

12-Sep-97 13:28:04-GMT,2776;000000000000
Return-Path: <fdc>
Received: (from fdc@localhost)
    by watsun.cc.columbia.edu (8.8.5/8.8.5) id JAA18834;
    Fri, 12 Sep 1997 09:28:02 -0400 (EDT)
Date: Fri, 12 Sep 97 9:28:02 EDT
From: Frank da Cruz <[e-mail]>
To: "John F. Chandler" <[e-mail]>
Cc: Joe Doupnik <[e-mail]>
Subject: Re: Some new Kermit protocol tweaks
In-Reply-To: Your message of Thu, 11 Sep 1997 23:06 EDT
Message-ID: <[e-mail]>

> > particular attribute (such as file creation date-time) does not fit within
> > the negotiated length, it is not sent at all.
>
> This is a possibility that I considered, but handled differently -- I
> took the view that the attribute couldn't be skipped and so sent it
> despite its length.  After all, quietly suppressing part of a transfer
> is the most insidious thing I can imagine.  In the context of a 30-byte
> limit (as mentioned later), there aren't any attributes that wouldn't
> fit.  The time tag is only 17 plus packet overhead.  Are you serious
> about the possibility of a 20-byte limit?
>
Not exactly, but there is obviously *some* lower bound beyond which things
just won't work.  The idea, however, is that if a limit is declared, then
this was done for a reason, and exceeding the limit is likely to be more
disastrous (e.g. chopping off the end of the packet so it can never be read,
causing the transfer to fail) than omitting some attribute info.

> >  1. Parameter negotiation packets (I, S, and their ACKs) are truncated to
> >     the negotiated length.
>
> Wait a minute.  At the time of the I and S packets, the negotiation has
> not yet begun.  The packet length is technically undefined (except in
> K370 the user can manually set the limit pending the first negotation).
> hmmmm.
>
That's what I meant -- "set send packet-length 12" and the "send".  Not a
big deal since it won't come up more than once every 10 years...

> >  4. Data packets and other packets are unaffected -- they can be as short
> >     as they need to be, within reason.
>
> That's the key -- "within reason".  You need room for at least three
> data bytes in every packet (or five if repeat-counting is turned on).
>
I'll worry about that if it ever comes up :-)

> > P.S. Any progress on K-370 4.3.2?  The Year-2000 Hordes are beating down
> > the door...
>
> Well, there's this problem that a tester has run into...  I'm hoping it
> was just a faulty installation, but the symptoms are pretty serious.
> Everything is ready to go, in principle, but I'd like to get this laid
> to rest before making the release official.
>
OK, great -- quality comes first :-)  Anyway, it's gratifying to know there
are still some mainframes left.  And they don't even run Windows!

Thanks.

- Frank

12-Sep-97 18:28:27-GMT,2139;000000000001
Return-Path: <[e-mail]>
Received: from CUVMB.CC.COLUMBIA.EDU (cuvmb.cc.columbia.edu [128.59.40.129])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with SMTP id OAA10545
    for <[e-mail]>; Fri, 12 Sep 1997 14:28:27 -0400 (EDT)
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP V2R1)
   with BSMTP id 4245; Fri, 12 Sep 97 14:28:29 EDT
Received: from CUVMB.CC.COLUMBIA.EDU (JCHBN) by CUVMB.CC.COLUMBIA.EDU (Mailer
 R2.07) with BSMTP id 9933; Fri, 12 Sep 97 14:28:29 EDT
Date: Fri, 12 Sep 1997   14:13 EDT
From: "John F. Chandler"   <[e-mail]>
To: Frank da Cruz   <[e-mail]>,
        Joe Doupnik   <[e-mail]>
Subject: Re: Some new Kermit protocol tweaks
In-reply-to: [e-mail] message
   <[e-mail]> of Fri, 12 Sep 97 9:28:02
   EDT
Message-id: <[e-mail]>

>  The idea, however, is that if a limit is declared, then
> this was done for a reason, and exceeding the limit is likely to be more
> disastrous (e.g. chopping off the end of the packet so it can never be read,
> causing the transfer to fail) than omitting some attribute info.

I have only the philosophical objection that suppressing part of the
expected transfer process without warning or even subsequent diagnostic
is a particularly bad procedure.  Consider the process for determining
what packet limit to use: the sensible and obvious thing to do is to
try a size and then halve it if that didn't work, so a likely scenario
would be 94 (too big), 47 (too big), 23 (worked, sort of).  In other
words, I would argue that the particular length specified might well
*not* be for a particular reason.  After all, there is a mechanism for
suppressing the time stamp.  (Of course, I have to admit that it would
be very tricky explaining why the user must enter SET ATTRI DATE OFF
in order to get transfers to work in the case of a real limit at 20.)
Oh, well.  I guess this is such a rare scenario that it doesn't pay to
worry too much about it...

                                       John