davidm@uunet.UU.NET (David S. Masterson) (10/08/90)
I've been using Atalk III to connect to Vax/VMS and then using Kermit to transfer files back and forth. Most of the time, its very reliable unless the connection is very noisy (what else is new, right ;-). What I'd like to know, though, is why the Transfer window on Atalk III typically reports the size of the transferred file as 50% larger than the actual file's size. Any ideas? -- ==================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
papa@pollux.usc.edu (Marco Papa) (10/08/90)
In article <CIMSHOP!DAVIDM.90Oct7224729@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >I've been using Atalk III to connect to Vax/VMS and then using Kermit to >transfer files back and forth. Most of the time, its very reliable unless the >connection is very noisy (what else is new, right ;-). What I'd like to know, >though, is why the Transfer window on Atalk III typically reports the size of >the transferred file as 50% larger than the actual file's size. Any ideas? The built-in Kermit reports the bytes transfered including any encoding. This results in "more" bytes than the actual file size. Since Release 1.3, A-Talk III has included XPRKermit that I authored together with Steve Walton (hi, Steve! :-), and that we put in the public domain. If you don't have Release 1.3c, you can upgrade from Oxxi quite inexpensively. The XPR Kermit turns out to be MUCH more powerful than the built-in kermit: it supports 8-bit quoting, large packets, user definable options AND it displays the "correct" file size. The built-in kermit will eventually be dropped and deleted from the binary and we'll ship only with XPR-Kermit. Given the above, there is no reason for us to "fix" the built-in kermit. Note that there is NO loss in performance by using the external XPRkermit compared to the built-in kermit, while this is NOT true concerning XPR-Zmodem vs. built-in ZMODEM, and that's why we'll keep the built-in ZMODEM. -- Marco -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
jbn35564@uxa.cso.uiuc.edu (J.B. Nicholson) (10/09/90)
papa@pollux.usc.edu (Marco Papa) writes: >Note that there is >NO loss in performance by using the external XPRkermit compared to the built-in >kermit, while this is NOT true concerning XPR-Zmodem vs. built-in ZMODEM, and >that's why we'll keep the built-in ZMODEM. Why not fix the XPR Zmodem? I really like the idea of XPR, and I think, with the right set of XPR protocols, you terminal developers could (theoretically) drop all transfer protocols and concentrate on the terminal emulator side of the product. >-- Marco >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >"Xerox sues somebody for copying?" -- David Letterman >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -- Jeff jeffo@mrcnext.cso.uiuc.edu
papa@pollux.usc.edu (Marco Papa) (10/09/90)
In article <1990Oct8.193808.21972@ux1.cso.uiuc.edu> jbn35564@uxa.cso.uiuc.edu (J.B. Nicholson) writes: >papa@pollux.usc.edu (Marco Papa) writes: >>Note that there is >>NO loss in performance by using the external XPRkermit compared to the built-in >>kermit, while this is NOT true concerning XPR-Zmodem vs. built-in ZMODEM, and >>that's why we'll keep the built-in ZMODEM. > >Why not fix the XPR Zmodem? > >I really like the idea of XPR, and I think, with the right set of XPR protocols, >you terminal developers could (theoretically) drop all transfer protocols and >concentrate on the terminal emulator side of the product. There is really nothing to fix. XPR-Zmodem has an inherent overhead due to the external protocol definition. This can be minimized with appropriate coding, but I doubt that it will ever be as good as a built-in one, where the extra overhead of procedure pointers and library calls is not there. I see the above being true of full-duplex streaming mode protocols like Zmodem and Ymodem-g, while pretty much ANY half-duplex protocol (like Kermit, Xmodem, and Ymodem) will not have any appreciable downgrading in an XPR implementation. -- Marco -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
jeh@sisd.kodak.com (Ed Hanway) (10/09/90)
papa@pollux.usc.edu (Marco Papa) writes: >In article <1990Oct8.193808.21972@ux1.cso.uiuc.edu> jbn35564@uxa.cso.uiuc.edu (J.B. Nicholson) writes: >>Why not fix the XPR Zmodem? >There is really nothing to fix. XPR-Zmodem has an inherent overhead due to >the external protocol definition. Then why not fix the external protocol definition? Or what I really mean is extend it to make it capable of handling full-duplex streaming protocols without degradation. Ed Hanway uunet!sisd!jeh
joseph@valnet.UUCP (Joseph P. Hillenburg) (10/11/90)
jeh@sisd.kodak.com (Ed Hanway) writes: > papa@pollux.usc.edu (Marco Papa) writes: > >In article <1990Oct8.193808.21972@ux1.cso.uiuc.edu> jbn35564@uxa.cso.uiuc.ed > >>Why not fix the XPR Zmodem? > > >There is really nothing to fix. XPR-Zmodem has an inherent overhead due to > >the external protocol definition. > > Then why not fix the external protocol definition? Or what I really mean > is extend it to make it capable of handling full-duplex streaming protocols > without degradation. > > Ed Hanway > uunet!sisd!jeh The fact that the protocol is *external* is why it isn't as fast as an internal protocol. BTW, does anyone know if, on a 25 mhz 2500/30, that the downloading problems with JR-Comm are eliminated, when using 9600 baud on a 16 color screen? -Joseph Hillenburg UUCP: ...iuvax!valnet!joseph ARPA: valnet!joseph@iuvax.cs.indiana.edu INET: joseph@valnet.UUCP