: >If the article numbers are not kept the same, this will break any use >of a cluster of round-robined news servers. Not good! If your nntpcache is reading specific groups from a specific server or * from a specific server, there's no problem. The problems start when * is defined in the server config as being available from more than one source. Articles numbers start varying wildly if the primary server is unavailable and nntpcached tries to grab articles from the secondary one. >We intend using nntpcache in each of our PoPs, but need the redundancy >of central backup servers incase of a failure at the remote PoP. With >the article numbers the same, customers would see no difference in >the use of a different server to normal. This also means that customers >can dial into any PoP without upsetting their news reader. I do this too for several end-user dial-on-demand setups. As long as nntpcache is reading from a single server or a group of synchronized servers, there is no problem and you'll never see offered article numbers vary. If one group is ever found to be on 2 unsyncronised servers by nntpcached, when the primary one is unavailable, nntpcached will start offering article numbering from the secondary. This _will_ mess things up. Most readers assume that a lower highwater mark than previously seen means the group has been renumbered and offer the reader every message in the group as "new". Unless article numbering on both sites is close, readers will see every message again. Even if the servers are close, programs like Free Agent which cache header info for selection purposes will see the effect that selecting a message from the subject window will get a completely unrelated body. This usually results in spurious support calls for us. AB
