Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!hellgate.utah.edu!dog.ee.lbl.gov!nosc!crash!simpact!jeh From: jeh@dcs.simpact.com Newsgroups: comp.mail.uucp Subject: Re: How efficient/fast is uucp? Message-ID: <1565.26d6609c@dcs.simpact.com> Date: 25 Aug 90 18:27:24 GMT References: <8464@pitt.UUCP> <1556.26d282ea@dcs.simpact.com> <1990Aug24.152938.7413@chinet.chi.il.us> Organization: Simpact Associates, San Diego CA Lines: 92 In article <1990Aug24.152938.7413@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: > This is true for direct connections with "real" full duplex modems where the > turn-around time for the ack packets is insignificant. However, many > connections currently happen over packet-switched networks, satellite links, > and/or modems that pretend to be full duplex but actually take some time > to switch directions. Then you can end up waiting for the ack's and > reducing throughput. These links provide an error-free path, no? There is already the "f" protocol which is intended for use through mostly-error-free, flow-controlled links. It sends a single checksum at the end of the entire file, relying on the network to get the data through and relying on the fact that while the RS232 (or whatever) connection to your local modem may not be perfect it is quite close. > Older g's allow a 3-packet window that can be sent > before the ack's get back, newer ones allow 7 which is the limit for > the g protocol field that specifies the number. You could hack 'g' fairly readily to allow larger fields for the packet number. While you're at it you'd better add selective retransmit, aka receive window size > 1, to reduce the cost of retransmission when errors occur. > On top of this, there is the non-windowed > per-file handshake and the fact that mail messages carry along a second > small file for the uuxqt command. Increasing the packet size or window > wouldn't help much with mail transfers, since the files often don't > fill the existing window. Note: this applies to trailblazers as well, > although you have to look at real connect time to see it - the xferstats > don't count the per-file handshake time. yup! > The big hangup here is that you need a source license to begin with, and > then you can't distribute copies. Does anyone have a HDB compatible > uucico that can be freely distributed? well, how "compatible" does it have to be? DECUS uucp uses old-style spool file names and a single spool directory but talks to HDB systems just fine. It also has the best login and dialer scripting capability of any uucp arround (not just my opinion). Of course it's written for VMS, but someone told me they ported the g protocol module to MS-DOS in just two days and are getting first-class performance with it, so that can't be too much of a drawback. "Freely distributed"? It used to be based on gnuucp, but the gnu folks tell me that their version has diverged wildly from what they originally sent me, and our version has too (I completely threw away their 'g' implementation and did a whole new one that does windowing, for a start), so I have declared it to be in the public domain. We are going to go to neighbor-system-specific spool directories for the next release. (Right, Mark? :-) HDB-style permissions files are so bizarre that we'll be doing something different. > I'd like to see a protocol where you could specify a minimum and > maximum packet and window size per host, device and dialer. we support this in 'g' via an options field in the entries in the systems file. > Also, file boundaries should stream through the window. This is clearly impossible for "pull-mode" ("I want to receive..."), since the slave can't very well start sending a file until it receives your request for it! But the vast majority of traffic (there I go again) is push- mode, and it would certainly be possible to start sending the file immediately after sending the "I want to send you this file" command, without waiting for a yea or nay. You could assign a simple id code to each file sent during a call; this would be sent in the S command and also in the header for each data block for the file. If the receiving system rejects an S command it would simply drop any data packets containing the same id code. I agree with you about the performance hit for small files, and doing something about it at uucp level sounds like a hell of a good idea. I've seen too many small mail messages (and X files for both mail and news) go through my trailblazer with an effective throughput in the real of 100 char/sec! (Our throughput reporting DOES take the beginning- and end-of-file overhead time into account. 50 Kbyte news batches do hit it up at around 1200-1400.) Unfortunately, in order to use this with TrailBlazer modems, we'd have to abandon their fabled 'g' protocol spoofing. a TB in g-spoof mode not only "knows about" the data link level, it looks for and interprets the "messages" (S, SY, CY, etc.) that mark the beginning and end of a file transfer. It has to, because it has to know to flush its buffers and prepare for line turnaround when the sending system sends the last packet of a file. Another way to fix it would be (for mail) to go to BSMTP, and (for news) to hack uuxqt to allow multiple commands per X file. Then you could send all of your 50 Kbyte news batches and just one (still fairly small) X file. --- Jamie Hanrahan, Simpact Associates, San Diego CA Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG Internet: jeh@dcs.simpact.com, or if that fails, jeh@crash.cts.com Uucp: ...{crash,scubed,decwrl}!simpact!jeh