Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site down.UUCP
Path: utzoo!linus!philabs!seismo!harpo!ulysses!princeton!down!honey
From: honey@down.UUCP (code 101)
Newsgroups: net.bugs.uucp
Subject: Re: BUG in System III [and others] UUCP (FLAME)
Message-ID: <24@down.UUCP>
Date: Fri, 20-Jan-84 21:58:54 EST
Article-I.D.: down.24
Posted: Fri Jan 20 21:58:54 1984
Date-Received: Sat, 21-Jan-84 09:09:47 EST
References: rlgvax.1549, <1243@ittvax.UUCP>
Organization: Princeton Univ. EECS
Lines: 19

just to review, the issue at hand is the proper handling of SN4 codes
in cntrl.c:  what should my side do if your side runs out of space?
this question was the subject of heated discussion at one point among
redman, bellovin, nowitz and myself.  our thoughts in brief.

we agreed from the outset that it was imperative that my side abort
processing of the current C. file.  someone proposed that the next C.
file be considered; it was pointed out that in all likelihood, that
transaction (and all subsequent ones) would also fail.  (the
overwhelming majority of file transfers are sends, not receives).  you
then would have to be careful to avoid looping when the directory is
rescanned.  (this is not outrageously hairy, in practice.)  it can be
argued that the wisest course is to inspect the remaining C. files for
receive requests, process those, then switch roles (i.e., request to
hangup), with a switch in anlwrk.c to avoid the loop (on a later role
change).  we felt that, among other things, this complexity would
eventually come back to haunt us, so we took the easy way out:
we hang up.
	peter honeyman