usenet

The NNTP protocol supports both push-style and pull-style operation.

Backbone-to-backbone connections often operate in "push" mode, with the sending site having a receiving site's subscription list (which may include wildcards to push all articles in entire newsgroup hierarchies). The sending site will send an IHAVE message for each qualifying article it has, and the receiving site will send back a specific request for each article it hasn't received via another path. The IHAVE messages identify the article by its messageID, but do not specify what newsgroups it's posted to... and thus the filtering of articles by newsgroup has to be done at the pushing side.

Reader connections (client-to-server) generally operate in a "pull" mode, with the client asking for the article IDs of new messages in specific newsgroups, and then pulling the articles desired.

Small "leaf node" servers often use the client (reader) protocols to connect to larger (backbone) servers. This allows the leaf site's subscription list to be managed locally (e.g. adjusting it automatically based on read requests from local clients).

Historically, USENET news has also been handled via protocols other than NNTP. Originally, UUCP transport was used, and this was (I believe) always in "push" or "offer" mode.

NG

Look at that again, that is an offer and pull system.

Yes, UUCP was originally used for the *Transport* part. The control level from back then was not well documented. I expect it was an offer and pull system, much like it is today.

It's an offer-and-pull system at the article level. However, the decision as to which articles to offer is strictly a "push" decision... the server knows which newsgroups the receiving system is subscribed to, and offers every article which arrives in any of those newsgroups.

The receiving system has the ability to pull, or not pull, a given article it's offered... but it can do so *only* on the basis of the article's message-ID. It isn't given any other information about the article from the server... the server doesn't tell it what newsgroups the article was posted to.

So, what it boils down to in practice (with this approach) is that the server will attempt to push all articles in specific newsgroups or distributions to a given downstream node. The downstream node can veto the transfer of individual articles (by not responding with a SENDME) if it already has the individual article in its spool.

For the original UUCP-based implementation of USENET, you'd be mistaken... it was strictly a push system. Upon receiving an article, each node would forward it to every outbound peer (it had a list of the newsgroup hierarchies each peer wanted to receive). Articles might be sent as individual UUCP jobs (for very small feeds) but were more commonly batched up, compressed, and then sent as large chunks.

At the receiving node, articles were decompressed, split apart, and then either written to disk (if wanted) or just discarded (if the article had already been received from another upstream). It wasn't uncommon for sites with multiple upstream feeds to discard half of the incoming articles as duplicates.

An IHAVE/SENDME capability was added to later UUCP-based versions of the USENET system, in order to reduce the bandwidth waste at sites with multiple upstreams. This worked very much as the NNTP-based IHAVE/SENDME system does... the sending system would create a spool file full of IHAVE article-IDs, compress the file, and UUCP it to the receiving system... which would eventually turn around and send back a compressed batch of SENDME requests, which would trigger the actual batching and compression and UUCP'ing of the articles. Much more efficient, although it was/is still possible for downstream nodes to receive articles from more than one upstream and end up discarding the unwanted duplicates.

I thought the (lead) group was embedded in the message-ID.

Still describes offer and pull.

Upstream - downstream does not really match the structure as designed, only as currently implemented. The various servers are called peers by each other, and joining at the server level is called 'peering' regardless of the relative power of the two nodes. And most server nodes strive to have a multiplicity of peers.