dg@lakart.UUCP (David Goodenough) (03/02/89)
csg@pyramid.pyramid.com (Carl S. Gutekunst) sez:
] 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.
Reading between the lines, if I create a new "g" protocol UUCICO I'd better
keep to 64 byte packets, and a window size of 3 (I think that's how everyone
else does it). If this is the case I'm real glad, as it makes my job about
1000 times easier!!
Am I correct, or way out in left field?
Thanks for any advice,
--
dg@lakart.UUCP - David Goodenough +---+
IHS | +-+-+
....... !harvard!xait!lakart!dg +-+-+ |
AKA: dg%lakart.uucp@xait.xerox.com +---+csg@pyramid.pyramid.com (Carl S. Gutekunst) (03/03/89)
In article <455@lakart.UUCP> dg@lakart.UUCP (David Goodenough) writes: >Reading between the lines, if I create a new "g" protocol UUCICO I'd better >keep to 64 byte packets, and a window size of 3 (I think that's how everyone >else does it). Packet size is stuck at 64, yes. Window size negotiation, on the other hand, *does* work properly, and window size 7 has become common for folks running UUCP over PC Pursuit. So if you want to do a "complete" 'g' implementation, you'll have to do variable window size. But you can also fix your window size at 3, and then only accept 3 at negotiation time. Note that reverse-engineering the 'g' protocol is *damn* hard. Few have done so without making grave sacrifices; UUPC and uuslave, for example, came out supporting only a window size of 1, and gave up under almost any error con- dition that the AT&T 'g' implementation would plow right through. Indeed, the 'g' protocol is by far the biggest stumbling block to producing a PD UUCP. <csg>
jthomp@hemaneh.Central.Sun.COM (Jim Thompson Sun Dallas SWAN Engineer) (03/03/89)
In article <455@lakart.UUCP> dg@lakart.UUCP (David Goodenough) writes: >csg@pyramid.pyramid.com (Carl S. Gutekunst) sez: >] 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. >o True. There are hardwired constants in places, and fixed size buffers. >] 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. >Reading between the lines, if I create a new "g" protocol UUCICO I'd better >keep to 64 byte packets, and a window size of 3 (I think that's how everyone >else does it). If this is the case I'm real glad, as it makes my job about >1000 times easier!! >Am I correct, or way out in left field? Well, y're half-right. You have to keep the 64 byte packets, but you can have more than 3 windows. (7 is typically a 'good' number.) There is, at this point, no way to fix the packet size handshake. (But why would you want to create a new 'g' protocol? You might impliment a cleaner version, but a 'new g'? Hardwired constants and fixed size buffers have nothing to do with it. The handshake code is broken, always has been. No way to fix it now. What we really need, is a good 'SLIP' modem, and dial-up slip service. Then we could use SMTP, and NNTP, and do away with uucp, (for the most part.) Jim Thompson jthomp@central.sun.com "I woudn't recommend sex, drugs, or insanity Network Engineering for everyone, but they've always worked for me." Sun Microsystems -- Hunter S. Thompson
steve@pnet51.cts.com (Steve Yelvington) (03/05/89)
csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >Note that reverse-engineering the 'g' protocol is *damn* hard. Few have done >so without making grave sacrifices; UUPC and uuslave, for example, came out >supporting only a window size of 1, and gave up under almost any error con- >dition that the AT&T 'g' implementation would plow right through. Indeed, the >'g' protocol is by far the biggest stumbling block to producing a PD UUCP. > ><csg> John Logajan (logajan@logajan.mn.org) has written a PD UUCP mailer for the Atari ST in -- get this -- BASIC. I believe it uses a window size of 3, and was written from UUCP documentation, not based on preexisting code. I have not tried it, but others who have say it works just fine. I'm using an ST program called UUMAIL that grew out of UUSLAVE and shares its limitations of a window size of 1 and a propensity to cry "uncle" when the going gets rough. UUCP: {uunet!rosevax,amdahl!bungia,chinet,killer}!orbit!pnet51!steve ARPA: crash!orbit!pnet51!steve@nosc.mil INET: steve@pnet51.cts.com ----------- -or- stag!thelake!steve@pwcs.StPaul.GOV "A member of STdNET -- the ST Developers' Network"
sl@van-bc.UUCP (pri=-10 Stuart Lynne) (03/06/89)
In article <61288@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >Note that reverse-engineering the 'g' protocol is *damn* hard. Few have done >so without making grave sacrifices; UUPC and uuslave, for example, came out >supporting only a window size of 1, and gave up under almost any error con- uupc supports a window size of 7. >dition that the AT&T 'g' implementation would plow right through. Indeed, the >'g' protocol is by far the biggest stumbling block to producing a PD UUCP. The g protocol stuff in uupc is quite sound. Adding some additional error recovery wouldn't be too hard. uupc's main problems lie with lack of documentation and a horrible user interface. -- Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl Vancouver,BC,604-937-7532
rpw3@amdcad.AMD.COM (Rob Warnock) (03/10/89)
In article <406@texsun.Sun.COM> jthomp@hemaneh.UUCP writes: +--------------- | What we really need, is a good 'SLIP' modem, and dial-up slip service. | Then we could use SMTP, and NNTP, and do away with uucp, (for the most part.) +--------------- I think we already have good modems. Consider the following configuration: 1. One end: PC/AT clone running Phil Karn's "KA9Q" TCP/IP code, speaking SLIP over COM1 at 9600 baud. 2. Other end: VAX-11/780 running 4.3bsd, with SLIP driver, on 9600-baud DH-11 port. (The SLIP driver was *slightly* hacked by me to add proper carrier-detect & SIGHUP support.) 3. Telebit Trailblazer+ on both ends. 4. KA9Q's "TCP Max Seg Size" set to 512, "TCP Window Size" set to 4096. I have measured large FTP file transfers (100K+) at 880 bytes/sec of user data (that is, FileSize/ElapsedTime = 880). The best I have ever seen between Unix systems, even using the TB+'s UUCP mode, was a little over 800 bytes/sec at 9600 baud. The sustained transfer rate was somewhat sensitive to the "Max Seg Size" and "Window Size" settings of the "KA9Q" code. I tried a number of variations before settling on the above settings, which seem fairly robust in the FTP environment. I don't know what throughput I would have gotten between two 4.3bsd systems running SLIP on TB+'s. (Anybody want to try it and report?) p.s. Note that you don't really want a "SLIP modem"; what you really want is SLIP header compression in the hosts, to keep the chatter off the async line in the first place. That way, you might be able to get reasonable Telnet performance. Sad to say, the KA9Q/SLIP/TB+/TB+/SLIP/4.3 combo gives *abyssmal* Telnet interactive performance even at 9600 (though full-screen refresh is just fine). That's probably because a single typed character causes 43 bytes of data on the line (SLIP Start_Frame, IP, TCP, the byte, SLIP End_Frame), which causes the TB+'s to go into "unidirectional mode" with a turn-around time of ~1 sec., instead of the 7 (9?) times/sec ping-pong they do when you're using them as normal terminal modems. With SLIP header compression in the hosts, a single typed character would yield maybe 3-4 characters on the line, which wouldn't pop the TB+ out of ping-pong mode, and Telnet would win. p.p.s. SLIP is one place the "true" full-duplex of v.32 probably wins a lot over PEP. Anybody got a pair of v.32 modems they can try a Telnet/SLIP connection over? Rob Warnock Systems Architecture Consultant UUCP: {amdcad,fortune,sun}!redwood!rpw3 ATTmail: !rpw3 DDD: (415)572-2607 USPS: 627 26th Ave, San Mateo, CA 94403