Observation using trn-test76 and INN 2.4.0

[Patrick Vervoorn]

Hi,

[I'm e-mailing this to both the trn and the inn mailing-lists since this
is something which concerns both sides of the news reader/server
combination...]

Since I'm now more actively using trn I've also run into a problem I had
with trn in combination with INN quite a while ago (around december 2000,
judging by the mails I archived).

The problem was as follows: when entering a rather large binary newsgroup
(> ~75.000 articles unread), trn would take a VERY long time to get the
XOVER information). The same thing happened with the trn (test76) I was
using now, and connecting to an INN 2.4.0 (20021115 prerelease) newsserver
but since that version was 'grabbed' from a Linux binary release, I
couldn't change the OV_CHUNK_SIZE setting.

Now that compiling works, I did just that: I changed it from the default
of 40, to 40000. This causes trn to grab about 10000 articles in each
'XOVER' command. This speeds up the ov-fetching from ridiculously long
(sometimes it took several hours) to pretty quick (about 30 seconds to get
~100000 articles).

Apparently a news-server package like INN (and maybe others) are not so
much interested in 'nice' clients which only fetch 40 headers at once, but
are more oriented towards the 'brute-force' newsreaders that just grab the
entire range in on XOVER-command (something 'newsreaders' like Netscape,
Mozilla, or Agent probably do).

While I'm not promoting the 'upping' of the default OV_CHUNK_SIZE in the
trn source, it would maybe be a wise thing to make it an externally
configurable setting, so that individual users can 'speed up' trn in the
case when using servers that cater to the 'brute force' users...?

Could people from both/either the trn and INN communicaties comment on
this? Is this indeed whats happening?  What's the cause for this, at the
INN side? What would be the best solution to this problem? (taking 4+
hours to execute the 'XOVERs' for 100000 articles is a problem in my
opinion ;) Change the configuration reader, or is there an optimisation to
be done to the INN server software? Or is maybe the INN server in question
incorrectly configured?

Best regards,

Patrick.