Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: innduct - a replacement for innfeed/nntpsend, 0.1 alpha
(Julien ?LIE)
2. Re: innduct - a replacement for innfeed/nntpsend, 0.1 alpha
(Ian Jackson)
3. Re: innduct - a replacement for innfeed/nntpsend, 0.1 alpha
(Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Sun, 01 Sep 2013 22:10:48 +0200
From: Julien ?LIE <[email protected]>
To: Ian Jackson <[email protected]>
Cc: [email protected]
Subject: Re: innduct - a replacement for innfeed/nntpsend, 0.1 alpha
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Ian,
>>> I looked at editing innfeed to make it tail the feed file with
>>> inotify/kqueue but innfeed is an very large program for what it does -
>>> nearly 25kloc.
>>
>> Maybe the funnel-file mode I am speaking about is what you are hinting
>> at here. Instead of editing innfeed to tail the funnel-file on its own,
>> a separate script doing that could be periodically run by crond.
>
> I'm not sure I follow. In order to have both reliability and
> timeliness, the lines need to be read out of the funnel file (or, as
> innduct has it, the feed file) immediately via inotify, and then
> whatever is transmitting the articles needs to use some appropriate
> protocol to record where it got up to. innfeed doesn't do this.
It is true that innfeed does not do that. However, please note that
when innfeed has sent all the messages it was expected to send (that is
to say when innfeed reaches the end of the feed file), it only waits for
a second before having a look at whether there are more messages to
send. So timeliness is basically achieved within a second or so.
I understand your point when you say the transmission it not immediate.
If you want an immediate transmission, a funnel file should not be
used. But if a second is acceptable, then a funnel file could be used.
In innfeed/innlistener.c:
#define EOF_SLEEP_TIME 1 /* seconds to sleep when EOF on InputFile */
>> Would you mind if we mention innduct in:
>> * the "Related Packages" section of README
>> http://www.eyrie.org/~eagle/software/inn/docs/readme.html
>
> Sure.
[...]
>> Is the URL
>> http://www.chiark.greenend.org.uk/ucgi/~ian/git/innduct.git
>> OK for you to use, or do you prefer another one? (tarball, HTML page
>> describing the project or HTML version of the man page...)
>
> It's not the best page, is it. But the alternative is probably to
> wait for me to set up some kind of automatic gitweb manpage formatter
> or something. So please use that URL.
Thanks for having set up the URL:
http://www.chiark.greenend.org.uk/ucgi/~ian/git-manpage/innduct.git/innduct.8
It is pretty extensive and easy to read.
I will add the link soon to our documentation.
If I may suggest: a few links could be de-activated for you not to see
404 errors in your logs (links to inotify, inn.conf(5) or man2html for
instance).
> I'm expecting to have to do some work on innduct fairly soon because
> I'll be upgrading to Debian wheezy which has a new version of INN. I
> want, obviously, to be able to rebuild my innduct...
The patches you are currently using (for example lib/remopen.c) are
related to INN 2.4.x; source code has changed in INN 2.5 (especially
lib/network.c for what was previously in lib/remopen.c) so maybe there
are now no longer useful.
I hope upgrading innduct will be straight-forward; do not hesitate to
tell in case you are facing issues with the new version of INN shipped
with Wheezy.
--
Julien ?LIE
? ? Dis Ast?rix ! Quelle salade pour un peu d'huile !
? Oui, et d?p?chons-nous de trouver un gu?risseur avant que ?a
ne tourne au vinaigre. ? (Ast?rix)
------------------------------
Message: 2
Date: Sun, 1 Sep 2013 21:29:30 +0100
From: Ian Jackson <[email protected]>
To: Julien ELIE <[email protected]>
Cc: [email protected]
Subject: Re: innduct - a replacement for innfeed/nntpsend, 0.1 alpha
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
Julien ?LIE writes ("Re: innduct - a replacement for innfeed/nntpsend, 0.1
alpha"):
> Hi Ian,
> > I'm not sure I follow. In order to have both reliability and
> > timeliness, the lines need to be read out of the funnel file (or, as
> > innduct has it, the feed file) immediately via inotify, and then
> > whatever is transmitting the articles needs to use some appropriate
> > protocol to record where it got up to. innfeed doesn't do this.
>
> It is true that innfeed does not do that. However, please note that
> when innfeed has sent all the messages it was expected to send (that is
> to say when innfeed reaches the end of the feed file), it only waits for
> a second before having a look at whether there are more messages to
> send. So timeliness is basically achieved within a second or so.
Ah, but if you use innfeed in that kind of mode, what do you do if
it dies for any reason ? I think you have to restart it and it has to
then offer all of the articles in the feed file back to the same peer.
Also I think it doesn't deal well with 431/436 responses - see the
commentary about resendid in incoming.conf(5). innduct gets that
right.
> Thanks for having set up the URL:
>
> http://www.chiark.greenend.org.uk/ucgi/~ian/git-manpage/innduct.git/innduct.8
>
> It is pretty extensive and easy to read.
> I will add the link soon to our documentation.
Thanks.
> If I may suggest: a few links could be de-activated for you not to see
> 404 errors in your logs (links to inotify, inn.conf(5) or man2html for
> instance).
Hmm, yes, or they could go to locally hosted manpages. I may get
around to that eventually.
> > I'm expecting to have to do some work on innduct fairly soon because
> > I'll be upgrading to Debian wheezy which has a new version of INN. I
> > want, obviously, to be able to rebuild my innduct...
>
> The patches you are currently using (for example lib/remopen.c) are
> related to INN 2.4.x; source code has changed in INN 2.5 (especially
> lib/network.c for what was previously in lib/remopen.c) so maybe there
> are now no longer useful.
Yes. I just went and looked this up, and I offered to do some
forward-porting of the necessary changes, which I haven't yet done...
Thanks,
Ian.
------------------------------
Message: 3
Date: Sun, 01 Sep 2013 23:30:44 +0200
From: Julien ?LIE <[email protected]>
To: Ian Jackson <[email protected]>
Cc: [email protected]
Subject: Re: innduct - a replacement for innfeed/nntpsend, 0.1 alpha
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Ian,
>> It is true that innfeed does not do that. However, please note that
>> when innfeed has sent all the messages it was expected to send (that is
>> to say when innfeed reaches the end of the feed file), it only waits for
>> a second before having a look at whether there are more messages to
>> send. So timeliness is basically achieved within a second or so.
>
> Ah, but if you use innfeed in that kind of mode, what do you do if
> it dies for any reason ? I think you have to restart it and it has to
> then offer all of the articles in the feed file back to the same peer.
Yes, I also believe innfeed will resend all the messages to the peers.
We do not know whether they have already been sent. Yet, it will
normally be fast because remote peers will respond they already have the
proposed Message-IDs.
You will also have to restart innfeed manually, yes.
> Also I think it doesn't deal well with 431/436 responses - see the
> commentary about resendid in incoming.conf(5). innduct gets that
> right.
How would you want innfeed to handle 431/436 responses?
From incoming.conf man page:
noresendid: This key requires a boolean value. It defines whether innd
should send 431 (response to CHECK, in streaming mode) or 436 (response
to IHAVE in non-streaming mode) responses instead of 438 (response to
CHECK) or 435 (response to IHAVE) if a message is offered that is
already received from another peer. This can be useful for peers that
resend messages right away, as innfeed does. The default is false: the
peer receives 431 and 436 codes so that it resends the article later.
According to innfeed/host.c, when innfeed receives a 431/436 response,
it marks the article to be resent 5 seconds later (function
hostArticleDeferred). 5 seconds should normally be enough for another
peer to complete the transmission of the article, so normally 438/435
will be received the second time by innfeed, and it will no longer
attempt to send the article.
Hmmm... Maybe the documentation is not clear and should be reworded
this way?
noresendid: This key requires a boolean value. It defines whether innd
should send 438 (response to CHECK, in streaming mode) or 435 (response
to IHAVE in non-streaming mode) responses instead of 431 (response to
CHECK) or 436 (response to IHAVE) if a message is offered that is
already received from another peer. The deferral feature can be useful
for peers that resend messages right away, as innfeed does. The default
is false: the deferral feature is used so that the peer receives 431
and 436 codes, and therefore resends the article later.
>> The patches you are currently using (for example lib/remopen.c) are
>> related to INN 2.4.x; source code has changed in INN 2.5 (especially
>> lib/network.c for what was previously in lib/remopen.c) so maybe there
>> are now no longer useful.
>
> Yes. I just went and looked this up, and I offered to do some
> forward-porting of the necessary changes, which I haven't yet done...
Also, if you believe innduct could be of interest to Debian users,
packaging it could be worthwhile :-)
Like innfeed that is a Debian package related to inn v1 (not inn2).
--
Julien ?LIE
? ? Dis Ast?rix ! Quelle salade pour un peu d'huile !
? Oui, et d?p?chons-nous de trouver un gu?risseur avant que ?a
ne tourne au vinaigre. ? (Ast?rix)
------------------------------
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
End of inn-workers Digest, Vol 55, Issue 1
******************************************
