Xref: utzoo comp.mail.uucp:5442 comp.dcom.modems:7286
Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!smurf!urlichs
From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: comp.mail.uucp,comp.dcom.modems
Subject: Re: What should a new UUCP protocol do?
Message-ID: <p6v9g2.[q5@smurf.sub.org>
Date: 11 Nov 90 10:54:51 GMT
References: <1889.2739aa0d@dcs.simpact.com> <+2m8g2.lb1@smurf.sub.org> <1898.273bd977@dcs.simpact.com>
Organization: University of Karlsruhe, FRG
Lines: 40

In comp.dcom.modems, article <1898.273bd977@dcs.simpact.com>,
  jeh@dcs.simpact.com writes:
< In article <+2m8g2.lb1@smurf.sub.org>, urlichs@smurf.sub.org 
< (Matthias Urlichs) writes:
< > 
< > Lots of g's _think_ they can do 4K packets, but internally they use some
< > stupid small buffers anyway because the support for big blocks hasn't been
< > tested in the last ten years or so.
< 
<Hmmmmm.  Well, if one still wanted to stay with "g", this would be fixable with
<an option in the systems file entry(ies) for those hosts.  "When talking to
<this host, restrict packet size to n, and window size to m."  
< 
OK, but that implies that the protocol can get at the systems file entry,
which requires modification of your UUCP beyond linking in another protocol
and augmenting the protocol table. It might be better to create a new
protocol for working big-packet g protocol implementations. Call it "G". ;-)

< > You'll also run into trouble if you try to talk to a Telebit with UUCP
< > spoofing enabled, and want to use bigger blocks.
< 
<This I have not seen -- I have tested a 7x4k g through a TB+ and it works fine,
<though it only runs 3x64. [...]

Hmmm ... I'll have to look into this some more, then...

< > One problem that you're not going to cure with this is that if you have a
< > full duplex  link, about  half the bandwidth is wasted.
< > Hmmmm ... Thinking some about this ... you could possibly fake it by ...
< > [ multiplexing two uucico conversations onto one line ]
< 
<Someone actually hacked this together a year or so ago.  As I recall he never
<did get it working perfectly but I am sure this was just an implementation bug
<and not a real flaw in the design; the design looked fine. 
< 
Are the sources for this available anywhere?

-- 
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de     /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330)   \o)/