This HOWTO was written to allow a Linux system administrator provide the
Usenet news service to readers of those articles. The rest of this HOWTO
focuses on the server-end software and systems, but one chapter
dedicated to the clients does not seem disproportionate, considering
that the raison d'etre of Usenet news servers is to serve
these clients.
The overwhelming majority of clients are software programs which access
the article database, either by reading /var/spool/news on a
Unix system or over NNTP, and allow their human users to read and post
articles. We can therefore probably term this class of programs UUA, for
Usenet User Agents, along the lines of MUA for Mail User Agents.
There are other special-purpose clients, which either pull out
articles to copy or transfer somewhere else, or for analysis,
e.g. a search engine which allows you to search a
Usenet article archive, like Google (www.google.com)
does.
This chapter will discuss issues in UUA software design, and bring out
essential features and efficiency and management issues. What this
chapter will certainly never attempt to do is catalogue all
the different UUA programs available in the world --- that is best left to
specialised catalogues on the Internet.
This chapter will also briefly cover special-purpose clients which
transfer articles or do other special-purpose things with them.
We will discuss Suck and nntpxfer from the NNTP server
distribution here. Suck has already discussed earlier. We will be happy
to take contributed additions that discuss other client software.
NNTPCache is an interesting transparent cacheing proxy for
news articles. News articles are read-only by definition,
i.e. they do not change once they are posted;
they can only be deleted. NNTPCache uses this feature to build a
local cache of news articles.
You set up NNTPCache to listen on the NNTP port of your local
Unix server, and act like an NNTP daemon. You configure it to
connect back-to-back to another NNTP daemon, further away, which has
all the interesting stuff the users want to read. When a user
connects to the local NNTPCache, it connects to the remote NNTP
server and acts as a relay for the NNTP connection, ferrying
commands and responses back and forth. What the user sees therefore
comes from the remote server, the first time. However, all news
articles fetched by NNTPCache are also stored in a local cache, thus
allowing the next user to browse the same set of articles faster.
Like all demand-driven caches, the advantage here is that the local
NNTPCache does not need (much) administering, and will automatically
delete all articles from its cache once they've been lying unread
long enough.
We list it here as an NNTP client because every proxy server
is a server on one side and a client on the other.
Free eBook: 
