info-kermit@ucbvax.ARPA (08/11/85)
From: Jeff Damens <US.JD@CU20B.ARPA> Info-Kermit Digest Fri, 09 Aug 1985 Volume 3 : Number 13 Departments: ANNOUNCEMENTS - Kermit directories/files have moved KERMIT ENHANCEMENTS DISCUSSION - Sliding windows on micros should work ANY-duplex Windows Half-duplex windowing and large packets UNIX KERMIT - CKermit Statistics MS-DOS KERMIT - Warning: Unrecognized Baud Rate MISCELLANY - How do you edit pc-ix sources? RT-11/TSX+ Kermit Wanted: Kermit for the Burroughs B-20s,B-25s,B-26s running BTOS. ---------------------------------------------------------------------- Date: Sat 3 Aug 85 09:02:08-PDT From: Douglas Edwards <EDWARDS@SU-CSLI.ARPA> Subject: "Warning: Unrecognized Baud Rate" I use MS-DOS Kermit for the IBM PC (actually I have a Compaq, but they seem interchangeable). I have one minor problem. When I start up Kermit I always get the message "?Warning: Unrecognized Baud Rate" even though my init file clearly specifies 1200 bps. (It works fine--the message seems to have no significance, it's just annoying.) What causes this? Douglas Edwards (edwards@su-csli) [Ed. - When it starts up, MS-DOS Kermit looks at the baud rate the serial port is set to and tries to identify it (so that the status command will print the correct value if the baud rate isn't explicitly set). If it can't figure out the baud rate, the message is printed. This has nothing to do with what's in your init file - it is printed even before the init file is read. The message won't affect anything else; it should probably be removed. ] ------------------------------ Date: Sun, 4 Aug 85 15:08:17 pdt From: "Corwin Nichols; Community Data Processing; 415-322-9069" <cdp!corwin@Glacier> Subject: sliding windows on micros should work In a July 27 note, B.Eiben writes: >As is probably known, none of our current 'Van Neuman' machines can handle >more than one task at any given instant of time. The illusion of >'time-sharing' and 'multi-tasking' or even 'multi-processing' are only >possible with the existence of a sophisticated interrupt-structure >[typically combined with 'hardware assisted' context-switching] and software >delivering the book-keeping services. >The currently most 'popular' micro-systems [CP/M and MSDOS or derivatives] >are SINGLE-tasking systems. Although the used micro-processors typically >support a basic interrupt-structure, the lack of buffered and hardware >assisted I/O devices limits the interrupt-structure basically to ERROR >intercepts and clock-service. -- Or in laymans terms, "A typical micro >CANNOT accept characters on the Input-port, as long as its reading or >writing to the floppy". It is true that the current crop of popular micros run MSDOS, CP/M, or AppleDos, and that these are singletasking operating systems. However it is NOT necessary to have a "sophisticated interrupt-structure" or fancy hardware in order to process a single stream of incoming characters while performing other tasks such as monitoring the incoming stream, calculating checksums, transmitting ACKs, etc. All that is required is a simple interrupt routine which captures the incoming stream in a buffer, and which is enabled throughout disk i/o operations. All machines which claim to be close to IBM PC compatibility meet this simple criteria. Many CP/M machines also meet these requirements, ei Radio Shack models 2, 4, 12, and 16; all Compupros, Altos's, Cromemcos and any other machine which uses a dma chip for disk i/o and has a serial chip that is on an interrupt line. Since most of the CP/M and MSDOS implementations are already machine dependent, I don't foresee any major problems implementing the sliding window code on most of the popular micros. ------------------------------ Date: Fri, 2 Aug 85 20:18:22 pdt From: hpl-opus!poulton%hplabs.csnet@csnet-relay.arpa hplabs!cc.fdc@cu20b.ARPA, hplabs!oc.source@cu20b.ARPA Subject: ANY-duplex Windows I agree with Leslie et al, that they have a viable, apparently well thought-out proposal for full-duplex sliding windows. Where we differ is in whether half-duplex windows belong to Sliding Windows or to Long Packets. They argue that the various half-duplex proposals all filter down to long, segmented packets. At the link level (what passes down the wires, and how to synchronize it) this is true. But NOT AT THE PACKET LEVEL, where most of the programming is involved. The major part of the implementation of full-duplex windows is in the handling of a window of "active" packets (except when the opsys doesn't support multi-processing). At the packet level, the handling of half-duplex windows is nearly the same, as Leslie agrees: 1. Ken Poulton's suggestion of a way to do "super-packet" half-duplex (message dated July 27). This is a effectively a super-packet with segmentation. ******************************************** ************* Hugh agrees with Ken Poulton that the coding on this suggestion would parallel well with the full-duplex coding. *********************************************************** PROPOSAL: Have the full-duplex windows allow for half-duplex operation. All implementations with full-duplex windows should be able to run in half-duplex mode also, so that we don't end up with two (probably incompatible) versions of windows/long-packets running around. I don't think this requires adding much to a full-duplex window scheme. To repeat from my earlier proposal: All the full-duplex version needs to do is: 1) negotiate half-duplex status and super-packet size along with window size 2) bunch outgoing packets together (without end-of-lines) to form a super-packet 3) wait for the replying super-packet before sending the next. My immediate concern is with point (1): unless this negotiation is added to the full-duplex windows NOW, it never will. But once that part is defined, the implementation is easy. In fact, it might be a positive benefit for future full-duplex implementations: one could bring up half-duplex windows first to debug the window algorithm and worry about the low-level interrupt/process handling stuff later. (Half-duplex windows have got to be easier to debug than full-duplex...) Adding a half-duplex option to sliding windows also makes them more portable: half-duplex windows might still work across operating system revs or different hardware (e.g., PC-almost-clones) when a full-duplex implementation (that munged the interrupt vector, or whatever) broke. To argue by the numbers: 1) half-duplex windows are a SIMPLE extension of the proposed full-duplex window proposal 2) half-duplex windows ADD portability and robustness, even for full-duplex machines 3) The only critical need *right now* is to *define* the bits and bytes for negotiating half-duplex windows and add that part of the negotiation to the full-duplex window specification. In the interests of allowing Leslie, et al to move along, implementation can wait. If full-duplex windows go ahead without a half-duplex provision, it seems likely that we will eventually agree to a separate segmented long packet proposal, which may go the way of File Attribute Packets. (Almost no one has implemented these because there is almost no one else to exchange them with.) Momentum is key here! Leslie & co have made a large contribution here, and I thank them for that. I agree that this window proposal is indeed a critical moment for Kermit. We *all* benefit by making it useful to more machines. After all, isn't that what Kermit is all about? Ken Poulton hplabs!poulton ------------------------------ Date: Wed 7 Aug 85 03:20:06-EDT From: Ken Rossman <sy.Ken@CU20B.ARPA> Subject: Kermit directories/files have moved Due to space shortages on our PS structure, all Kermit directories and files have been moved to the PX/PB structure. All system-wide logical names have been correspondingly redirected, so if you use the system-wide logicals for all file references, you should not notice any difference. Mail questions and/or problems to info-kermit@CU20B. ------------------------------ Date: 7 Aug 85 18:11:49 EDT From: BL02@CMU-CC-TC Subject: how do you edit pc-ix sources? Help! I have a pc-xt running pc-ix. I can't live with INed (the editor) anymore. Since ckermit is a rather large program, and it has been made to run under pc-ix, I gather someone out there has a nice editor that runs under same. Can someone give me a pointer to where I can get one? I really am looking for an emacs clone (thief, fine, jove, etc.) or even real emacs, etc., etc., etc. I do have some sources to thief and jove, but not for pc-ix, and I just don't have the time right now to fix them up. Can anyone help me?? or am I just stuck with INed? Thanks SO MUCH for any replies or comments. Bryan Lally bl02@cmcctc ------------------------------ Date: Tue, 6 Aug 85 11:59:46 PDT From: Bruce_A._Cowan%SFU.Mailnet@MIT-MULTICS.ARPA Info-Kermit@CU20B.ARPA Subject: Half-duplex windowing and large packets I'd like to make a proposal which essentially adds some details to Ken Poulton's proposal for half-duplex sliding windows with super-packets (Info-Kermit #11). Extend the protocol to negotiate both the maximum window size and the super-packet size, using the byte following the window size for the super-packet size. Now, if the super-packet size is 0 or 1 (treat 0 as equivalent to 1), then we have full-duplex windowing as in the Source's proposal. If the super-packet size is the same as the window size, then we have half-duplex windowing. If somewhere in between, then we have full-duplex windowing using super-packets. Note that if window size is super-packet size times 2, then although we strictly have full-duplex windowing, we can consider it to be half-duplex with type-ahead. I believe that will work on a few half-duplex systems. It will certainly work on my MTS system. In this proposal the window size in terms of number of super-packets outstanding at once is (window size)/(super-packet size). Keep the rule in the original windowing proposal that explicit ACKs and NAKs are required for each packet. Note that implicit ACKing must be disabled if the environment is full-duplex, because you really don't know if the missing packet is an ACK or a NAK (you could change it to implicit NAKing). The other rule that differs between half- and full-duplex environments is that in a half-duplex environment one should do something with a packet with a bad checksum - sender treats it as a NAK and receiver sends a NAK. That prevents having to wait for a timeout every time a packet gets mangled. As the windowing proposal correctly states, in a full-duplex envorinment one must simply ignore packets with a bad checksum. That is because one cannot guess the correct packet number as one can in the half-duplex environment. I'd also like to propose one more extension to save money on public data networks. Many of those networks charge by the packet and packet sizes are typically up to 128 or 256 bytes. I'd like to extend the packet length field to 2 bytes when the first length byte (decoded) is 1 or 2. That will allow packet sizes from the current minimum up to 284 with no loss of efficiency on short packets. It will allow a super-packet of 26696 (284*94) bytes which seems more than long enough. Two more bytes are needed in the Init packet to negotiate the maximum packet size just as in the original long packet proposal. Note that I haven't used packet size 0 so this doesn't conflict with the large packet proposal. However, I'd like to see this proposal supercede that one because it is superior in several respects. It allows ACKing and NAKing parts of large packets and it fits in with the windowing proposal. Now, this idea complicates the negotiation process a bit, because if one side wants to be half-duplex and the other side doesn't care, the negotiation must be sure to end up in a half-duplex state. I believe the following rules will work: 1. Use the minimum value of window size (or smaller, see 3). 2. Be half-duplex (super-packet size equal to window size) if either side requests that. 3. Make super-packet size divide (no remainder) window size and make super- packet size be such that the resulting quotient is the minimum of the two quotients requested, by adjusting the window size downward if necessary. The biggest drawback to this proposal is that it doesn't allow very large packets when one really wants a window size of 31 (since in that case one cannot use super-packets). Nonetheless, the 284 byte maximum packet size in that case seems sufficient. I'm a bit out of touch for the next week and have been for a few days so this proposal may not take into account everything it should and I won't be able to respond until next week. ------------------------------ Date: Mon, 5 Aug 85 14:19:56 pdt From: seismo!decvax!ucbvax!ucdavis!deneb!ccrms@columbia.arpa (Michael Shulman) Subject: RT-11/TSX+ Kermit We understand that there is a version of Kermit available for the TSX+ system. It is far easier for us to obtain a copy of this system on 8" disk than it would be to bootstrap it ourselves. Are there any sites that have such a system running and would be willing to make us a copy on 8" disk? Thank you, Michael Shulman Computer Center UCDavis ... ucbvax!ucdavis!deneb!ccrms ------------------------------ Date: Thu, 8 Aug 85 03:29:24 pdt From: Neal Holtz <holtz%cascade.carleton.cdn%ubc.csnet@csnet-relay.arpa> Subject: CKermit Statistics A statistic regarding performance of C-Kermit: source: Vax 11/750 4.2 BSD dest: Apollo DN320, Aegis SR8 line: 9600 baud type: text # files: 53 # chars: 684206 time: 29 min. (+/- 1 min.) effective rate: 393 chars/sec Notes: 1) Apollo versions: C-Kermit 4.2(030) PRERELEASE # 2, 5 March 85 C-Kermit Protocol Module 4.2(015), 5 Mar 85 C-Kermit functions, 4.2(026) 5 Mar 85 Unix cmd package V1.0(015) 27 Feb 85 User Interface V4.2(038), 5 Mar 85 Apollo Aegis tty I/O, 4C(023), 20 May 85 for Apollo Aegis SR8 Aegis file support, 4C(024) 20 May 85 for Apollo Aegis SR8 Connect Command for Unix, V4.2(006) 5 March 85 2) Vax versions: C-Kermit 4.2(030) PRERELEASE # 2, 5 March 85 C-Kermit Protocol Module 4.2(015), 5 Mar 85 C-Kermit functions, 4.2(026) 5 Mar 85 Unix cmd package V1.0(015) 27 Feb 85 User Interface V4.2(038), 5 Mar 85 Unix tty I/O, 4.2(016), 5 Mar 85 for 4.2 BSD Unix file support, 4.1(015) 28 Feb 85 for 4.x BSD Connect Command for Unix, V4.2(006) 5 March 85 3) All compiler optimizing turned off on Apollo 4) Used about 25% of CPU on Vax 5) Used about 70% of CPU on Apollo ------------------------------ Date: Fri, 9 Aug 85 9:46:06 EDT From: David Roth (Ft. Benj. Harrison) <droth@BRL.ARPA> Subject: Wanted: Kermit for the Burroughs B-20s,B-25s,B-26s running BTOS. This Sept.15 we are expecting shipment to arrive of dozens of Burroughs B-20s, B-25s & B-26s. The operating system they run is called BTOS. We are in need of a version of KERMIT for these systems. Anyone have a version or enough experience in using BTOS to suggest what existing version of KERMIT we should start with. The Army refers to these systems as: TACCS. Thanks in advance. David A. Roth droth@brl-bmd US Mail: COMMANDER USA Soldier Support Center ATSG-DTU-S Attn: Mr. David A. Roth Fort Benjamin Harrison, IN 46216-5590 AUTOVON:699-4298 FTS:335-4298 COMMERCIAL:(317) 542-4298 ------------------------------ End of Info-Kermit Digest ************************* -------