fenner@jazz.psu.edu (Bill Fenner) (06/07/91)
In article <1991Jun4.161440.4161@wynnds.xenitec.on.ca> timk@wynnds.xenitec.on.ca (Tim Kuehn) writes: |Procedure: |---------- |1) An article of the above format is received by the site and stored |in the system somewhere. | |2) This article would be compared against the local "offender_site" list. |Any differing or omitted entries in the news article compared to the local |offender-site list would be updated in the news article to reflect the |current offender-site name and date information. | |(Note: the news article would only be scanned for entries made by the |*local* site. Other site information would not be touched but left to |the remote sites to update as required.) | |3) If the news article was changed by the local machine, it would be |reposted to the net and shipped out with the next poll. If it was |not changed, then it would not be reposted. When you repost it, do you change the Message-ID? If yes, you might get hundreds of articles in this group... let's say site a posts an article, and sends it to sites b and c. b and c both have additions to the article, so they modify it and repost it, both sending it back to a. a sends the article it got from c to b, and the article it got from b to c (so right now we have 3 articles, with 3 different message-ID's). But the article that went to C, got modified, went back to A, then went to B, doesn't have B's stuff in it, so B modifies it and posts it back. Same with C -- the article that went to B, got modified, went back to A then to C doesn't have C's entries in it. So C modifies it and reposts it. Now we have 5 articles, 2 of which are identical except for message-ID, and only 2 out of the 5 have all the information needed. If you don't change the Message-ID, the message will not propogate back where it came from. Let's say A is generating bad articles, and B and C notice. But A is where the "bad-article" message is coming from, so when B and C modify it and try to send it back to A, it will get rejected based on the Message-ID, and A won't know that it's generating bad articles. Also, if B and C have downstream sites, they will each get different articles (messages with _different_ content) with the same Message-ID, and if the feeds converge later on, it gets even hairier. Also, how do you decide what machine posts the original message for others to modify? |Question/Caveat: |---------------- |Under (3) above, if multiple copies of the article came in, provision |would have to be made to ensure that the number of copies kept on the |local spool area don't grow like wildfire, but only one file is kept |on the system at a time. So you would need more of a "pseudo-group", with a program running every once in a while to consolidate the articles (do you consolidate before or after you batch for other sites? ...). Let's take the first example above, adding merging of the articles. A sends to B and C, who each modify the article. B sends back its copy (it's a fast NNTP link), and C's modified article gets there later (it's a slow UUCP link). When A gets B's copy, it must merge it with its own local copy. Does it then send the merged one or the un-merged one on? (At this point, they're equivalent, so it doesn't matter.) So it sends the article to C, and at the same time, gets C's modified article. It merges C's article with its local article, and then propogates it (merged? un-merged?) to B, for B to merge it with its local article. Seems like an awfully CPU-intensive and high-bandwidth solution. Bill -- Bill Fenner fenner@jazz.psu.edu ..psuvax1!hogbbs!wcfpc!wcf wcf@hogbbs.scol.pa.us (+1 814 238-9633 2400MNP5)