csg@pyramid.pyramid.com (Carl S. Gutekunst) (01/24/88)
In article <567@acornrc.UUCP> bob@acornrc.UUCP (Bob Weissman) writes: >Can someone tell me the effect of tweaking the "packet size" and >"number of windows" parameters in UUCP? Sure. You'll break it. :-) >E.g., are there settings which are appropriate for different transmission >speeds? Will responding hosts understand different (presumably larger) >packet sizes? What's a "window" anyway? The uucico 'g' protocol is characterized as "packetized, sequenced, windowed" meaning that: - The data to be transferred is fragmented into packets; - Each packet has a sequence number and the packets must arrive in sequence; - A number of packets can be sent back-to-back without acknowledgement. The space into which these packets fit is called the "window," and the maximum number of unacknowledged packets is called the "window size." The advantage is parallelism: new packets can still be arriving while old acks are being calculated and sent. In uucico pk.h, the usual window size is 3, and the packet size is 64. You *can* increase the window size up to 7, and the two sites will negotiate the actual window size (based on who has the highest maximum). This has very little effect when using normal modems; it is a big win when the 'g' protocol is used on dialup public data networks (for example, PC Pursuit). It also helps with packetized modems, including MNP modems. You *cannot* increase the packet size beyond its current limit of 64. Although the protocol supports packets up to 4096, no UUCP version in use to date has buffers to handle anything bigger than 64. So if you increase the packet size and buffer sizes on your end, you will core dump the uucico on the other end. <csg>
paul@vixie.UUCP (Paul Vixie Esq) (01/25/88)
In article <13668@pyramid.pyramid.com> csg@pyramid.UUCP (Carl S. Gutekunst) ^^^^^^^^^^^^^^^^^^^ writes: You like to publicize that name, huh? :-) :-) >You *cannot* increase the packet size beyond its current limit of 64. Although >the protocol supports packets up to 4096, no UUCP version in use to date has >buffers to handle anything bigger than 64. So if you increase the packet size >and buffer sizes on your end, you will core dump the uucico on the other end. What if both sides have increased their buffer & packet sizes? And why don't the two cico's negotiate packet size in addition to window size -- i.e., use the largest size that both sides can support? Are we ready for 'h' protocol (or whatever letter we're up to?) :-) (Just discovered ca.unix today...) -- Paul A Vixie Esq paul%vixie@uunet.uu.net {uunet,ptsfa,hoptoad}!vixie!paul San Francisco, (415) 647-7023
rick@seismo.CSS.GOV (Rick Adams) (01/25/88)
There is a bug in every uucico that I have ever seen that is derived from ATT code (i.e. damned near everyone) where the protocol will netgotiate a packet bigger than it can handle. It will then happily bus error. I have not figured out a way to negotiate the packet size that is backwards compatible with all those broken 'g' protocol drivers. So, yes, to negotiate the packet size you would have to do a new protocol. If you're going to do that, you might as well implement something like the zmodem protocol. (Its been on my todo list for over 2 years) --rick
csg@pyramid.pyramid.com (Carl S. Gutekunst) (01/25/88)
>>You *cannot* increase the packet size beyond its current limit of 64. > >What if both sides have increased their buffer & packet sizes? It works just fine. Or, at least it does using 4.3BSD. >And why don't the two cico's negotiate packet size in addition to window size? They try to. But the packet negotiation code is broken, and fixing it renders you incompatible with standard 'g'. We just lucked out that window size nego- tiation works. >Are we ready for 'h' protocol (or whatever letter we're up to?) :-) Rick Adams did a protocol called 'G' that fixed the 'g' bugs. We were consid- ering it as a way to improve throughput on the Telebit TrailBlazer, but Peter Honeyman's 'g' in the modem made this unnecessary. I'm now looking at the Z- modem streaming protocol, since it is a win on X.25 as well as on packetized modems. Even the new & improved 'G' is excessively expensive over X.25 PDNs. >In article <13668@pyramid.pyramid.com> > ^^^^^^^^^^^^^^^^^^^ >You like to publicize that name, huh? :-) :-) Well, it certainly makes more sense than dec.pyramid.com, or hp.pyramid.com, or cci.pyramid.com, or gould.pyramid.com, or.... :-) :-) <csg>
egisin@orchid.waterloo.edu (Eric Gisin) (01/27/88)
In article <44231@beno.seismo.CSS.GOV>, rick@seismo.CSS.GOV (Rick Adams) writes: > So, yes, to negotiate the packet size you would have to do > a new protocol. If you're going to do that, you might as > well implement something like the zmodem protocol. (Its been > on my todo list for over 2 years) What's the advantage of the zmodem protocol? I have Chesson's paper on uucp but am not familiar with zmodem.
alen@cogen.UUCP (Alen Shapiro) (01/30/88)
In article <12263@orchid.waterloo.edu> egisin@orchid.waterloo.edu (Eric Gisin) writes: >In article <44231@beno.seismo.CSS.GOV>, rick@seismo.CSS.GOV (Rick Adams) writes: >> So, yes, to negotiate the packet size you would have to do >> a new protocol. If you're going to do that, you might as >> well implement something like the zmodem protocol. (Its been >> on my todo list for over 2 years) > >What's the advantage of the zmodem protocol? >I have Chesson's paper on uucp but am not familiar with zmodem. Sorry to jump into the middle of this (our net access has been out of sorts for a bit) so I hope this is relevant. ukc (University of Kent U.K.) have had a version of uucp (I believe it is a p.d. version) that one can specify both packet-size and # of windows in the L.sys file. By tuning these fields I've been able to get our 2400baud tx light to remain on pretty steadily (with a regular rx ack flash that sometimes skips a beat but so what cos when the window param is set correctly, tx remains on). I made a small mod to the L.sys language that allows for a timeout time specification so now it even queues connects over gandalf-like concentrators that are fairly busy (it sits in the queue like a user when no connect lines are free). If anyone would like details, mail me direct and I'll see a) if ukc have a more up-to-date version (mine is a coupla years old) and b) if ukc would mind me sending copies. It's the best thing since sliced chips --alen the Lisa slayer (it's a long story) ps anyone at ukc wanna comment? .....seismo!esosun!cogen!alen
lmjm@doc.ic.ac.uk (Lee McLoughlin) (01/31/88)
The version I support over here (UKUUCP) has the capability to change the packet & window size when talking to itself at the remote end. It does this by sending across some more options in the pre-protocol messages. It doesn't negotiate. We've found that by playing with the numbers (they can be set in the L.sys file) you can dramatically improve thru' put over the X.25 networks used heavily in the UK. Lee.
neil@ist.CO.UK (Neil Todd) (02/05/88)
In article <398@cogen.UUCP>, alen@cogen.UUCP (Alen Shapiro) writes: . . > ukc (University of Kent U.K.) have had a version of uucp (I believe it > is a p.d. version) that one can specify both packet-size and # of windows > in the L.sys file. By tuning these fields I've been able to get our > 2400baud tx light to remain on pretty steadily (with a regular rx ack > flash that sometimes skips a beat but so what cos when the window param > is set correctly, tx remains on). . . > if ukc would mind me sending copies. > > It's the best thing since sliced chips > > --alen the Lisa slayer (it's a long story) > > ps anyone at ukc wanna comment? > OK, not a UKC comment but:- UKUUCP is not written by UKC, is derives for HB (I believe), much of the dirty work was done by Lee McLoughlin <lmjm@doc.ic.ac.uk> currently at Imperial College in London. The majority of sites in the UK use it. Zillions of bug fixes, plus improved structure of L.sys file, additional protocols (currently g,f and t I think), runs nicely over X25 lines. New release is currently on the cards, as for getting it that is possibly a problem is it is NOT PD. Neil [neil@ist.co.uk <- preferred [neil@ist.uucp [{backbone}!ist.co.uk!neil
wnp@dcs.UUCP (Wolf N. Paul) (02/18/88)
In article <157@istop.ist.CO.UK> neil@ist.CO.UK (Neil Todd) writes: >OK, not a UKC comment but:- UKUUCP is not written by UKC, is derives >for HB (I believe), much of the dirty work was done by >Lee McLoughlin <lmjm@doc.ic.ac.uk> currently at Imperial College >in London. The majority of sites in the UK use it. Zillions of bug >fixes, plus improved structure of L.sys file, additional protocols >(currently g,f and t I think), runs nicely over X25 lines. > >New release is currently on the cards, as for getting it that is >possibly a problem is it is NOT PD. If getting it is a problem, and it is not PD, how come the majority of sites in UK use it? Are the majority of sites in UK source licenced? If not, how do they get it? A definitive and authoritative comment from UKC would still be welcome! -- Wolf N. Paul Phone: (214) 306-9101 (h) (214) 404-8077 (w) 3387 Sam Rayburn Run UUCP: ihnp4!killer!{dcs, doulos}!wnp Carrollton, TX 75007 INTERNET: wnp@dcs.UUCP ESL: 62832882 Pat Robertson does NOT speak for all evangelical Christians--not for me, anyway!
csg@pyramid.pyramid.com (Carl S. Gutekunst) (02/23/88)
>In article <398@cogen.UUCP>, alen@cogen.UUCP (Alen Shapiro) writes: > ukc (University of Kent U.K.) have had a version of uucp (I believe it > is a p.d. version) that one can specify both packet-size and # of windows > in the L.sys file. The "packet and window size" in UKUUCP refers to the X.25 packet and window size, negotiated all call request time by the two X.25 DTEs. It is entirely different from the uucico 'g' protocol window and packet size. In fact, when to X.25 sites connect, they aren't using 'g' protocol at all; they use 'f'. A pity they had to add another field to L.sys to do this. I rather like the way we do it here, with subfields in the fifth field: pyramid Any PAD 9600 311040800000,W7,P256 ogin:--ogin: which allows any X.25 facilities to be specified, not just packet and window size. And to get the variable bit protocols, I'd rather follow in the steps on HDB by using the protocol subfield after the caller, e.g., "ACU,6". But alas, our UUCP won't talk to ukc. I'm going to find out why, someday.... In article <157@istop.ist.CO.UK> neil@ist.CO.UK (Neil Todd) writes: >UKUUCP is not written by UKC, it derives for HB (I believe).... No, it is based on 4.2BSD UUCP. And of course the base code is proprietary to AT&T. However, if you can prove you have a source license, you can get it for free. So you might say that UKC's modifications are PD. And any site that has a source license can compile it for a neighboring site that has only a binary license, and give them the binary. <csg>
neil@ist.CO.UK (Neil Todd) (02/23/88)
From article <19@dcs.UUCP>, by wnp@dcs.UUCP (Wolf N. Paul): > In article <157@istop.ist.CO.UK> neil@ist.CO.UK (Neil Todd) writes: . . > >New release is currently on the cards, as for getting it that is > >possibly a problem is it is NOT PD. > > If getting it is a problem, and it is not PD, how come the majority of sites > in UK use it? Are the majority of sites in UK source licenced? If not, how > do they get it? > > A definitive and authoritative comment from UKC would still be welcome! Still not UKC - but UKUUCP has been set up to allow binary distribution, but still to have a lot of tailorability (horrible word!). This might be the answer to the availability problem. Many sites in the UK are universities and thus do have source licences. Neil Neil@ist.co.uk <- preferred Neil@ist.uucp {backbone}!ist!neil
heiby@mcdchg.UUCP (Ron Heiby) (02/24/88)
Carl S. Gutekunst (csg@pyramid.UUCP) writes: > And any site that has > a source license can compile it for a neighboring site that has only a binary > license, and give them the binary. I think that this should be checked before being acted upon. Once upon a time, I asked about doing just such a thing. (It was even in the context of UUCP!) The answer I got was that the source site must have a Binary Redistribution Agreement (called "Customer Provisions", I believe, whatever that means) with AT&T in order to distribute binaries derived from licensed software. Not only that, but said source site would be liable to AT&T for an additional binary royalty, even if the recipient of the program already had a copy from a different vendor and had already paid a binary royalty. I haven't kept track of AT&T's licensing policies and am not a lawyer. I'm just suggesting that you check before getting into trouble. -- Ron Heiby, heiby@mcdchg.UUCP Moderator: comp.newprod & comp.unix "Intel architectures build character."
phil@amdcad.AMD.COM (Phil Ngai) (02/25/88)
In article <4684@mcdchg.UUCP> heiby@mcdchg.UUCP (Ron Heiby) writes: <Carl S. Gutekunst (csg@pyramid.UUCP) writes: << And any site that has a source license can compile it for a neighboring << site that has only a binary license, and give them the binary. < <I think that this should be checked before being acted upon. Once upon a time, <I asked about doing just such a thing. (It was even in the context of UUCP!) <The answer I got was that the source site must have a Binary Redistribution <Agreement (called "Customer Provisions", I believe, whatever that means) with <AT&T in order to distribute binaries derived from licensed software. Not only <that, but said source site would be liable to AT&T for an additional binary <royalty, even if the recipient of the program already had a copy from a <different vendor and had already paid a binary royalty. I have asked AT&T about this also and Ron is correct. Quite simply, _you_ must license a machine before _you_ put any AT&T Unix code on it, whether source or binary, it must be licensed appropriately. The fact that someone else has already licensed the same machine for Unix is as irrelevant as the same machine having an MSDOS license. Think of it as a license for you to perform the act of putting the code on the machine, not as a license for the machine. Only the license holder is permitted to install a Unix derived program. I do not know how well such a policy can be enforced. But we play by the rules at my company. Who wants to tangle with AT&T lawyers? If it seems like a rip off, complain to AT&T. -- I speak for myself, not the company. Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com
rob@philabs.Philips.Com (Rob Robertson) (02/25/88)
In article <4684@mcdchg.UUCP> heiby@mcdchg.UUCP (Ron Heiby) writes: |Carl S. Gutekunst (csg@pyramid.UUCP) writes: |> And any site that has |> a source license can compile it for a neighboring site that has only a binary |> license, and give them the binary. >I think that this should be checked before being acted upon. Once upon a time, >I asked about doing just such a thing. (It was even in the context of UUCP!) >The answer I got was that the source site must have a Binary Redistribution >Agreement (called "Customer Provisions", I believe, whatever that means) with >AT&T in order to distribute binaries derived from licensed software. Not only >that, but said source site would be liable to AT&T for an additional binary >royalty, even if the recipient of the program already had a copy from a >different vendor and had already paid a binary royalty. at the usenix berkeley bof, it was mentioned that UC Berkeley was trying to license their microvaxen for 4.3 binaries. since microvaxen are sold with an OS (either vms or ultrix), berkeley asked at&t if they got ultrix, could they put 4.3 on them and not have to pay additional license fees (since both stem from 4.2, which contain the SAME original at&t source code). at&t said no, they would have to pay $400 a unit to put 4.3 on them. more and more the GNU project looks alot better to me. rob -- william robertson rob@philabs.philips.com
lmjm@doc.ic.ac.uk (Lee McLoughlin) (02/28/88)
In article <19@dcs.UUCP> wnp@dcs.UUCP (Wolf N. Paul) writes: >In article <157@istop.ist.CO.UK> neil@ist.CO.UK (Neil Todd) writes: > >OK, not a UKC comment but:- UKUUCP is not written by UKC, is derives > >for HB (I believe), much of the dirty work was done by > >Lee McLoughlin <lmjm@doc.ic.ac.uk> currently at Imperial College > >in London. The majority of sites in the UK use it. Zillions of bug > >fixes, plus improved structure of L.sys file, additional protocols > >(currently g,f and t I think), runs nicely over X25 lines. > > > >New release is currently on the cards, as for getting it that is > >possibly a problem is it is NOT PD. > >If getting it is a problem, and it is not PD, how come the majority of sites >in UK use it? Are the majority of sites in UK source licenced? If not, how >do they get it? > >A definitive and authoritative comment from UKC would still be welcome! Well I'm sort of the author will I do? I'm not too sure what this conversation is about but ... Its widely available in the UK because all the source licensed academic sites use it, most of the UK unix vendors supply it with there machines in place of the standard version. In fact Unisoft - then Root Computers - the major 'porter of USG gave me machine time to develope it in its early days. They helped to make it widely available on sys3, sys5 machines in the UK. Other vendors have been persuaded to supply binaries by customers. It was originally based on V7 uucp. Every useful patch ever seen on the net has been installed. Given that it went up on a lot of novel architecture machines a lot of other bugs were fixed. Lots of people, 40-50 at the last count, contributed fixes or enhancements. Lastly I am a complete workaholic and spent more time working on it than I care to think about! It is not PD. You'd need a V7 source license or better to get it. I used to keep all the license photocopies till my desk started getting full. A new release is pending. I've just spent time in hospital, hence the delay. It may be the last. I'd like to upgrade uupc to be compatiable. Then no more license problems! If anyone else is interested, mail me. Lee
lmjm@doc.ic.ac.uk (Lee McLoughlin) (02/28/88)
In article <15322@pyramid.pyramid.com> csg@pyramid.UUCP (Carl S. Gutekunst) writes: >> ukc (University of Kent U.K.) have had a version of uucp (I believe it >> is a p.d. version) that one can specify both packet-size and # of windows >> in the L.sys file. > >The "packet and window size" in UKUUCP refers to the X.25 packet and window >size, negotiated all call request time by the two X.25 DTEs. It is entirely >different from the uucico 'g' protocol window and packet size. In fact, when >to X.25 sites connect, they aren't using 'g' protocol at all; they use 'f'. As I mentioned in a recent posting UKUUCP IS NOT PD. The packet and window size do refer to the 'g' protocol - NOT the X25 packet and window driver. Not all X.25 sites use 'f' some still use 'g' depending on how they access X.25 in the first place. There is an X25 device driver in UKUUCP to control a York-Box. UKC doesn't use this. You have to get it seperately from the main distribution from one of the two sites who use it. > >A pity they had to add another field to L.sys to do this. I rather like the >way we do it here, with subfields in the fifth field: I could almost agree with this. But the login script under UKUUCP is quite different as well. So it doesn't really make much difference. UKUUCP pre-dates HDB by a long time (its V7 based after all!) so I didn't have its lead to follow. > >But alas, our UUCP won't talk to ukc. I'm going to find out why, someday.... > Well I've not had many problems with any version I've come across unless they redefine some of the initial protocol flags. Eg EUUG-UUCP uses the -p flag for some purpose that clashes with UKUUCP. We just don't exchange this flag. >In article <157@istop.ist.CO.UK> neil@ist.CO.UK (Neil Todd) writes: >>UKUUCP is not written by UKC, it derives for HB (I believe).... > See my other posting for details about UKUUCP. Message-ID: <210@gould.doc.ic.ac.uk> Date: 27 Feb 88 17:11:52 GMT If you have any queries about it please mail me. Lee -- UKUUCP SUPPORT Lee McLoughlin "What you once thought was only a nightmare is now a reality!" Janet: lmjm@uk.ac.ic.doc, lmcl@uk.ac.ukc DARPA: lmjm@doc.ic.ac.uk (or lmjm%uk.ac.ic.doc@nss.cs.ucl.ac.uk) Uucp: lmjm@icdoc.UUCP, ukc!icdoc!lmjm
rpa@eagle.ukc.ac.uk (R.P.Almeida) (02/29/88)
This is NOT an definite or authorative UKC reply, as i'm a student here.
UUPC works fine when talking to UUUCP using 'g' protocol.
The only thing that needed altering was the timeout after UUPC has
requested my HAYES compatible modem to dial, till it has connected.
That was becuase we still have to use pulse dialing in most of the UK,
and obviously that takes much longer then tone dialing.
UKUUCP also has an extra feature enabling communications over non
8 bit networks. (datawidth code)
On sites running UKUUCP here, there can be 5 'uucp' logins :-
uucp uucp4 uucp6 uucp7 uucpf
If you have a 4 bit datapath, then you log in as 'uucp4' , a 7 bit path
then 'uucp7' etc.
These logins have default shells of uucico , uucico.4 , uucico.6
uucico.7 and uucico.f respectively. All five of these are infact links
to the same program (uucico).
uucico looks at the name it was called by, and sets its datawidth
appropriatly.
uucico.f uses a flow control protocol for working over links that are
(almost) error free. (eg direct links or X25 links) using a 7 bit wide
protocol.
I suppose this was added to UKUUCP because most of the UK's universities
are connected together by a X25 network called JANET.
I had started to add code to do the above 'datawidth' stuff to UUPC , working
on my Amiga, but then my Amiga broke, and now my Finals have caused the idea
to be shelved. (probably permanantly, as soon i shall no longer be a student).
Richard Almeida.
!mcvax!ukc!rpa
rpa@ukc.UUCP
rpa@ukc.ac.uk
This is virtually all from memory, so i hope its accurate.andys@genesis.ATT.COM (a.b.sherman) (02/29/88)
In article <20522@amdcad.AMD.COM> phil@amdcad.UUCP (Phil Ngai) writes: > [description of AT&T software licensing practices] >I do not know how well such a policy can be enforced. But we play by >the rules at my company. Who wants to tangle with AT&T lawyers? > >If it seems like a rip off, complain to AT&T. > >-- >I speak for myself, not the company. > >Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com We play by the rules at AT&T too. We pay for AMD chips (unless they're samples :-) ) and we don't try to copy AMD designs. Getting a fair return for the expense of developing software is no more a ripoff than getting a fair return for developing chips. If chips were as easy to copy as programs, you'd find yourself in the same boat we are in. -- andy sherman / at&t bell laboratories (medical diagnostic systems) room 2h-097 / 480 red hill road / middletown, nj 07748 (201) 615-5708 / andys@shlepper.ATT.COM ...The views and opinions are my own. Who else would want them?
lmjm@doc.ic.ac.uk (Lee McLoughlin) (03/01/88)
In article <3313@briar.Philips.Com> rob@philabs.Philips.Com (Rob Robertson) writes: >|> a source license can compile it for a neighboring site that has only a binary >|> license, and give them the binary. > >>I think that this should be checked before being acted upon. Once upon a time, >>I asked about doing just such a thing. (It was even in the context of UUCP!) ... >>royalty, even if the recipient of the program already had a copy from a >>different vendor and had already paid a binary royalty. Its daft licensing like this that convinced me to start on a PD version of uucp some time ago. I was beaten to it by uuslave and friends (which came out while I was still arguing with various people about a whole bunch of legal wrangles to do with duplicating the uucp protocols - something deeply ironic there). I plan on trying to make something as powerful as UKUUCP but based on uupc(?) - time permitting. Then I can post it! Make life so much easier. Lee. -- UKUUCP SUPPORT Lee McLoughlin "What you once thought was only a nightmare is now a reality!" Janet: lmjm@uk.ac.ic.doc, lmcl@uk.ac.ukc DARPA: lmjm@doc.ic.ac.uk (or lmjm%uk.ac.ic.doc@nss.cs.ucl.ac.uk) Uucp: lmjm@icdoc.UUCP, ukc!icdoc!lmjm