mirror of https://github.com/tLDP/LDP
94 lines
3.7 KiB
Plaintext
94 lines
3.7 KiB
Plaintext
<section><title>Usenet news clients</title>
|
|
<para>
|
|
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 <emphasis>raison d'etre</emphasis> of Usenet news servers is to serve
|
|
these clients.
|
|
</para>
|
|
|
|
<para>
|
|
The overwhelming majority of clients are software programs which access
|
|
the article database, either by reading <literal>/var/spool/news</literal> 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.
|
|
</para>
|
|
|
|
<para>
|
|
There are other special-purpose clients, which either pull out
|
|
articles to copy or transfer somewhere else, or for analysis,
|
|
<emphasis>e.g.</emphasis> a search engine which allows you to search a
|
|
Usenet article archive, like Google (<literal>www.google.com</literal>)
|
|
does.
|
|
</para>
|
|
|
|
<para>
|
|
This chapter will discuss issues in UUA software design, and bring out
|
|
essential features and efficiency and management issues. What this
|
|
chapter will certainly <emphasis>never</emphasis> attempt to do is catalogue all
|
|
the different UUA programs available in the world --- that is best left to
|
|
specialised catalogues on the Internet.
|
|
</para>
|
|
|
|
<para>
|
|
This chapter will also briefly cover special-purpose clients which
|
|
transfer articles or do other special-purpose things with them.
|
|
</para>
|
|
|
|
<section><title>Usenet User Agents</title>
|
|
|
|
<section><title>Accessing articles: NNTP or spool area?</title>
|
|
<para>TO BE ADDED LATER</para>
|
|
</section>
|
|
|
|
<section><title>Threading</title>
|
|
<para>TO BE ADDED LATER</para>
|
|
</section>
|
|
|
|
<section><title>Quick reading features</title>
|
|
<para>TO BE ADDED LATER</para>
|
|
</section>
|
|
|
|
</section>
|
|
|
|
<section><title>Clients that transfer articles</title>
|
|
|
|
<para>
|
|
We will discuss Suck and <literal>nntpxfer</literal> from the NNTP server
|
|
distribution here. Suck has already discussed earlier. We will be happy
|
|
to take contributed additions that discuss other client software.
|
|
</para>
|
|
</section>
|
|
|
|
<section><title>Special clients</title>
|
|
<section><title>NNTPCache</title>
|
|
<para>NNTPCache is an interesting transparent cacheing proxy for
|
|
news articles. News articles are read-only by definition,
|
|
<emphasis>i.e.</emphasis> 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.</para>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>We list it here as an NNTP client because every proxy server
|
|
is a server on one side and a client on the other.</para>
|
|
</section>
|
|
|
|
</section>
|
|
</section>
|