[leafnode-list] configure script suggestion

[Cory C. Albrecht]

From:           	Matthias Andree <ma at dt.e-technik.uni-dortmund.de>
> "Cory C. Albrecht" <cory+spam at fenris.cjb.net> writes:

> The kernel re-sends the SYN packets for a while so losing the first one
> isn't a problem.

But obviously they aren't getting resent often enough, in my case. BTW, just 
in case you were assuming I use Linux, I don't. I use OpenBSD. 

> 
> > With the primary listed first in config, this meant that out going
> > posts usually failed since fetchnews couldn't conenct to it and that I
> > would get no new news. :-(

> I'd turn things around and run fetchnews from /etc/ppp/ip-up
> instead. You can for instance ping your news server to trigger the dial.

The machine connects to the network for reasosn other than downloading news. 
What you're suggesting would mean that every time I went to surf the web, 
fetchnews would get started up in ip-up, unecessarily chewing up precious 
bandwidth. If sendmail can't contact the MX for for a domain to deliver an 
email, it tries every so often. Fetchnews would then get started from ip-up 
everytime sendmail made one of these retries. IOW, starting fetchnews from ip-
up would be rather silly.

> > It would be nice if on the config file there were a retries parameter.

> I'm not going to add such a feature, solving the network-layer problems
> of dial-on-demand is out of leafnode's scope.

Yes, in that limited aspect you are right, but that isn't the full picture.

Sometimes these network layer problems are just transient things that just 
appear and then disappear. Packets get dropped anywhere along the line bwteen 
<here> and <there>, not just during dial-on-demand problems like mine. Perhaps 
because of exceeding TTL during bandwidth saturation on some link, or maybe 
because the redundant bridge doesn't come on-line in zero time when the 
primary has a hardware failure or power loss and shuts down, or any of a 
gazillion other reasons.

It is expected, and that is why browsers, IRC clients, FTP clients, SSH 
clients and so on try a handful of times to connect and not just once and then 
give up. And clients aren't the only ones to retry - FTP servers try a few 
times to connect to the port the client gave to start a file transfer, "full-
service" news servers (like innd or cnews) retry their peers, and more.

Why wouldn't leafnode have a similar "retry a finite number of times before 
giving up" method, like everything else? After all, not everybody's ISP has 
multiple redundant newsservers such that a DNS query gives multiple answers 
for news.somewhere.com. Most ISPs only have one news server with one IP 
address for that host.

No, it's not leafnode's job to counteract every possible network layer 
problem, but neither should it just throw up its hands in defeat at the first 
failed connection for a server. It should be "ruggedized", so to speak, in 
order to cope with minor transient problems.
--
Cory C. Albrecht
http://cory.doesntexist.com/
Life in a vacuum sucks.