Path: utzoo!utgpu!watserv1!watmath!att!att!pacbell.com!ucsd!usc!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!uafhp!actsn!david
From: david@actsn.fay.ar.us (David Summers)
Newsgroups: comp.mail.uucp
Subject: Re: What should a new UUCP protocol do?
Summary: I have some such sources.
Message-ID: <791@actsn.fay.ar.us>
Date: 18 Nov 90 05:34:59 GMT
References: <1889.2739aa0d@dcs.simpact.com> <+2m8g2.lb1@smurf.sub.org> <p6v9g2.[q5@smurf.sub.org>
Followup-To: comp.mail.uucp
Organization: All Church Technical Service, Fayetteville, AR
Lines: 59

In article <p6v9g2.[q5@smurf.sub.org>, urlichs@smurf.sub.org (Matthias Urlichs) writes:
[ ... deleted ... ]
> < > 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)/

I tried playing around with multiplexing 2 uucico's last year, creating a total
of 4 processes per machine.  I tried to implement a sort of Zmodem-type
streaming protocol but had strange problems (admittedly (sp?) my first attempt
at designing my own protocol) where the receiver would lose packets and things
would never get back in sync and finally it would give up.  I finally had to
back off to having every big packet ACKed by a small packet but I was still
coming close to cutting transmission times by 2 when things were flying in
both directions.

I essentially spoofed UUCICO to think that each connection was the only one
on the channel, by using pipes.

The biggest problem I ran into was that Xenix (and maybe AT&T SysV???) can
only handle about 256 bytes at a time before it starts dropping stuff, when
there is any kind of load on the system.


I liked what I saw mentioned previously....use existing UUCICO but pipe the
input and output through pipes to another process.  For some reason I didn't
think of that (maybe because I have source?).  

Anyway, it seems to work but my error correcting protocol is somehow not working
and I ran out of time to work on it while trying to finish my undergraduate work
and beginning GRAD school.  I would like to work on it some more but haven't
found the time.

I could send the sources to anyone interested, or put it up for FTP if there
is enough interest.  Be warned that it is only the mods to the standard UUCP
and most of that is just in the protocol selection.  UUCICO is designed to
just  drop in another protocol and I took advantage of that.  I created my
own 'b' protocol to test thins out.  I also have it set up to test  out on
an error "connection" between two pipes on the same computer.  It was
interesting trying to debug 8 processes at once.......


   - David Summers
   (david@actsn.fay.ar.us)

-- 
I'm sick and tired of this machine, I wish that I could sell it.
It never does just what I want, but only what I tell it!
- David Summers (david@actsn.fay.ar.us)