rmf@media.medianette (Roger Fujii) (08/14/90)
After sending some time digging through the Cnews source code, it seems to
me that the Ihave-Sendme implementation is 'less than optimal'. Unless
I am missing something, it seems that Cnews generates a 'sendme' AS
SOON AS it processes the ihaves. This destroys any advantage of delaying
the sendbatches of Host.sendme to 'disfavor' a slow ihave site (My
situation is several incoming ihave/sendme sites, some TB+s, and some
2400s - we would like to favor the TB sites).
Anyway, I rigged up a set of changes to (hopefully) fix this. Here is
what I did:
1) I produced a program that will re-check article ids to see
if it has arrived. This is to check to see if the article
has come in after receiving the ihave, but before I gen
the sendme.
2) Changed batchsm to call this program instead of cat.
3) Fixed spacefor to accept "ihave" & "sendme" flags to
calculate saner numbers.
4) Changed batchsplit to check for ihave/sendme messages
and calculate saner sizes
5) Changed sendbatches to pass the ihave/sendme flag to
the modified spacefor.
This seems to work, but I have this nasty feeling that this is too simple
and I am missing something. Any comments?
--
Roger Fujii - Media Cybernetics Phone: (301)495-3305
Internet: rmf%media@uunet.uu.net UUCP: {uunet,hqda-ai}!media!rmfjerry@olivey.olivetti.com (Jerry Aguirre) (08/16/90)
In article <1990Aug14.051835.209@media.medianette> rmf@media.medianette (Roger Fujii) writes: >I am missing something, it seems that Cnews generates a 'sendme' AS >SOON AS it processes the ihaves. This destroys any advantage of delaying >This seems to work, but I have this nasty feeling that this is too simple >and I am missing something. Any comments? Yes, you are missing something. An alternate way, that involves no code changes, is to delay the transmission of the ihave messages. There are two basic ways to do this. The first is to rename the "ihave" queue file. For example if the was a media.ihave file you could at cron scheduled intervals rename it to media.ihave.1 after first renameing media.ihave.1 to be media.ihave.2, etc. Then you generate the ihave using media.ihave.N where N is the delay you want. I use this scheme here. In fact I have a general "ihave" queue that I use to generate ihaves control messages for multiple sites. A second, simpler, method is to use "at" to schedule turning the ihave queue file into a control message. This places the burden on "at" to save the input file away and run it at the proper time. I havn't tried this method personally. A final improvement on the above is to queue the ihave message for transmission with a low UUCP grade. If your UUCP supports it queue the ihave message separately (not in a batch) with a grade of "z". That will allow normal batches to be transmitted, and hopefully processed, before the ihave message. With sendme messages you want the opposit. Queue it with the highest grade possible ("0"). Once the sendme is issued the articles are going to be transmitted. If they are transmitted late then they will likely be duplicates because the other feed will get there first. Control of how the ihave and sendme messages are queued is possible because they are queued using the "to.sitename" newsgroup. So, a sys entry like: to.media/media:world,to.media:BSUL:/usr/bin/uux -c -z -gZ media!rnews would queue the ihave message with a very low grade. A corresponding entry on media could queue the sendme with a higher than normal grade. Of course if you are both sending ihave/sendme then this method breaks down. A news group other than to.site could be used for the ihave messages allowing different handling. I contemplated using a "from.site" group for a while. That would allow a single ihave to go to multiple news neightbors. Of course by now you may have noticed that this places the burden on the sending site rather than your method which puts the changes in the receiving site. Using the "at" method of delaying ihave messages shouldn't be to hard for your feed to implement though. Jerry
henry@zoo.toronto.edu (Henry Spencer) (08/16/90)
In article <1990Aug14.051835.209@media.medianette> rmf@media.medianette (Roger Fujii) writes: >After sending some time digging through the Cnews source code, it seems to >me that the Ihave-Sendme implementation is 'less than optimal'... Ihave/Sendme is less than optimal. That is an established fact. :-) The C News implementation of it has approximately the same functionality as the B News one, and delayed transmission is not a feature of either. However, I tend to agree that a delayed Ihave/Sendme would be a useful thing, and an "official" version is in the works. It is actually quite similar to Roger's scheme, delaying and re-examining the sendmes rather than messing with the ihaves. This is the preferred solution because it means that all decisions (e.g. how long to delay) are made at the recipient, not at the feed site, so a change in policy does not require help from the feed's sysadmin. -- It is not possible to both understand | Henry Spencer at U of Toronto Zoology and appreciate Intel CPUs. -D.Wolfskill| henry@zoo.toronto.edu utzoo!henry