5.4. Article Numbering and its Importance
Before we can emphasize the incredible benefit of a global, centralized article numbering system, we must first ensure clarity and demonstrate importance of what article numbering is.
Every article on Usenet has a set of information unique to itself and itself alone. The set of information is contained within the article headers. Three headers are pertinent to our discussion:
- Message-ID
The Message-ID is a string of random text of the form < unique @ full domain name > and should be unique to only one article. RFC 1036 recommends the Message-ID to be guaranteed unique for at least two years.
- Newsgroups
The Newsgroups header denotes what group or groups the article belongs to.
- Xref
The Xref header specifies an article number for each group in the Newsgroups header.
Figure 1
Figure 1 illustrates a Usenet Network that does not attempt to synchronize article numbers. An article is accepted by a Router server (Cyclone) into the network with a pre-existing (or non-existent) article number, and is passed to three Reader (Typhoon, Twister, and Tornado Back End) servers. Once the article reaches each Reader server, an article number is assigned based on an internal database on each Reader server. Rarely, if ever, will two Reader servers assign the same number to the same article unless synchronized by an outside mechanism.
Figure 2
Now examine Figure 2. Here is a Usenet Network that synchronizes article numbers. The Router server accepts the same article, but before passing the article along, it assigns a number to the article for every group the article appears in. The article in the figure only belongs to one group, comp.lang.c++. Since each Reader server is configured to obey the article numbers it receives, the article number is now the same on every Reader server.
Figure 3
A common problem on unsynchronized networks is depicted in Figure 3. A Usenet client requests a specific article, but gets a different article instead. Since clients will often open multiple connections to the Reader servers, load balancers can send connections to any Reader server and may not be able to guarantee which one accepted it. Even in networks that do not use a load balancer, the client can manually connect to another Reader server and invalidate the configuration achieved on the previous Reader.
Synchronization solves the problems illustrated in Figure 3 and provides several very significant additional benefits to the network (Figure 4).
Figure 4
Load Balancing - Any incoming client can access any of the Reader servers as if they were one server.
Fail-over - Since all Reader servers have identical data (which gave us Load Balancing), any one Reader can be taken offline and the other servers can pick up the workload.
No Client Reconfiguration - In an unsynchronized scenario, clients can connect to a different server and invalidate their configuration (article counts, downloaded headers, read/unread messages, etc.).
To achieve article number synchronization, one Router must generate all article numbers for a particular network. Also, for an article to be numbered, the entire article must be sent to the Router doing the numbering. Out of these requirements materializes the Master Number Generator Architecture, where the Router doing the numbering is labeled the Master Number Generator and all other servers on the network respect the numbers it provides.