Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!mordor!lll-tis!ames!schoch
From: schoch@ames.arpa (Steve Schoch)
Newsgroups: comp.mail.uucp
Subject: Re: 4.3 uucp w/TCP troubles
Message-ID: <2201@ames.arpa>
Date: Thu, 2-Jul-87 21:30:36 EDT
Article-I.D.: ames.2201
Posted: Thu Jul  2 21:30:36 1987
Date-Received: Sat, 4-Jul-87 08:53:46 EDT
References: <762@hao.UCAR.EDU>
Reply-To: schoch@ames.UUCP (Steve Schoch)
Organization: NASA Ames Research Center, Moffett Field, Calif.
Lines: 31
Keywords: TCP UUCP

In article <762@hao.UCAR.EDU> woods@hao.UCAR.EDU (Greg Woods) writes:
> ... What happens is that uucico times out in "tcpopen". It isn't
...
>I now see TIMEOUT, as follows:
...
>TCP CLOSE called
>woods seismo (6/29-13:35-23579) TIMEOUT (tcpopen)
>woods seismo (6/29-13:35-23579) FAILED (call to seismo )

I fixed this problem on ames, the problem was caused by taking the existing
code for uucp, and splicing the TCP/UUCP code into it.

First, look in aculib/bsdtcp.c in the routine bsdtcpopn.  In that routine
it sets a signal handler for SIGALARM, then calls alarm() before the
connect call.  I see no reason for this, because the TCP code in the BSD
4.3 kernel does a much better job of determining the timeout for TCP than
a user program, so the user program should just let the connect call return
with ETIMEDOUT rather than setting its own timer.

Next, in other parts of the (generic) uucp code, there are several places
where you have "alarm(MAXMSGTIME)" immediately before a read or imsg.  This
makes sense if you are using a modem, as the other side could crash and
leave the carrier on the modem, but this makes no sense when using TCP as
TCP provides its own timeouts.  The way I fixed this problem was to change
all the MAXMSGTIME to a variable, maxmsgtime, which I set to MAXMSGTIME as
a default, but when using TCP, I set to something bigger (like an hour).

If anyone is running the 4.3 BSD uucp with TCP, let me know and I'll mail
you my changes.

BSD