saroff@.tmc.edu (steven saroff) (12/26/89)
I am interested in learning about the various flavors of transfer programs for PC's etc. Dr. S.Z. Saroff o o Thinking Machines Corporation (_)_____o email: saroff@think.com ~~~~~~~~~~~~(_____)~~~~~~~~~~~~~~ 245 First St oo oo Cambridge, MA 02142 The Bear who Swims 617 876 1111 ext 2454 -- Dr. S.Z. Saroff o o Thinking Machines Corporation (_)_____o email: saroff@think.com ~~~~~~~~~~~~(_____)~~~~~~~~~~~~~~ 245 First St oo oo
don@delta.uucp (Donald K. Irmiger) (01/01/90)
In article <32428@news.Think.COM> saroff@.tmc.edu (steven saroff) writes: >I am interested in learning about the various flavors of transfer >programs for PC's etc. I've always had an affinity for ZMODEM. I'm using ProComm Plus (which does not directly support ZMODEM) doing file transfers to/from a Xenix box. Works great. I like the ability to resurrect an interrupted transfer, although I've yet to use it. Cheap too. Donald K. Irmiger III UUCP: uunet!delta!don Data Systems Coordinator Altos 2086/Xenix 3.4b Michiana Rehabilitation Institute's Data Systems Center
gordon@eecea.eece.ksu.edu (Dwight Gordon) (01/01/90)
In article <32428@news.Think.COM> saroff@.tmc.edu (steven saroff) writes: >I am interested in learning about the various flavors of transfer >programs for PC's etc. My program of choice depends on the environment. ZMODEM - 1. Fast! It gives me in excess of 10% greater throughput than KERMIT. (~230 cps on my 2400 baud modem) 2. Requires 8-bit datalinks (at least my version does). 3. Not as robust as KERMIT. a. noisy environments (bad phone connections) causes troubles b. multitasking (DesqView) a graphics (high cpu overhead) application in another window tends to cause retries/packet failures (yes, I know that there must be a way to tune the DesqView parameters so that this doesn't happen. I haven't found it!) 4. The ability to resume an aborted transfer is GREAT! 5. "Problem connections" (see 3) cause ZMODEM to decrease the packet size. This will (hopefully) increase reliability. However, it plays havoc with the throughput! (I've seen it drop to <100 cps on 2400 baud.) KERMIT 1. Not as fast as ZMODEM (with 1K packets it claims about 208 cps on my 2400 baud modem) 2. Works on both 7 and 8 bit connections. This sometimes causes problems with configuring KERMIT. Some of the UNIX systems I've used will happily configure KERMIT for 8-bit, where the tty is set for 7-bit. (Our campus mainframe, KSUVM, only works with 7-bit datalinks!) 3. ROBUST! It was designed to transfer information between dissimilar machines. I have seen it "give up" (see 3.b above). It does so less often than ZMODEM. 4. No direct support for aborted downloading. 5. Packet size is negotiated at the start of the transfer, and doesn't change. - Dwight - -- Dwight W. Gordon, Ph.D. | 913-532-5600 | gordon@eecea.eece.ksu.edu Electrical & Computer Engineering Department | dwgordon@ksuvm.bitnet Kansas State University - Durland Hall | rutgers!ksuvax1!eecea!gordon Manhattan, KS 66506 | {pyramid,ucsd}!ncr-sd!ncrwic!ksuvax1!eecea!gordon
amichiel@rodan.acs.syr.edu (Michielsen) (01/02/90)
In article <1989Dec31.210253.25273@delta.uucp> don@delta.UUCP (Donald K. Irmiger) writes: >In article <32428@news.Think.COM> saroff@.tmc.edu (steven saroff) writes: >>I am interested in learning about the various flavors of transfer >>programs for PC's etc. > >I've... Kermit, Is best because it's free. It works pretty well for transfers of files & the terminal emulation is pretty robust. However, it requires kermit running at both ends & setup compatible to do file transfers. X,Y,& Z Modem all are fairly much the same. They are only a method of file transfers. Each (or all) may be implemented in any terminal sofa stand alone product. All three also require the same software running at each end. They all work very well to transfer binary (.com .exe etc) files without the user having to worry or get any setups made properly (more than the basics). I have found X modem to be the most widely used on bbs & stuff. Y & Z may be able to identify X type tyransfers & use that automatically. I forget. Y & Z are supposedly better & faster, with Z being the best. I won't argue with that but it is in my experience the least implemented in the real world. I find that I can't live without straight ascii file transfers that non of these will do. The options available for ascii transfers are seemingly limitless. Rate, delay, interchange handshaking, filtering, convering,... The more options the more equipment (odd ball & non-computer {well ou know, cnc equipment, robots...}) you can easily transfer info with. This feature is built into almost all terminal packages & a discussion (war/flame fest) comparing & contrasting & arguements of could well take up weeks. al
tempest@wet.UUCP (Ken Lui) (01/02/90)
In article <1989Dec31.210253.25273@delta.uucp> don@delta.UUCP (Donald K. Irmiger) writes: >Works great. I like the ability to resurrect an interrupted transfer, >although I've yet to use it. > I'll have to second this reason for liking Zmodem. I've had to use it more than once and believe me, it really saves your skin if a large file was being uploaded or downloaded. The only problem I have with it is there isn't an option where you can turn off the CRC checking. It would be really nice to have a Zmodem-equivalent of Ymodem-G for high-speed or error correcting modems. Although Ymodem-G is about as fast as you can get in transferring a file, you don't have the resurrect transfer option of something goes wrong; and it appends extra bytes to files...which can be a pain if you transfer compressed files--.Z files from UNIX. You will get extra garbage as you uncompress them. Maybe it's my version of compress, but I always get them when I use X or Ymodem to download; I never get the trailing garbage if I use Zmodem. Ken -- _____________________________________________________________________________ Kenneth K.F. Lui | UUCP: ...{ucsfcca|claris}!wet!tempest tempest@wet.UUCP | Internet: cca.ucsf.edu!wet!tempest@cgl.ucsf.edu | -or- claris!wet!tempest@ames.arc.nasa.gov
larry@nstar.UUCP (Larry Snyder) (01/02/90)
In article <1989Dec31.210253.25273@delta.uucp>, don@delta.uucp (Donald K. Irmiger) writes: > > I've always had an affinity for ZMODEM. I'm using ProComm Plus (which does > not directly support ZMODEM) doing file transfers to/from a Xenix box. > Works great. I like the ability to resurrect an interrupted transfer, > although I've yet to use it. I am running ProYam here on nstar and it supports all the protocols available in the most popular DOS packages but best of all, ProYam is available for Unix System V and Xenix. ProYam is $139 (retail). -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA uucp: larry@nstar -or- ...!iuvax!ndmath!nstar!larry "Don't waste your time with QNX!"
larry@nstar.UUCP (Larry Snyder) (01/02/90)
> b. multitasking (DesqView) a graphics (high cpu overhead) application > in another window tends to cause retries/packet failures (yes, I > know that there must be a way to tune the DesqView parameters so > that this doesn't happen. I haven't found it!) I have several modems (4) all communicating at speeds of 9.6/19.2k and I can grab any modem from the pool, dial out and initiate a Zmodem transfer and get throughtput just as good as if I were calling out from a single user PC under DOS. With the HST modem, 1707 cps on archived transfers is the norm. Hardware? 25mhz '386 with smart serial board (10 mhz 80186). OS is ISC 2.02 System V. -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA uucp: larry@nstar -or- ...!iuvax!ndmath!nstar!larry "Don't waste your time with QNX!"
thaler@shorty.cs.wisc.edu (Maurice Thaler) (01/02/90)
In article <919@eecea.eece.ksu.edu> gordon@eecea.UUCP (Dwight W. Gordon) writes: >ZMODEM - >3. Not as robust as KERMIT. > a. noisy environments (bad phone connections) causes troubles > b. multitasking (DesqView) a graphics (high cpu overhead) application > in another window tends to cause retries/packet failures (yes, I > know that there must be a way to tune the DesqView parameters so > that this doesn't happen. I haven't found it!) Sorry Dwight, I don't buy this one. ZMODEM is very robust. 32bit-crc gives your virtually identical files including date and time stamping. Also, as the baud rate goes up the speed difference between ZMODEM and Kermit widens. I use a US Robotics Dual Standard modem and regularly get >1600bps using ZMODEM . Kermit could never do that, not even SuperKermit. If you are having problems with DesqView with DSZ or ZCOMM, I would suggest that it could be either EMS memory management and/or a less than well behaved disk cache that causes intrupt latecency problems (well documented in DSZ.DOC) or a less than wonderful UART. I switched to the NS16550an UART as recommended by Forsberg in the DSZ.DOC (about a $20 mod) and it cleared up all high speed/multitasking problems. This brings up another issue. It seems that several manufacturers (for example DELL) are using VLSI COM ports that are terrible at better than 9600. They can receive data at 19200 perhaps but fail to handle hardware handshaking thus being useless with today's high speed modems which require you to be locked into a bps higher than your connect rate. With my Dual Standard modem, they recommend you lock in at 38,400bps. This would fail every time with these VLSI or ancient UARTS. Also, quite unfortunately, when you buy an i/o card, they always solder in the first UART and leave the second socketed which means that you can only run one high speed UART off of COM2 and not COM1. At any rate, getting back to the original question, KERMIT is ONLY useful for talking to mainframes that have a 7bit data stream over which you want to pass 8-bit binaries. For PC-PC, or UNIX-PC ZMODEM is a clear winnner. BTW, If it wasn't mentioned earlier, if properly implemented, one nice feature of ZMODEM is that the receiving end does nothing to start the download. On my Unix account, I have an "rz" binary that automatically kicks in when I send files from my PC, and with ZCOMM,YAM, and TELIX, the terminal watches the datastream for ZMODEM's init string and automatically starts downloading. This is a really nice feature which sure beats: init download on remote jump back to terminal init download locally I was really disappointed when I checked out the new XTALK for Windows and discovered that their implementation of ZMODEM did not include autodownload. (Neither does WINQVT, but one would hope that the commercial package would have a better implementation than the shareware version |-) ) At any rate, perhaps ZMODEM is not free, but there are an increasing number of programs that implement it. And the price of DSZ, or ZCOMM is still under $50, which is a small percentage of your yearly phone bill using the program... -- Maurice Thaler SYSOP Audio Projects BBS (608) 836-9473 SYSOP Power Board BBS (608) 222-8842
gordon@eecea.eece.ksu.edu (Dwight Gordon) (01/02/90)
In article <9457@spool.cs.wisc.edu> thaler@shorty.cs.wisc.edu (Maurice Thaler) writes: >In article <919@eecea.eece.ksu.edu> gordon@eecea.UUCP (Dwight W. Gordon) writes: >>ZMODEM - >>3. Not as robust as KERMIT. >> a. noisy environments (bad phone connections) causes troubles >> b. multitasking (DesqView) a graphics (high cpu overhead) application >> in another window tends to cause retries/packet failures (yes, I >> know that there must be a way to tune the DesqView parameters so >> that this doesn't happen. I haven't found it!) > >Sorry Dwight, I don't buy this one. ZMODEM is very robust. 32bit-crc >gives your virtually identical files including date and time stamping. >Also, as the baud rate goes up the speed difference between ZMODEM and >Kermit widens. I use a US Robotics Dual Standard modem and regularly get >>1600bps using ZMODEM . Kermit could never do that, not even >SuperKermit. If you are having problems with DesqView with DSZ or >ZCOMM, I would suggest that it could be either EMS memory management >and/or a less than well behaved disk cache that causes intrupt latecency >problems (well documented in DSZ.DOC) or a less than wonderful UART. >I switched to the NS16550an UART as recommended by Forsberg in the >DSZ.DOC (about a $20 mod) and it cleared up all high speed/multitasking >problems. EMS is QEMM. It's interrupt latency all right. I admit the UART my strange (a custom VLSI for both UART channels - no $20 fix, board replacement time for the FIFO uart). The problem comes with graphic foreground tasks and telecommunications in the background. ZMODEM sees troubles and decreases the packet size. The unix box on the other end (3b15) suddenly gets "bogged down" with packets that have gotten as small as 32 bytes! (32 bits of CRC/32 Bytes of data => ~11% overhead). My point is that the graphic activities that generally cause this decrease in packet size are of a relatively short duration. Kermit doesn't change the packet size (at least my version doesn't). It drops packets just as ZMODEM does. However, with a "large" file, it more than catches up with its 1K packets (vs. the 32byte packets I end up with under ZMODEM). Note: I've tried "Tuning" my DesqView and haven't come up with a solution that both 1) doesn't drop packages in the background, and 2) leaves me enough time-slices in the foreground so that I still feel as if I'm running a 25MHz '386! - Dwight - P.S. I knew that my original posting was an invitation for flames. I was hoping for some constructive suggestions to fix the problem. I prefer ZMODEM. Has anybody out there seen a "cheap" 2S/1P card with the FIFO uart chips on it? -- Dwight W. Gordon, Ph.D. | 913-532-5600 | gordon@eecea.eece.ksu.edu Electrical & Computer Engineering Department | dwgordon@ksuvm.bitnet Kansas State University - Durland Hall | rutgers!ksuvax1!eecea!gordon Manhattan, KS 66506 | {pyramid,ucsd}!ncr-sd!ncrwic!ksuvax1!eecea!gordon
querubin@uhccux.uhcc.hawaii.edu (Antonio Querubin) (01/02/90)
There seem to be a few misconceptions in this string of notes regarding Kermit. Someone earlier wrote that none of the above programs in the subject line can do straight ascii text transfers. MS-Kermit can (see the TRANSMIT command). Another person wrote that Kermit couldn't run at 1600 BPS or greater. I would suspect this is a problem with the UART and BIOS on each machine and not with Kermit. I've run MS-Kermit to/from MacKermit file transfers at 5760 BPS (57600 BAUD) and MS-Kermit to/from C-Kermit (3840 BPS/38400 BAUD) (on a Unix mainframe going through two intermediate systems), both text and binary and don't have any problems. A distinction should also be made between the Kermit protocol itself and the Kermit programs that implement that protocol. I've heard for example that Procomm's implementation of the Kermit protocol isn't very intelligent. But that's not a problem with Kermit (the program), it's a problem with Procomm. The MS-Kermit program has a number of features that don't have equivalents in the basic XMODEM-family of programs. I have found that Kermit is implemented on a larger variety of computers than any single variant of XMODEM (substitute a letter of the alphabet for X) :-). MS-Kermit (the program) also provides VT-52, VT-102, Z-19, and Tek 4014 emulation modes all in one program. Best of all Kermit is FREE, Columbia University doesn't even ask for a donation last I checked.
wb8foz@mthvax.cs.miami.edu (David Lesher) (01/02/90)
Each protocol has some advantages.
Kermit will talk to/from a vast array of machine types, including ugly
Big Blue mainframes. In fact, this was part of its design intent.
For reasons I have never figured out, some unix versions need to
be explicitly told when the path is 7 bit, and crash and burn when I
forget to do this.
Zmodem is MUCH faster *if* the link has turn around delays. The longer
the delay, the more the advantage. An example of this is PCPursuit. If
you have a bare_bones direct connection, the speed advantage may not be
visible.
{X,Y}modem tend to be everywhere in the PC BBS world. So if you
spend lots of time there, it's nice to have the lowest common
denominator available.
Yous pays your money and yous takes your choice. Most of the
time, the money is near to or = 0.00.
--
A host is a host & from coast to coast...wb8foz@mthvax.cs.miami.edu
no one will talk to a host that's close..............(305) 255-RTFM
Unless the host (that isn't close)......................pob 570-335
is busy, hung or dead....................................33257-0335scott@csusac.csus.edu (L. Scott Emmons) (01/02/90)
In article <9457@spool.cs.wisc.edu> thaler@shorty.cs.wisc.edu (Maurice Thaler) writes: >>ZMODEM - >>3. Not as robust as KERMIT. >> [...] >Sorry Dwight, I don't buy this one. ZMODEM is very robust. 32bit-crc >gives your virtually identical files including date and time stamping. > [...] I have noticed that ZMODEM fails miserably when attempting transfers through a buffered environment, as from what I understand ZMODEM requires stricter timing than KERMIT, XMODEM, YMODEM, et al. When I am on a clean line, not running through many boxes (i.e. direct telco line to one of our micro-vaxen) ZMODEM runs perfectly. However, when I use it via our AT&T ISN network, which runs through a PBX, and several other boxes, ZMODEM fails (It gets a timeout error _EVERY_ 10K or so [where I assume the buffering is a problem somewhere in our system]), while YMODEM runs perfectly, 0% packet loss. So my opinion is that ZMODEM is the best protocol in direct CPU-modem-modem-CPU installations, while other protocols may be preferable in environments where data will undergo transformation/transportation through several different devices, especially equipment akin to AT&T's ISN, which is noisy...at least at our site... -- L. Scott Emmons --------------- ...[!ucbvax]!ucdavis!csusac!scott ucdavis!csusac!scott@ucbvax.berkeley.edu
larry@nstar.UUCP (Larry Snyder) (01/02/90)
> The MS-Kermit program has a number of features that don't have equivalents in > the basic XMODEM-family of programs. I have found that Kermit is implemented > on a larger variety of computers than any single variant of XMODEM (substitute > a letter of the alphabet for X) :-). MS-Kermit (the program) also provides > VT-52, VT-102, Z-19, and Tek 4014 emulation modes all in one program. Best of > all Kermit is FREE, Columbia University doesn't even ask for a donation last > I checked. What is the current version of MSKermit? We have 2.31a and am running into problems using the server mode and since 2.31 is dated August 88, assume that there is a newer release in distribution. -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA uucp: larry@nstar -or- ...!iuvax!ndmath!nstar!larry "NO! QNX is non-standard, not compatible, and is no more Unix than DOS!"
scott@clmqt.marquette.Mi.US (Scott Reynolds) (01/02/90)
Let me first qualify what I say in this article by stating that I didn't write ZModem (that honor goes to Chuck Forsberg). These are my personal opinions and observations. scott@csusac.csus.edu (L. Scott Emmons) writes: >I have noticed that ZMODEM fails miserably when attempting transfers through >a buffered environment, as from what I understand ZMODEM requires stricter >timing than KERMIT, XMODEM, YMODEM, et al. This one seems pretty strange to me. ZModem runs pretty well through buffered lines, being an ACK-less protocol. I've done it myself a few times through a packet network, and I've had no problems I can't attribute to other things. "Other things" include, for example, the fact that this 286 box can't handle continuous 2400 bps receiving from 3 async lines simultaneously without burping every couple minutes. The *NIX 2.x versions are in the public domain now, from what I understand, and I've been using them for over 2 years without problems. Most people connecting to this system have MS-DOS machines and use either DSZ or the ZModem built into the Telix package. -- Scott Reynolds = $ cat 'a can of tuna' Enterprise Information System = cat: cannot open a can of tuna scott@clmqt.marquette.Mi.US ..rutgers!mailrus!sharkey!clmqt!scott
ts@uwasa.fi (Timo Salmi LASK) (01/03/90)
In article <9457@spool.cs.wisc.edu> thaler@shorty.cs.wisc.edu (Maurice Thaler) writes: >In article <919@eecea.eece.ksu.edu> gordon@eecea.UUCP (Dwight W. Gordon) writes: >>ZMODEM - >>3. Not as robust as KERMIT. >> a. noisy environments (bad phone connections) causes troubles > >Sorry Dwight, I don't buy this one. ZMODEM is very robust. 32bit-crc But I do! Having used both quite heavily, my experience is that over very difficult conditions (noise, heady load on a remote server line, etc) kermit is the protocol that is the most likely to get through. Under these conditions Z-modem tends to get stuck. (It does not send incorrect data, though, which would be intolerable). Z-modem is a very nice protocoll under good and fair conditions, and is a good choice then. ................................................................... Prof. Timo Salmi (Site 128.214.12.3) School of Business Studies, University of Vaasa, SF-65101, Finland Internet: ts@chyde.uwasa.fi Funet: vakk::salmi Bitnet: salmi@finfun
ts@uwasa.fi (Timo Salmi LASK) (01/03/90)
In article <511119@nstar.UUCP> larry@nstar.UUCP (Larry Snyder) writes: > >What is the current version of MSKermit? We have 2.31a and am running into >problems using the server mode and since 2.31 is dated August 88, assume that >there is a newer release in distribution. The current version is 2.32A, and if you have anonymous ftp you can download it eg from chyde.uwasa.fi. ................................................................... Prof. Timo Salmi (Site 128.214.12.3) School of Business Studies, University of Vaasa, SF-65101, Finland Internet: ts@chyde.uwasa.fi Funet: vakk::salmi Bitnet: salmi@finfun
scott@csusac.csus.edu (L. Scott Emmons) (01/03/90)
In article <1578@clmqt.marquette.Mi.US> scott@clmqt.marquette.Mi.US (Scott Reynolds) writes: >>I have noticed that ZMODEM fails miserably when attempting transfers through >>[...] >This one seems pretty strange to me. ZModem runs pretty well through >buffered lines, being an ACK-less protocol. I've done it myself a few >[...] I 'spose I didn't make it very clear in my post, but yeah, the problem with Zmodem that I have found likely _isn't_ the protocol itself (which, IMHO, is the best one yet), but rather is with the setup of our computer network network. [sic -- we have a network of networks, if you will]. I still find it strange that ACKfull protocols work where Zmodem doesn't -- Apparantly some boxes (X.25 networks, for example) barf on ACKs...which is why Kermit was (according to my sourcs) invented (it uses no ACKs). It seems to me that Zmodem should work anywhere that any other protocols do...but I'm not familiar with the mechanics of Zmodem. Has anyone else had problems like I illustrated in my previous post? If so, perhaps we can isolate it and create a fix for certain environments. I will post my findings...time to go fire up the datascope! -- L. Scott Emmons --------------- ...[!ucbvax]!ucdavis!csusac!scott ucdavis!csusac!scott@ucbvax.berkeley.edu
perand@nada.kth.se (Per Andersson) (01/03/90)
There has been quite a lot of discussion of 'kermit' vs. Z-modem lately. What almost everybody forgot to mention is what kind of kermit you are running. This is most important, due to allowed differences in the implementation ( which, of course, doesn't mean they won't talk to each other). When comparing with Z-modem you should choose C-kermit and MS-kermit, which allow large packet-sizes etc. There is no reason to blame the kermit protocol for bad implementations. These few percent I might loose running MS-Kermit instead of Z-modem don't bother me, as I really like to have a transfer program available on my mini ( Norsk Data btw.). Kermit has yet the absolutely greatest count of implementations. I tend to run Z-modem, or rather TELIX, but then rather for its simplicity on my 8-bit path, and it's auto-transfer starting. But maybe kermit allows that too, and nobody has yet implemented it ?. Apart from filetransfer, MS-Kermit tends to be one of the greatest terminal emulators around ( as someone also mentioned previously ). Happy flaming, Per -- --- Per Andersson Royal Institute of Technology, Stockholm, Sweden perand@admin.kth.se, @nada.kth.se
roy@comcon.UUCP (Roy M. Silvernail) (01/03/90)
In article <1636@rodan.acs.syr.edu>, amichiel@rodan.acs.syr.edu (Michielsen) writes: > Y & Z are supposedly better & faster, with Z being the best. I won't argue > with that but it is in my experience the least implemented in the real world. Zmodem is primarily (for now) a PC protocol. There are implementations for Unix, though. (I use Zmodem on this Unix site daily) > I find that I can't live without straight ascii file transfers that non of > these will do. Straight ASCII files? I assume, since you mentioned it at all, that you are moving text files between a PC and a non-PC. Zmodem for Unix includes a -a switch to convert newlines as the transfer progresses. Of course, in the case of a batch transfer, you must make sure that all the files to be moved are ASCII, else any binaries in the queue will be demolished by the text conversion. (You are correct about Xmodem and Ymodem not having this ability) There are also a large number of utilities to make the newline conversion on your PC. I use Rahul Dhesi's FLIP. No war. No flame-fest (at least, not from me... ;-) I use Zmodem most of the time, and Kermit when I have to. -- _R_o_y _M_. _S_i_l_v_e_r_n_a_i_l | UUCP: uunet!comcon!roy | "Every race must arrive at this #include <opinions.h>;#define opinions MINE | point in its history" SnailMail: P.O. Box 210856, Anchorage, | ........Mr. Slippery Alaska, 99521-0856, U.S.A., Earth, etc. | <Ono-Sendai: the right choice!>
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (01/03/90)
If you can avoid kermit, do so for several reasons. It's designed
to work on a 7-bit data path, so it has an inherent performance penalty
due to this. Also, it uses miniscule packets (although newer versions
are supposed to be able to handle reasonably-sized packets ... but only
if you have a newer version at both ends of the data link). I'm not
sure if it can transmit date/time stamp information; I don't think it
can.
Between X and Y, pick Y if you have a reasonably reliable phone line.
It uses 1K packets rather than the 128 byte packets of XMODEM, so the
overhead is reduced by about a factor of eight (but if you have a very
noisy phone line, more packets will have to be resent). I think that
some implementations of XMODEm have added batch transfer capabilities
to it; these are standard in YMODEM (although I don't think either one
transfers time/date stamps).
I haven't used ZMODEM, so I can't comment except to say that it is
reported to be better than X or Y.
--
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
If it's true that love is only a game//Well, then I can play pretendwb8foz@mthvax.cs.miami.edu (David Lesher) (01/03/90)
>Has anyone else had problems like I illustrated in my previous post? If so, >perhaps we can isolate it and create a fix for certain environments. I will >post my findings...time to go fire up the datascope! Well, ISTM the problem with ZMODEM and multiple boxes betwixt and between isn't ACKS or quacks, it's dropped data. Since ZMODEM does not sit around every 'n' bits and wait for a grunt back, it overflows those routes with FUBAR flow control. In theory, you get everything out that you put in. In practice, if the buffers are small, and the flowcontrol either too slow or too stupid, you lose stuff. Now since X,Y and Kermit all {send, wait, send, etc} there is time for the buffers to empty. ZMODEM sees no reason to waste this time. There is a Gandolf/Decserver path to mthvax. If I attempt use it with text, it drops the ends of full pages. Pages with lots of short lines and <CR>s are no problem. Sure enough, ZMODEM bitches constantly if I attempt to use this path. But it does go through, intact. IMHO, you can't blame ZMODEM for the valid assumption that what goes in, must come out. You can blame the people who designed and/or implementated the hardware. -- A host is a host & from coast to coast...wb8foz@mthvax.cs.miami.edu no one will talk to a host that's close..............(305) 255-RTFM Unless the host (that isn't close)......................pob 570-335 is busy, hung or dead....................................33257-0335
querubin@uhccux.uhcc.hawaii.edu (Antonio Querubin) (01/03/90)
In article <511119@nstar.UUCP> larry@nstar.UUCP (Larry Snyder) writes: > >What is the current version of MSKermit? We have 2.31a and am running into >problems using the server mode and since 2.31 is dated August 88, assume that >there is a newer release in distribution. The version we have is 2.32/A. The current version can be gotten from kermit.columbia.edu.
jbayer@ispi.UUCP (Jonathan Bayer) (01/03/90)
scott@csusac.csus.edu (L. Scott Emmons) writes: >In article <1578@clmqt.marquette.Mi.US> scott@clmqt.marquette.Mi.US (Scott Reynolds) writes: >I 'spose I didn't make it very clear in my post, but yeah, the problem with >Zmodem that I have found likely _isn't_ the protocol itself (which, IMHO, is >the best one yet), but rather is with the setup of our computer network >network. [sic -- we have a network of networks, if you will]. I still find it >strange that ACKfull protocols work where Zmodem doesn't -- Apparantly some >boxes (X.25 networks, for example) barf on ACKs...which is why Kermit was >(according to my sourcs) invented (it uses no ACKs). It seems to me that >Zmodem should work anywhere that any other protocols do...but I'm not familiar >with the mechanics of Zmodem. >Has anyone else had problems like I illustrated in my previous post? If so, >perhaps we can isolate it and create a fix for certain environments. I will >post my findings...time to go fire up the datascope! The problem isn't Z-modem, it is the hardware. Somewhere in the network a buffer is being overflowed and data is being lost. This happens because Z-modem is a streaming protocol, meaning that it sends continously until either there is an error or the file is finished. There is already a fix. sz has some options, the "-l" and the "-L". Copying from the manual pages: L N Use ZMODEM sub-packets of length N. A larger N (32 <= N <= 1024) gives slightly higher throughput, a smaller N speeds error recovery. The default is 128 below 300 baud, 256 above 300 baud, or 1024 above 2400 baud. l N Wait for the receiver to acknowledge correct data every N (32 <= N <= 1024) characters. This may be used to avoid network overrun when XOFF flow control is lacking. JB -- Jonathan Bayer Intelligent Software Products, Inc. (201) 245-5922 500 Oakwood Ave. jbayer@ispi.COM Roselle Park, NJ 07204
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (01/04/90)
In article <1636@rodan.acs.syr.edu> amichiel@rodan.acs.syr.edu (Michielsen) writes: | Kermit, Is best because it's free. It works pretty well for transfers of | files & the terminal emulation is pretty robust. However, it requires kermit | running at both ends & setup compatible to do file transfers. Hate to shock you, but there are free implementation of [XYZ]modem and commercial implementations of Kermit. Zmodem and window Kermit will run well over packet connections (and that includes some ECC modems) while the others suffer because of line turnaround time. They produce the best throughput over clean lines, too, but they are not as common as plain Kermit and Xmodem. Zmodem seems to work better on a noisy line, due to changing the packet size. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
querubin@uhccux.uhcc.hawaii.edu (Antonio Querubin) (01/04/90)
In article <25A14694.9576@maccs.dcss.mcmaster.ca> cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) writes: > > If you can avoid kermit, do so for several reasons. It's designed >to work on a 7-bit data path, so it has an inherent performance penalty >due to this. Also, it uses miniscule packets (although newer versions >are supposed to be able to handle reasonably-sized packets ... but only >if you have a newer version at both ends of the data link). I'm not >sure if it can transmit date/time stamp information; I don't think it >can. Kermit does not inherently work on a 7-bit data path. MS-Kermit and MACKermit for example, transfer 8-bit data AS 8-bit data. You can force 8-bit 'quoting' if you need to. Both these versions handle 1K and 2K packets, respectively. C-Kermit also handles 1K+ packets. I know that MS-Kermit handles file attribute info. MACKermit does also if you select the macbinary mode. I don't know about the other modes. The Kermit family of programs is pretty big. They're written for different hardware platforms and a wide variety of operating systems. Some implement many of the kermit protocol features, others implement only the basics just to get the job done. But they share one very important feature: they can talk to each other.
flinton@eagle.wesleyan.edu (01/12/90)
In article <5885@uhccux.uhcc.hawaii.edu>, querubin@uhccux.uhcc.hawaii.edu (Antonio Querubin) writes: [in response to query: "What is the current version of MSKermit?"] > > The version we have is 2.32/A. The current version can be gotten from > kermit.columbia.edu. A beta-test edition of version 3.0 has just been announced (I _think_ I saw the announcement on comp.archives). -- Fred
news@bbn.COM (News system owner ID) (01/13/90)
flinton@eagle.wesleyan.edu writes:
< A beta-test edition of version 3.0 has just been announced (I _think_
< I saw the announcement on comp.archives).
Yes, this is true. The new version has lots of new stuff, including
international char set handling (both screen and transfer), and the
windowing protocol enhancement (which makes Kermit better than X and
Y-MODEM, and Real Close to Zmodem in performance (roughly 95%
efficiency for text, slightly less (low 90s) for compressed data).
As a fellow Kermit developer, I ask you all to do Joe a big favor: If
you do get a copy of _beta_ MK 3.0, PLEASE do NOT pass it along to
your friends who can't FTP the release version when it comes out
(which will be quite soon), and PLEASE do yourself get the release
version when it comes out (and make sure all beta copies that got
around are updated).
You really wouldn't believe how many letters I get reporting bugs in a
_beta_ version of MacKermit that was superceded a YEAR ago (in this
case, 0.97 -- if you have it, throw it away and get 0.98).
-- Paul Placewaycharlie@csnz.co.nz (Charles Lear) (01/24/90)
In article <50876@bbn.COM> pplacewa@antares.bbn.com (Paul W Placeway) writes: >You really wouldn't believe how many letters I get reporting bugs in a >_beta_ version of MacKermit that was superceded a YEAR ago... I would. I had a bug report from a beta test site of my BBS software last night. Sounded like something I'd fixed a while ago. "What version are you running?" "5.08" "Argh! Why aren't you using 5.10S????" "I found a couple of bugs in it and went back to the old version"... ============================================================================== Charlie "The Bear" Lear Snail: Box 12-175, Wellington, New Zealand The Cave BBS: 64(4)643429 24hrs V21/23/22/22bis Free Access 157MB online! UUCP: ..!uunet!vuwcomp!dsiramd!csnz!charlie Domain: charlie@csnz.co.nz ==============================================================================