zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (02/27/89)
In article <[1861.5]karl@ddsw1.comp.ibmpc;1> karl@ddsw1.MCS.COM ([Karl Denninger]) writes: >Without help the HSTs do TERRIBLY on uucp calls, as the back-channel is not >big enough to pass the "acks" without turning around the line. > It's too bad that current implementations of uucp have problems with using larger packet sizes. The packet size information is exchanged during the handshake process, but something isn't handled quite right. Maybe some combinations work - HDB/HDB or BSD/BSD. We need a good PD uucp implementation that does it right. A 256 byte packet size would make a big difference for HST modems (the ack would fit in the back channel) and for people using PC Pursuit. -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Ann Arbor, MI mailrus!b-tech!zeeff
csg@pyramid.pyramid.com (Carl S. Gutekunst) (02/28/89)
In article <5138@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >The packet size information is exchanged during the handshake process, but >something isn't handled quite right. True. There are hardwired constants in places, and fixed size buffers. >Maybe some combinations work - HDB/HDB or BSD/BSD. Nope. Sometimes you get lucky, but that's about it. >We need a good PD uucp implementation that does it right. Several people have done this in their own UUCP's. Just don't call your new protocol 'g', or you'll break all the existing implementations. The better solution for modems like the HST is a streaming protocol, like 'f' but more robust and less overhead. I keep toying with this idea, as does Rick Adams, but we never get around to an implementation. <csg>
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (03/02/89)
In article <60827@pyramid.pyramid.com> csg@pyramid.UUCP (Carl S. Gutekunst) writes: | Several people have done this in their own UUCP's. Just don't call your new | protocol 'g', or you'll break all the existing implementations. The better | solution for modems like the HST is a streaming protocol, like 'f' but more | robust and less overhead. I keep toying with this idea, as does Rick Adams, | but we never get around to an implementation. One existing protocol which does very well at this is zmodem. Rather than invent a new protocol, perhaps this could be added. It was designed to run of long delay networks, and the back traffic is minimal. Maybe someone could suggest that UNIX international push on AT&T a little and see if a new *standard* protocol could be added to HDB. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
csg@pyramid.pyramid.com (Carl S. Gutekunst) (03/02/89)
>In article <60827@pyramid.pyramid.com> csg@pyramid.UUCP (Carl S. Gutekunst) writes: >The better solution for modems like the HST is a streaming protocol, like >'f' but more robust and less overhead. I keep toying with this idea, as >does Rick Adams, but we never get around to an implementation. In article <13275@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > One existing protocol which does very well at this is zmodem. Rather >than invent a new protocol, perhaps this could be added. This is exacly what Rick and I were originally planning. After some study of the zmodem protocol, however, I've decided against it. The zmodem protocol is strictly for practically error free channels like X.25; error recovery is expensive. It also requires 8-bit transparency. What I want -- and I have the groundwork of a design -- is a streaming protocol that provides fairly cheap error correction, and is thus suitable over a variety of media, including standard non-intelligent modems. The protocol would also have to be extensible, so new features could be added without breaking existing installations. One place it would not work is really trashy dialup lines; but that's what we have 'g' protocol for. :-) <csg>
rkh@mtune.ATT.COM (Robert Halloran) (03/02/89)
In article <13275@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >In article <60827@pyramid.pyramid.com> csg@pyramid.UUCP (Carl S. Gutekunst) writes: > >| Several people have done this in their own UUCP's. Just don't call your new >| protocol 'g', or you'll break all the existing implementations. The better >| solution for modems like the HST is a streaming protocol, like 'f' but more >| robust and less overhead. I keep toying with this idea, as does Rick Adams, >| but we never get around to an implementation. > > One existing protocol which does very well at this is zmodem. Rather >than invent a new protocol, perhaps this could be added. It was designed >to run of long delay networks, and the back traffic is minimal. > > Maybe someone could suggest that UNIX international push on AT&T a >little and see if a new *standard* protocol could be added to HDB. Unfortunately for this line of thought, the impression is that the features being added to SysV are driven by the standards organizations (IEEE POSIX, ANSI C, etc.) and the existing Unix applications market (BSD networking, XENIX binary compatibility for Intel CPU's). The fact that zmodem is a up and coming protocol in the DOS world probably would make no difference to them, since that's not where their interests lie. Bob Halloran ========================================================================= UUCP: att!mtune!rkh Internet: rkh@mtune.ATT.COM USPS: 17 Lakeland Dr, Port Monmouth NJ 07758 DDD: 201-495-6621 eve ET Disclaimer: If you think AT&T would have ME as a spokesman, you're crazed. Quote: "May: In Baton Rouge, the Rev. Jimmy Swaggart, announcing that he has been forgiven by the Lord, returns to his pulpit, where he receives a warm reception from 300 billion locusts." - Dave Barry's 1988 Year-In-Review
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (03/03/89)
From a coding point of view, it seems alot easier to fix the problems
with 'g' at larger packet sizes that to create a whole new protocol.
I'd guess that with a days effort, someone could make these modems
with small reverse channels work efficiently. Uucp has some exchange
that indicates what packet sizes an implementation can use - if it
doesn't do it right, I agree, a new protocol letter should be used.
Come on AT&T, fix 'g' larger packet sizes in Sys V.4.
--
Jon Zeeff zeeff@b-tech.ann-arbor.mi.us
Ann Arbor, MI mailrus!b-tech!zeeff
----- Use lint! -----