news@fps.com (NetNews Administrator) (09/30/89)
In the intro to patch 18 Rick Adams says:
Specifying both I and F in the sys file will result in both the
pathname and the message-id of the file being written out.
This is NOT backwards compatible. For the old behavior,
specify only "I" and not both "I" and "F"
My question is: what's the purpose of this? My first guess was that
the path name was included in the "/usr/spool/batch/systemname.ihave"
file and when the "sendme" message came back, the pathnames would still
be included and rnews wouldn't have to look up the path names to setup
the batch (so making this operation much faster). Instead, it puts the
path names in the "/usr/spool/batch/systemname" file a la "F" style
followed with the message ID's. It seems to completely ignore the ".ihave"
file after that. So, my question is: why would anyone want to do this?
I can't think of any purpose for this. I looked through the code for
batch.c and I can't see where it's used. The diffs from patch 18 don't
tell me anything either. Am I missing the obvious?
Bill Davidson billd@fps.com
NetNews Administrator celerity!billd@ucsd.edu
FPS Computing Inc., San Diego
9692 Via Excelencia ...!{ucsd|sdsu|nosc|photon|cogen}!celerity!billd
San Diego CA 92126 (619) 271-9940 Ext. 242chris@wugate.wustl.edu (Chris Myers) (10/04/89)
In article <1046@celit.fps.com> news@fps.com (NetNews Administrator) writes: >In the intro to patch 18 Rick Adams says: > > Specifying both I and F in the sys file will result in both the > pathname and the message-id of the file being written out. > This is NOT backwards compatible. For the old behavior, > specify only "I" and not both "I" and "F" > >My question is: what's the purpose of this? My first guess was that >the path name was included in the "/usr/spool/batch/systemname.ihave" >file and when the "sendme" message came back, the pathnames would still >be included and rnews wouldn't have to look up the path names to setup >the batch (so making this operation much faster). Instead, it puts the >path names in the "/usr/spool/batch/systemname" file a la "F" style >followed with the message ID's. It seems to completely ignore the ".ihave" >file after that. So, my question is: why would anyone want to do this? >I can't think of any purpose for this. I looked through the code for >batch.c and I can't see where it's used. The diffs from patch 18 don't >tell me anything either. Am I missing the obvious? This option supports a minor hack I made to nntpxmit (I'm not saying this is the only use or reason for its existence, but it conveniently made it into an official news patch) that can cut down on I/O and cpu time by about 50% for well-connected nodes using NNTP to transfer news. What the original NNTP code did was: (1) get the path of the article from the batch file, (2) open it, (3) read the message header and parse out the message id, and (4) tell the other machine "IHAVE <messageid>". My modification got rid of step (3), which can make a really huge difference when the other node is usually rejecting 50-80% of the articles you offer, and a smaller difference for transmitting to end nodes. This patch was posted to news.software.nntp some time ago, but I will mail it to anyone on request. I have also submitted it to Stan Barber for incorporation into the next official NNTP patch (I don't know if he will do it or not, though). Chris Myers Internet: chris@wugate.wustl.edu Software Engineer BITNET: chris@wunet.bitnet Office of the Network Coordinator Washington University in Saint Louis, MO Phone: +1 314 362 6186
brian@ucsd.Edu (Brian Kantor) (10/08/89)
I asked Rick Adams to put the 'IF' patch into Bnews 2.11.18 so that lots of people would have software capable of making use of the articleid/filename patch to nntpxmit before Stan published the nntpxmit patch - and thereby avoid lots of incompatable and/or incoherent patches to B news when the nntpxmit patch appeared. As it is, Rick caught a bug in my patch to inews, luckily before it got published. (i.e., 2.11.18 works ok) I guess you could consider this some informal sort of revision control. - Brian