Huge articles & maxartsize (CURRENT)

F. Senault fred.letter at
Wed Mar 30 10:41:53 UTC 2005


I'm using a fairly recent CURRENT snapshot (2.5.0 20050321 prerelease),
and I'm having some troubles.

A few weeks ago, a peer reported that my machine was spooling, with a
lot of "unresponsive connection" log messages on his side.  After a few
hours of troubleshooting, I found that he was submitting "huge" articles
(compared to our bandwidth, anyways ! :)).

I had set up maxartsize on my side to 100000 bytes, he was submitting
(at least) a 5Mb article that took about three minutes to crawl along
the wire.  From that point, my feed went completely unresponsive : no
messages logged, no accept or rejection message...

Of course, from that point, the peer times out, the article is
respooled, proposed again, lather, rinse, repeat.

From=20what I've seen, there were quite a few changes in the code around
maxartsize in CURRENT.  I've taken a look at art.c, in ARTchecksize, and
I see :

    if (innconf->maxartsize > 0 && size > (size_t) innconf->maxartsize) {
        if (cp->State =3D=3D CSgotarticle)
            cp->State =3D CSgotlargearticle;
            cp->State =3D CSeatarticle;

I don't understand the meaning of the cp->State =3D CSeatarticle ?  And,
especially, if the state is set to CSeatarticle, can it revert to
CSgotlargearticle and get logged after ?

I'm probably missing something in the code, but the effects are here.

I've warned my peers about this, and I shouldn't receive any more big
articles, but if I can do something else to help debugging...

You're right - what should we care about silly things like counting
votes when we're in a war to preserve democracy.  And mind that you
don't say anything against the current resident because that would
undermine our efforts to preserve freedom.     (Paul Tomblin in the SDM)

More information about the inn-workers mailing list