12-Sep-97 5:53:41-GMT,3305;000000000011 Return-Path: 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 ; 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" To: Frank da Cruz , Joe Doupnik Subject: Re: Some new Kermit protocol tweaks In-reply-to: fdc@watsun.cc.columbia.edu message of Thu, 11 Sep 97 20:59:18 EDT Message-id: > 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: 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 To: John Chandler Subject: Some new Kermit protocol tweaks Cc: Joe Doupnik Message-ID: 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: 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 ; 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" To: Frank da Cruz , Joe Doupnik Subject: Re: Some new Kermit protocol tweaks In-reply-to: fdc@watsun.cc.columbia.edu message of Thu, 11 Sep 97 20:59:18 EDT Message-id: > 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: 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 To: "John F. Chandler" Cc: Joe Doupnik Subject: Re: Some new Kermit protocol tweaks In-Reply-To: Your message of Thu, 11 Sep 1997 23:06 EDT Message-ID: > > 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: 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 ; 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" To: Frank da Cruz , Joe Doupnik Subject: Re: Some new Kermit protocol tweaks In-reply-to: fdc@watsun.cc.columbia.edu message of Fri, 12 Sep 97 9:28:02 EDT Message-id: > 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