ked@garnet.berkeley.edu (Earl H. Kinmonth) (05/14/89)
From an ATT 6310 running both SCO Xenix and MSDOS, I connect to a 9600 baud leased line which goes to a Develnet switch and thence to various machines at UC-Davis and UC-Berkeley. xyzmodem (any of the protocols) work for downloads, but uploads INVARIABLY stop after 16 blocks have been transferred. This is consistent over half a dozen different machines and several different xyzmodem packages on either end. The problem occurs on a 2400 baud dialin as well. Any ideas? kermit works (with mark parity).
les@chinet.chi.il.us (Leslie Mikesell) (05/15/89)
In article <24404@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: >From an ATT 6310 running both SCO Xenix and MSDOS, I connect to a 9600 >baud leased line which goes to a Develnet switch and thence to various >machines at UC-Davis and UC-Berkeley. xyzmodem (any of the protocols) >work for downloads, but uploads INVARIABLY stop after 16 blocks have >been transferred. This is consistent over half a dozen different machines >and several different xyzmodem packages on either end. The problem >occurs on a 2400 baud dialin as well. >Any ideas? kermit works (with mark parity). Something in the link is set to use XON/XOFF flow control. Packet 17 in x/ymodem will use a literal 17 (control-S) as the packet number and hang the link. The only control character kermit uses is control-A for start-of-packet, others are forced into the printable character range to avoid this type of problem. On the 2400 dialup, the flow control must be happening in one of the modems (not unusual these days). I thought zmodem was supposed to work on flow-controlled lines, but perhaps it takes some option to allow it. Les Mikesell
leonard@bucket.UUCP (Leonard Erickson) (05/15/89)
In article <24404@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes:
<From an ATT 6310 running both SCO Xenix and MSDOS, I connect to a 9600
<baud leased line which goes to a Develnet switch and thence to various
<machines at UC-Davis and UC-Berkeley. xyzmodem (any of the protocols)
<work for downloads, but uploads INVARIABLY stop after 16 blocks have
<been transferred. This is consistent over half a dozen different machines
<and several different xyzmodem packages on either end. The problem
<occurs on a 2400 baud dialin as well.
<
<Any ideas? kermit works (with mark parity).
Sure, turn off the xon/xoff filter! Block # 17 will have a ^Q as the
block number. If you have something that is intercepting software flow
control, then your xfer will die after either block 16 or block 18.
To run [x|y|z]modem you must be using hardware flow control throughout.
Software flow control will kill the xfer.
--
Leonard Erickson ...!tektronix!reed!percival!bucket!leonard
CIS: [70465,203]
"I'm all in favor of keeping dangerous weapons out of the hands of fools.
Let's start with typewriters." -- Solomon Shortked@garnet.berkeley.edu (Earl H. Kinmonth) (05/15/89)
In article <8457@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <24404@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: >>machines at UC-Davis and UC-Berkeley. xyzmodem (any of the protocols) >>work for downloads, but uploads INVARIABLY stop after 16 blocks have >>been transferred. This is consistent over half a dozen different machines > >>Any ideas? kermit works (with mark parity). > >Something in the link is set to use XON/XOFF flow control. Packet 17 >in x/ymodem will use a literal 17 (control-S) as the packet number >and hang the link. The only control character kermit uses is >control-A for start-of-packet, others are forced into the printable Several people have suggested an xon/xoff problem. This may be the case, but I haven't lucked into the right set of operations yet. I tried stty -tandem tandem on the SUN and VAX hosts without luck. As time permits, I'll keep trying. I have had one success. Using rz -e on the host does allow uploads with Zmodem from my ATT 6310 running SCO Xenix. According to the zmodem manual, -e causes the sender (sz) to "quote all control characters." This works on both my leased line and 2400 baud modem. I haven't timed zmodem vs kermit on uploads yet. On downloads, at least with base 85 encoded files, kermit seems to win: average xfer rate on 9600 baud line of 560 chars/sec vs 340 for zmodem. Maybe there is more tuning that needs to be done. Thanks to all who offered help. Any further ideas still welcome.
paul@morganucodon.cis.ohio-state.edu (Paul Placeway) (05/16/89)
In article <24440@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: In article <8457@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <24404@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: >>machines at UC-Davis and UC-Berkeley. xyzmodem (any of the protocols) >>work for downloads, but uploads INVARIABLY stop after 16 blocks have >>been transferred. This is consistent over half a dozen different machines > >>Any ideas? kermit works (with mark parity). > >Something in the link is set to use XON/XOFF flow control. Packet 17 >in x/ymodem will use a literal 17 (control-S) as the packet number >and hang the link. The only control character kermit uses is >control-A for start-of-packet, others are forced into the printable ... I have had one success. Using rz -e on the host does allow uploads with Zmodem from my ATT 6310 running SCO Xenix. According to the zmodem manual, -e causes the sender (sz) to "quote all control characters." This works on both my leased line and 2400 baud modem. And you have just turned zmodem into something almost as roubust as Kermit (but not quite). I haven't timed zmodem vs kermit on uploads yet. On downloads, at least with base 85 encoded files, kermit seems to win: average xfer rate on 9600 baud line of 560 chars/sec vs 340 for zmodem. Maybe there is more tuning that needs to be done. Interesting. I just did the jrd/pwp cannonocal speed test (transfer ckutio.c), and got 805 c/s between two C-kermits (Sun-3 and MacKermit; both are test versions), using 1016 byte packets and 3 char checksum (CRC). First off, get the test version of C-Kermit from cunixc.cc.columbia.edu; look in the kermit/test directory. (If you do, and you have any problem, make sure to send back a description to info-kermit.) If you have a fairly clean line, set the recieve packet length to about 1000 (1016 is the absolute max, but 1000 is close enough). If you get more than about 3% retrys, drop this to about 500 bytes. If kermit works, use it. (I _could_ be accused of being biased I suppose... :-) ) -- Paul Placeway Mac Kermit coord.
wcf@psuhcx.psu.edu (Bill Fenner) (05/16/89)
In article <24404@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: |baud leased line which goes to a Develnet switch and thence to various |work for downloads, but uploads INVARIABLY stop after 16 blocks have |been transferred. This is consistent over half a dozen different machines Would the Develnet switch happen to like ^P as a "local" switch? At the PSU Engineering Computer Lab, we have a terminal switcher called T12, which uses ^P to switch back to it and choose another computer. Anyone familiar with x and ymodem will know that they transmit the block number as a single character, ^P is 16. See if there's a "passthrough" option on the switch, which won't let you change sessions, but will let you use your protocols. (T12 is a pain to attempt uucp through... too many ^P's. :-) Bill -- Bitnet: wcf@psuhcx.bitnet Bill Fenner | "Yesterday starts Internet: wcf@hcx.psu.edu | tomorrow; tomorrow UUCP: {gatech,rutgers}!psuvax1!psuhcx!wcf | starts today" Fido: Sysop at 1:129/87 (814/238 9633) \hogbbs!wcf | -- Marillion
wcf@psuhcx.psu.edu (Bill Fenner) (05/16/89)
In article <8457@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: |Something in the link is set to use XON/XOFF flow control. Packet 17 |in x/ymodem will use a literal 17 (control-S) as the packet number sorry. Last I checked, 17 was X*ON*... 19 is X*OFF*. See my previous message for a possible answer. Bill -- Bitnet: wcf@psuhcx.bitnet Bill Fenner | "Yesterday starts Internet: wcf@hcx.psu.edu | tomorrow; tomorrow UUCP: {gatech,rutgers}!psuvax1!psuhcx!wcf | starts today" Fido: Sysop at 1:129/87 (814/238 9633) \hogbbs!wcf | -- Marillion
caf@omen.UUCP (Chuck Forsberg WA7KGX) (05/17/89)
In article <1399@bucket.UUCP> leonard@bucket.UUCP (Leonard Erickson) writes:
:To run [x|y|z]modem you must be using hardware flow control throughout.
:Software flow control will kill the xfer.
Close, but no cigar. ZMODEM protects the four flow control characters.
Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
Omen Technology Inc "The High Reliability Software"
17505-V NW Sauvie IS RD Portland OR 97231 503-621-3406
TeleGodzilla:621-3746 FAX:621-3735 CIS:70007,2304 Genie:CAFbill@bilver.UUCP (Bill Vermillion) (05/17/89)
In article <24440@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: >In article <8457@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >>In article <24404@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: >>>machines at UC-Davis and UC-Berkeley. xyzmodem (any of the protocols) >>>work for downloads, but uploads INVARIABLY stop after 16 blocks have >>>been transferred. This is consistent over half a dozen different machines >>>Any ideas? kermit works (with mark parity). >>Something in the link is set to use XON/XOFF flow control. Packet 17 >>in x/ymodem will use a literal 17 (control-S) as the packet number >>and hang the link. Something doesn't sound right here, to me at least. 17 (decimal) is a control Q which is a restart after xoff. Control S is decimal 19. The way I see it, either kermit doesn't use the lower numbers, and sends a 19 for 17 - that doesn't seem at all logical, or something else is coming in to play. I counted on my fingers TWICE! :-) What am I missing here bill -- Bill Vermillion - bill@bilver.UUCP
les@chinet.chi.il.us (Leslie Mikesell) (05/17/89)
In article <1228@psuhcx.psu.edu> wcf@psuhcx.psu.edu (Bill Fenner) writes: >|Something in the link is set to use XON/XOFF flow control. Packet 17 >|in x/ymodem will use a literal 17 (control-S) as the packet number >sorry. Last I checked, 17 was X*ON*... 19 is X*OFF*. See my previous >message for a possible answer. Oops - you're right, of course. However, most links that use xon/xoff will not pass control-Q through either. DLE is also likely, though. If packet 16 is accepted by the receiver then it must be ^Q, if packet 16 doesn't get through then it is ^P. Les Mikesell
ked@garnet.berkeley.edu (Earl H. Kinmonth) (05/18/89)
In article <765@omen.UUCP> caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: >In article <1399@bucket.UUCP> leonard@bucket.UUCP (Leonard Erickson) writes: >:To run [x|y|z]modem you must be using hardware flow control throughout. >:Software flow control will kill the xfer. > >Close, but no cigar. ZMODEM protects the four flow control characters. As I indicated in my "thanks" posting, zmodem will work but only if the receiving side uses rz -e which, according to the documentation, quotes all control characters. Whether this also produces quoting of characters with the 8-th bit on, is not stated. By the way, am I "wrong" in thinking that the apparent assumption of a clear eight-bit path in the [xy]modem protocols represents {naive| brain-dead|criminally stupid} programming? Was there something different about the world when these protocols were written that a clear eight-bit path could be assumed? Maybe because I'm an historian and not a programmer, I would start from the assumption that any communications protocol ought to have as a fall back option nothing better than a BCD character set. (Anything less, and you may as well revert to carrier pigeons.)
palowoda@megatest.UUCP (Bob Palowoda) (05/18/89)
From article <24440@agate.BERKELEY.EDU>, by ked@garnet.berkeley.edu (Earl H. Kinmonth): > In article <8457@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >>In article <24404@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: >>>machines at UC-Davis and UC-Berkeley. xyzmodem (any of the protocols) >>>work for downloads, but uploads INVARIABLY stop after 16 blocks have >>>been transferred. This is consistent over half a dozen different machines >> [some text deleted] > > I haven't timed zmodem vs kermit on uploads yet. On downloads, at least > with base 85 encoded files, kermit seems to win: average xfer rate on > 9600 baud line of 560 chars/sec vs 340 for zmodem. Maybe there is more > tuning that needs to be done. Hmm, something is wrong with 340. I run Xenix and also use Zmodem to download/upload from a dos machine that's hard port connected @9600 and via a TrialBlazier. On hard connected I see 928cps, modem I see 910cps. Haven't tried 19.2k yet. ---Bob -- Bob Palowoda *Home of Fiver BBS* login: bbs Work: {sun,decwrl,pyramid}!megatest!palowoda Home: {sun}ys2!fiver!palowoda (A XBBS System) 2-lines BBS: (415)623-8809 2400/1200 (415)623-8806 1200/2400/9600/19200
THOMAS_ERSKINE@DOCCRC.BITNET (05/18/89)
Your problem isn't with X/Y/Z modem; your problem is with the Develnet switch. Unless your communications people have disabled the speed/parity/code conversion stuff in the switch, it *needs* to be able to throttle the line, and it will use XON/OFF. I don't think you can tell it to use anything else. You'll have to tell Zmodem to quote them or use Kermit. Kermit with long (>=1000) isn't that bad. If Zmodem can be convinced to only quote XON/XOFF, then it should be faster, but I seem to remember that it wants to quote all un-printables, or none. Thomas Erskine [613-998-2545] <TErskine@DOCCRC.BITNET>
dplatt@coherent.com (Dave Platt) (05/19/89)
In article <24552@agate.BERKELEY.EDU> Earl H. Kinmonth writes: > By the way, am I "wrong" in thinking that the apparent assumption of a > clear eight-bit path in the [xy]modem protocols represents {naive| > brain-dead|criminally stupid} programming? Was there something > different about the world when these protocols were written that a > clear eight-bit path could be assumed? Maybe because I'm an historian > and not a programmer, I would start from the assumption that any > communications protocol ought to have as a fall back option nothing > better than a BCD character set. (Anything less, and you may as well > revert to carrier pigeons.) Naive, perhaps; brain-dead or criminally-stupid, no. The XMODEM protocol was devised by a hobbyist, so that he and his friends could reliably transfer data over low-speed modem lines between their personal computers (this was back in the days when "PC" meant "a computer that I assembled, personally"). The technology in use was quite simple... Bell 103-protocol (300-baud) modems direct-dialed into one another. Networks (public or private), terminal concentrators, gateways, modem-based flow control, and the sort were non-issues... either they didn't exist at the time, or were absent in the environment in which XMODEM was being developed and used. The fundamental design of the protocol was "Keep It Simple, Stupid!" XMODEM has been implemented on _many_ systems, because it's a simple protocol to code up and because the protocol description is in the public domain. The XMODEM protocol is certainly showing its age... it has been enhanced to support larger packets (XMODEM-1k), file-description information (YMODEM-Batch), windowing, and other goodies. Its fundamental orientation as an 8-bit protocol hasn't gone away, though. Quite some time ago, folks who were living in a 7-bit environment developed a protocol that could work reliably over data-links that were limited to 7 bits and which were finicky about passing control characters. This protocol (Kermit) is still the protocol-of-choice for transferring files in most PC-to-mainframe environments. ZMODEM can, at least, deal with situations in which the reverse path (receiver-to-transmitter) is not 8-bit-transparent... this covers a large percentage of the download-lots-of-data-over-a-network situations. This was the purpose for which it was engineered... it was designed to permit people to download data, rapidly and effectively, over the sorts of packet-switching nets that the people-who-paid-for-its-design were running. My impression is that there was less emphasis laid on its ability to permit _uploading_ of data over these same networks; I could very well be wrong. [Chuck... care to comment, if you're following this thread?] There are a number of proprietary protocols floating around that can handle uploads and downloads over "unclean" and "untransparent" datapaths. Some of these are perhaps superior, in an engineering sense, to the [XYZ]MODEM family and to Kermit. However, because they're proprietary, they have not been widely implemented and have never become particularly popular. -- Dave Platt FIDONET: Dave Platt on 1:204/444 VOICE: (415) 493-8805 UUCP: ...!{ames,sun,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com INTERNET: coherent!dplatt@ames.arpa, ...@uunet.uu.net USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303
blarson@skat.usc.edu (Bob Larson) (05/19/89)
In article <24552@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: >By the way, am I "wrong" in thinking that the apparent assumption of a >clear eight-bit path in the [xy]modem protocols represents {naive| >brain-dead|criminally stupid} programming? Wrong only in that you assume different design goals for Xmodem than the author did. > Was there something >different about the world when these protocols were written that a >clear eight-bit path could be assumed? Since Xmodem was designed to transfer files from the author's CPM system to other CPM systems, the assumptions were valid. The problem is the people who started using Xmodem for things it has never been able to do in a reasonable manner: tranfer files to non-CPM systems, or use communications devices other than direct dial 300 baud modems. Kermit was designed from the begining to be used on a variety of machines. It is quite robust and can handle file transfers over data chanels that support all printing ascii characters and one control character (normally ^A). Zmodems main problem is lack of good free versions for most operating systems, when os9/68k and primos versions are available I may even consider replacing my use of kermit with Zmodem. -- Bob Larson Arpa: blarson@skat.usc.edu Uucp: {uunet,cit-vax}!usc!skat!blarson Prime mailing list: info-prime-request%ais1@ecla.usc.edu usc!ais1!info-prime-request
ked@garnet.berkeley.edu (Earl H. Kinmonth) (05/19/89)
In article <25165@coherent.com> dplatt@coherent.com (Dave Platt) writes: >In article <24552@agate.BERKELEY.EDU> Earl H. Kinmonth writes: > >XMODEM has been implemented on _many_ systems, because it's a simple >protocol to code up and because the protocol description is in the >public domain. This would suggest that the term "brain dead" is best applied to the people who installed it on the VAX I use - a system without an "honest" eight-bit path from the outside - without documenting the limitations of the protocol. Back where I come from, we'd call something like this, "About as useful as teats on a boar hog!" >ZMODEM can, at least, deal with situations in which the reverse path >(receiver-to-transmitter) is not 8-bit-transparent... this covers a >large percentage of the download-lots-of-data-over-a-network situations. After my original posting, I was able to get zmodem to work for both up and down loads. The trick for uploads was to use rz -e to force quoting of all control characters. I have not run any precise benchmarks yet, but given my path ATT6310 (Xenix) <==> 9600 baud line <==> switch <==> Develnet <==> SUN my IMPRESSION is that (large packet) kermit and zmodem offer similar performance for ascii files. For binary files, zmodem seems quite a bit faster. As time permits, I'll try to make serious tests. >running. My impression is that there was less emphasis laid on its >ability to permit _uploading_ of data over these same networks; I could >very well be wrong. [Chuck... care to comment, if you're following this >thread?] As noted above, rz -e, works fine. The documentation leaves much to be desired however. I figured out for myself how to run zmodem from kermit and how to patch Sandy's version of CU to call zmodem. I would say that I figured this out in spite of the ZMODEM documentation, not because of it. Presumably (flame me if I'm wrong as I'm sure you will) the author of Zmodem is between a rock and a hard place on this: he'd like to have the protocol become more widespread BUT he'd prefer this happen through purchase of PRO Yam (a name that rubs me the wrong way) rather than splicing the protocol into public domain software. I can supply a version of Sandy Z's CU hacked to properly call zmodem. Whether this is equivalent to the "seamless integration" promised in Pro Yam (which has received mixed reviews), I do not know. At least it's free. Earl H. Kinmonth History Department University of California, Davis Davis, California 95616 916-752-1636 (2300-0800 PDT for FAX) 916-752-0776 (secretary) ucbvax!ucdavis!ucdked!cck (email) cc-dnet.ucdavis.edu [128.120.2.251] (request ucdked, login as guest)
caf@omen.UUCP (Chuck Forsberg WA7KGX) (05/20/89)
In article <25165@coherent.com> dplatt@coherent.com (Dave Platt) writes:
...
:ZMODEM can, at least, deal with situations in which the reverse path
:(receiver-to-transmitter) is not 8-bit-transparent... this covers a
:large percentage of the download-lots-of-data-over-a-network situations.
:This was the purpose for which it was engineered... it was designed to
:permit people to download data, rapidly and effectively, over the sorts
:of packet-switching nets that the people-who-paid-for-its-design were
:running. My impression is that there was less emphasis laid on its
:ability to permit _uploading_ of data over these same networks; I could
:very well be wrong. [Chuck... care to comment, if you're following this
:thread?]
ZMODEM's hex packets are there to allow downloading from timesharing
systems where it is inconvenient or impossible to put the "keyboard"
into a pure 8 bit binary totally transparent mode. ZMODEM's support
for an extensible number of packet formats independent of the higher
level logic of the protocol, and its ability to use whichever of these
types is suited to the situation is unique among the popular protocols.
From its inception ZMODEM was designed with the hooks to allow for
operation over 7 bit networks by adding new packet/frame types.
Wishing to avoid Kermits 7/8 bit handshake problems and Kermit's
slow speed, I have not rushed ahead into territory where I am not
familiar with the types of data files that are most popular.
My current thinking for 7 bit paths is to add two new frame types.
The first would use RLE compression and 8th bit escaping, not
too much different from Kermit except that Kermit escapes ALL
control characters, while this is an option with ZMODEM. This
would be useful for test files that don't have too many
characters >127.
The second would pack N 8 bit characters into N+M bytes either
by shifting of bits or DEC RADIX50 style packing. There are
many tradeoffs between packing efficiency, output character
set, computational intensity, and code portability here, and
suggestions are welcome.
Some grant money to support these developments would also
come in handy.
Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
Omen Technology Inc "The High Reliability Software"
17505-V NW Sauvie IS RD Portland OR 97231 503-621-3406
TeleGodzilla:621-3746 FAX:621-3735 CIS:70007,2304 Genie:CAFles@chinet.chi.il.us (Leslie Mikesell) (05/20/89)
In article <206@bilver.UUCP> bill@bilver.UUCP (Bill Vermillion) writes: >Something doesn't sound right here, to me at least. 17 (decimal) is a control >Q which is a restart after xoff. Control S is decimal 19. The way I see it, >either kermit doesn't use the lower numbers, and sends a 19 for 17 - that >doesn't seem at all logical, or something else is coming in to play. Right, it is control Q but that is generally not passed through links that process xon/xoff flow control. As another posting mentioned it could also be 16 or control P which is sometimes used as Data Link Escape in packet networks. Kermit forces everything into the printable character range by preceding control characters with a prefix character and making the character itself into the printable representation. For example, control-M is sent as #M which is somewhat inefficient but it often works where other methods fail. Most kermits allow similar quoting to done (or not) for characters with the high bit set according to the needs of the transmission medium. Les Mikesell
ked@garnet.berkeley.edu (Earl H. Kinmonth) (05/23/89)
> Hmm, something is wrong with 340. I run Xenix and also use Zmodem > to download/upload from a dos machine that's hard port connected @9600 > and via a TrialBlazier. On hard connected I see 928cps, modem I see > 910cps. Haven't tried 19.2k yet. My connection is quite a bit more complex. ATT 6310 ==> line driver ==> leased line ==> data switch ==> Develnet ==> black hole ==> {SUN | VAX} If anyone is interested, I'll try to generate precise numbers. Having cobbled Sandy Z's CU to work with Zmodem, I've come to use it for most bulk file transfers. I run kermit when I need script capabilities. CU also does something, I'm not sure what, that makes its use as a terminal program very sluggish. kermit is far better on this. Over this link, I've had poor results with kermit and binary files. In fact, I've not been able to get reliable binary transfers unless I use an ascii coding scheme (uuencode, etc.). Zmodem goes fine. I've had no luck whatsoever in {SUN|VAX} ==> MSDOS downloads with binary files unless I go to ascii coding. I've tried a variety of parity settings without luck on {SUN|VAX} -> MSDOS transfers. I will supply the hacked version of CU upon request. Aside from adding an interface to zmodem, I've added a ~C directory command to allow changing the current working directory on the local machine, and a command that allows the escape character to be changed to something other than a tilde. (I have a dumb [moronic] terminal without a tilde.) I will only honor requests mailed to ucbvax!ucdavis!ucdked!cck that give a proper return address in bang!bang!bang format relative to ucbvax. My standard shipping format is tar | compress | uuencode. NOTE BENE (means "note this well" in Latin) if you use the [rR] command to make your request, you'll be using the wrong address, and while the message will get to me, it will be filed in /dev/null! Earl H. Kinmonth History Department University of California, Davis Davis, California 95616 916-752-1636 (2300-0800 PDT for FAX) 916-752-0776 (secretary) ucbvax!ucdavis!ucdked!cck (email) cc-dnet.ucdavis.edu [128.120.2.251] (request ucdked, login as guest)
rwh@me.utoronto.ca (Russell Herman) (05/23/89)
It wasn't until I began adding "-l 1024" to my SZ calls that I was able to get successful downloads to my PC. The path here is really offbeat: host-Develcon-T1-Develcon-modem My guess was that flow-control wasn't happening in real-time with all the intermediaries, so that using "-l" would force explicit handshaking. It takes a bit of a performance hit, but I still get over 200 cps on a 2400 baud modem. Has KERMIT thruput (with its 90+packet size) beat by miles! ______ Russ Herman, SysMgr / \ University of Toronto, Dept. of Mech. Eng. @( ? ? )@ 5 Kings College Rd., Rm. MC 229 ( || ) Toronto, ON Canada M5S 1A4 ( \__/ ) (416) 978-4987 \____/ INTERNET: rwh@me.utoronto.ca UUCP: ..!uunet!utai!me!rwh
leonard@bucket.UUCP (Leonard Erickson) (05/24/89)
In article <24552@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes:
<By the way, am I "wrong" in thinking that the apparent assumption of a
<clear eight-bit path in the [xy]modem protocols represents {naive|
<brain-dead|criminally stupid} programming? Was there something
<different about the world when these protocols were written that a
<clear eight-bit path could be assumed? Maybe because I'm an historian
<and not a programmer, I would start from the assumption that any
<communications protocol ought to have as a fall back option nothing
<better than a BCD character set. (Anything less, and you may as well
<revert to carrier pigeons.)
Xmodem was written by Ward Christenson(sp) back in the late 70's. It was
intended to allow two *people* to xfer files between their personal
computers over a phone line. So complete control of the channel was a
"given". So was operator intervention if things went greviously wrong.
Other oddities of the protocol come from its CP/M origins. 128 byte
blocks were used as that was one sector on a disk.
Xmodem is fine for what it was "designed" for. It's not so hot when ported
to odball environments. (from the viewpoint of it's original users, I'm
sure that mainframes and minis are oddball)
BTW I consider the *non*-availability of a clear 8-bit path to be a
clear indicator of brain damage.
--
Leonard Erickson ...!tektronix!reed!percival!bucket!leonard
CIS: [70465,203]
"I'm all in favor of keeping dangerous weapons out of the hands of fools.
Let's start with typewriters." -- Solomon Shortcaf@omen.UUCP (Chuck Forsberg WA7KGX) (05/25/89)
In article <890518.08250297.029229@CRC.CP6> THOMAS_ERSKINE@DOCCRC.BITNET writes:
:Your problem isn't with X/Y/Z modem; your problem is with the Develnet
:switch. Unless your communications people have disabled the
:speed/parity/code conversion stuff in the switch, it *needs* to be
:able to throttle the line, and it will use XON/OFF. I don't think you
:can tell it to use anything else. You'll have to tell Zmodem to quote
:them or use Kermit. Kermit with long (>=1000) isn't that bad. If
:Zmodem can be convinced to only quote XON/XOFF, then it should be
:faster, but I seem to remember that it wants to quote all
:un-printables, or none.
Actually, ZMODEM escapes XON, XOFF, and DLE in both parities.
This is explained in the ZMODEM protocol document, which
one can read before making possibly inaccurate statements
about ZMODEM.
Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
Omen Technology Inc "The High Reliability Software"
17505-V NW Sauvie IS RD Portland OR 97231 503-621-3406
TeleGodzilla:621-3746 FAX:621-3735 CIS:70007,2304 Genie:CAFWANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho") (05/25/89)
Xmodem was written by Ward Christenson(sp) back in the late 70's. Ward Christensen wrote MODEM, then MODEM2, as described. Keith Petersen modified the program to be used on an unattended Remote CP/M system, and called it XMODEM. Although people dialed into an RCP/M system using the MODEM program and transferred files using the XMODEM program on the remote end, the protocols were basically the same, except the name XMODEM, instead of MODEM, stuck. The correct term is the Christensen Protocol, which applies to the underlying protocol, originally using 8-bit checksums, with the 16-bit CRC option added a short time later. The 1K blocks were added to XMODEM later. The "batch" mode was NOT a part of XMODEM because it was desired to limit connect time, forcing the caller to transfer only those files one by one which would complete in the allotted time. Because the protocol is half-duplex, a clear 8-bit path is required only from sender to receiver. It would have been trivial to have the sending end honor flow control. It simply wasn't needed at the time. --Frank
les@chinet.chi.il.us (Leslie Mikesell) (05/25/89)
In article <769@omen.UUCP> caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: >My current thinking for 7 bit paths is to add two new frame types. >The first would use RLE compression and 8th bit escaping, not >too much different from Kermit except that Kermit escapes ALL >control characters, while this is an option with ZMODEM. This >would be useful for test files that don't have too many >characters >127. > >The second would pack N 8 bit characters into N+M bytes either >by shifting of bits or DEC RADIX50 style packing. There are >many tradeoffs between packing efficiency, output character >set, computational intensity, and code portability here, and >suggestions are welcome. How about sending one packet each direction of the known characters that must be escaped kermit-style (escaped, of course). Some shorthand notation for "all control characters" and "all characters >127" could be used here. Then for compression, how about building packets at least 1K in size and not necessarily alligned with the transmission packets that would have [START-CODE][RLE-PREFIX][ENCODING-METHOD][LENGTH][data....] where RLE-PREFIX would be chosen as the least frequent character in the packet, and the ENCODING-METHOD of choice would use a non-adaptive huffman or LZW compression with the tree built into both ends. If applying this compression does not reduce the size, then ENCODING-METHOD would be set to NONE and sent uncompressed. (Thus you don't have to send the tree, you can recover an interrupted stream, and you never grow more than the packet header when compression doesn't work). This stream would then go into the normal ZMODEM packets. Alternate encoding-methods could be used, perhaps to optimize the output character set to the known restrictions of the link. Les Mikesell