🚀 go-pugleaf

I had been having some trouble with an INND/nntplink setup.
I have traced these to the setting of WIP_CHECK in innd/nc.c, which is
delivered (in version 1.2) as 60*10, i.e. 10 minutes.

Scenario:
	feed A offers article - accepted
	Feed B offers same article
	Feed A sends article
	(feed A continues)
	Feed B does not receive a reply for 10 minutes, and times out
	the connection.
	Feed B restarts - offers same article; refused.

This will repeat over and over. Uunet timed us out 14 times yesterday.

The "correct" value for this would lead to "most" articles in the
process of being received to be completely received - i.e. very few
duplicates. I've set my copy of innd to 5 seconds, and was receiving
perhaps 20 duplicates/hour on Friday evening (GMT) but none over the
weekend. Maybe 10 or 20 seconds would be a good value - it depends on
the behaviour of and bandwidth to your main feeds. Certainly less than a
minute.

Are you affected? Yes, if you see a "readclose" in your innd syslog file,
you should reduce your own WIP_CHECK:

Jan  3 21:22:37 pipe innd: news.uu.net:15 readclose
Jan  3 21:22:37 pipe innd: news.uu.net:15 closed seconds 333 accepted 10 refused 16 rejected 0
Jan  3 21:22:52 pipe innd: news.uu.net connected 15

If you're running nntplink, and see this:

Jan 10 20:43:27 pipe nntplink[9706]: news.uu.net: connection timed out while reading reply
Jan 10 20:53:50 pipe nntplink[9706]: news.uu.net: connection timed out while reading reply

- then ask the admin of the other site to reduce their WIP_CHECK value.
(I've already mailed David)

BTW - congratulations to the authors of INND for making such a
maintainable product. It took me less than 10 minutes to find the fix
once I knew what the problem was, a tribute to the good structure of
the innd.

Ian
(news@pipex.net)
-- 
Ian Phillipps, Unipalm Ltd, 216 Science Park,		Phone +44 223 420002
Milton Road, Cambridge, CB4 4WA, England.		Phax  +44 223 426868
PIPEX is a division of Unipalm Ltd. - phone 0223 424616.