Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!helios.physics.utoronto.ca!alchemy.chem.utoronto.ca!mroussel From: mroussel@alchemy.chem.utoronto.ca (Marc Roussel) Newsgroups: comp.sys.cbm Subject: Re: Kermit Question Message-ID: <1991Apr7.205934.20408@alchemy.chem.utoronto.ca> Date: 7 Apr 91 20:59:34 GMT References: <1991Apr5.175215.23763@nntp-server.caltech.edu> <1991Apr5.201357.7658@noose.ecn.purdue.edu> <11571@jarthur.Claremont.EDU> Organization: Department of Chemistry, University of Toronto Lines: 26 In article <11571@jarthur.Claremont.EDU> nrossi@jarthur.Claremont.EDU (Nick Rossi) writes: >For standard Kermit, the maximum packet length is 94 bytes. Yes, there is >a lot of overhead in Kermit which makes it a very inefficient protocol (which >is why I dislike it so much). But it was designed to operate on ANY >computer environment, by forcing packets to consist of only printable >characters and such. I seem to recall using a Kermit program on an IBM which >was sending 1024 byte packets, but perhaps I was looking at the wrong thing >on the screen or something, as I haven't been able to reproduce it. I don't think that this is quite right. The packet length in Kermit is arbitrary. In fact, the initial handshake between the two computers includes packet length information. (Transmission is then undertaken at the largest packet length allowed by both Kermits. The "set send/receive packet length" commands merely tell Kermit how large a packet you wish to allow it to use. Why you'd ever want this to be less than the maximum, I don't know.) Kermit-65 can't handle packets any greater than 96 bytes (according to my manual). This maximum has to do with the amount of memory available for buffering I think. On the other hand, the latest versions of MS-Kermit and C-Kermit can handle packets up to 1Kbytes. I hope I got this right. (I'm relaying second-hand information here, not first-hand knowledge.) If I didn't, I hope someone will set me straight. Marc R. Roussel mroussel@alchemy.chem.utoronto.ca