paul@greipa.UUCP (Paul A. Vixie) (09/10/85)
I think my system is a bit to touchy on the timing - uusnap shows every system
that we talk to as "TIMEOUT" and has for some time. Systems log in and get an
hour or two of news, then TIMEOUT.
Of course there is no man page for uucico, so if there is an option for spec-
ifying the time limit I can't find it. Any ideas, anyone?
Paul Vixie
dual!greipa!paul
--
Paul Vixie
{decwrl dual pyramid}!greipa!paulguy@sun.uucp (Guy Harris) (09/11/85)
> I think my system is a bit to touchy on the timing - uusnap shows every > system that we talk to as "TIMEOUT" and has for some time. Systems log > in and get an hour or two of news, then TIMEOUT. Does it time out in the middle of a transfer, or does it successfully complete a UUCP session? Check the LOGFILE - if there's a message like <the other system> <log file crud> OK (conversation complete) just before the timeout for that system, the timeout is only a timeout in the hangup sequence. There's a bug that's been in UUCP since time immemorial, but which was only noticed in the 4.2BSD UUCP because other UUCPs didn't bother making any note of timeouts like that. Basically, the protocol is incorrectly implemented, so one side waits for an extra handshaking message that the other side has no intention of sending. The 4.3BSD UUCP fixes this by not waiting for the extra message. I suspect honey danber does also (Peter?). The bug is annoying but, as far as I know, harmless. > Of course there is no man page for uucico, so if there is an option for > specifying the time limit I can't find it. Any ideas, anyone? Since this timeout is an internal protocol timeout, it is not user-specifiable. Guy Harris
ken@turtlevax.UUCP (Ken Turkowski) (09/11/85)
In article <383@greipa.UUCP> paul@greipa.UUCP (Paul A. Vixie) writes: >I think my system is a bit to touchy on the timing - uusnap shows every system >that we talk to as "TIMEOUT" and has for some time. Systems log in and get an >hour or two of news, then TIMEOUT. This must be more prevalent than I thought. Our system suffers from this as well. Unfortunately, I don't have a solution. -- Ken Turkowski @ CADLINC, Menlo Park, CA UUCP: {amd,decwrl,hplabs,seismo,spar}!turtlevax!ken ARPA: turtlevax!ken@DECWRL.ARPA
clewis@mnetor.UUCP (Chris Lewis) (09/11/85)
In article <383@greipa.UUCP> paul@greipa.UUCP (Paul A. Vixie) writes: >I think my system is a bit to touchy on the timing - uusnap shows every system >that we talk to as "TIMEOUT" and has for some time. Systems log in and get an >hour or two of news, then TIMEOUT. > >Of course there is no man page for uucico, so if there is an option for spec- >ifying the time limit I can't find it. Any ideas, anyone? Does it timeout with stuff still left to send? If it doesn't, this is likely to be a protocol mismatch at call termination time rather than a true timeout - at least if you are on BSD4.2 or 4.1 and you are talking to System V's. Both <4.2 and SV have a bug in call termination, the UUCP for 4.3 has it fixed and will not timeout in this way when talking to 4.2 or SV. -- Chris Lewis, UUCP: {allegra, linus, ihnp4}!utzoo!mnetor!clewis BELL: (416)-475-8980 ext. 321
dave@onfcanim.UUCP (Dave Martindale) (09/12/85)
In article <383@greipa.UUCP> paul@greipa.UUCP (Paul A. Vixie) writes: >I think my system is a bit to touchy on the timing - uusnap shows every system >that we talk to as "TIMEOUT" and has for some time. Systems log in and get an >hour or two of news, then TIMEOUT. > Is this a timeout during the conversation, or after it is complete? There is a bug in (some versions of, at least) system V uucp that causes it not to send the final OOOOO message properly, and the machine on the other end (at least if it's a Berkeley unix) eventually times out. The symptoms of this are that the log file shows CONVERSATION COMPLETE before the TIMEOUT. If this is what is happening to you, don't worry about it - everything is in fact getting through. However, if it is happening during the conversation, you probably have a noise line and the modems eventually drop carrier. Nothing should be lost, but this can badly degrade the amount of stuff transferred over that connection. The best fix is to fix the modem or phone line or whatever is causing the problem. To increase the timeout, you need to have source for uucico (or a lot of skill with adb). But if you are really timing out, something is very unhealthy elsewhere.
bp@nyit.UUCP (Bruce Perens) (09/14/85)
Besides the over-and-out timeout, there's a timeout problem in xcp() (uucico source cpmv.c, 4.2 distribution). My news feed's uucico timed mine out whenever a large file was copied by xcp(). Xcp() uses fread() and fwrite(), but they are a lot slower than read() and write() for copying large buffers. I hacked xcp() to use read() and write(), and the problem went away. Another way to fix this would have been to write a faster implementation of fread() and fwrite(). There should probably be some kind of keep-alive message during a time-consuming process like xcp(). This is tricky to program. Xcp() is only used to copy a file if the spool file can't be linked to the destination file by xmv(). This happens if the des- tination file already exists, or if the destination is not on the same disk partition as the spool file. Bruce Perens NYIT Computer Graphics Lab. decvax!philabs!nyit!bp allegra!sbcs!nyit!bp nyit!bp@sbcs.csnet 516-686-7644