innduct - a replacement for innfeed/nntpsend, 0.1 alpha

[Julien ÉLIE]

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)