<HTML
><HEAD
><TITLE
>Usenet news clients</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
"><LINK
REL="HOME"
TITLE="Usenet News HOWTO "
HREF="index.html"><LINK
REL="PREVIOUS"
TITLE="Monitoring and administration"
HREF="x1094.html"><LINK
REL="NEXT"
TITLE="Our perspective"
HREF="x1243.html"></HEAD
><BODY
CLASS="SECTION"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Usenet News HOWTO</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="x1094.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="x1243.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECTION"
><H1
CLASS="SECTION"
><A
NAME="AEN1208">11. Usenet news clients</H1
><P
>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 <EM
>raison d'etre</EM
> of Usenet news servers is to serve
these clients.</P
><P
>The overwhelming majority of clients are software programs which access
the article database, either by reading <TT
CLASS="LITERAL"
>/var/spool/news</TT
> 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.</P
><P
>There are other special-purpose clients, which either pull out
articles to copy or transfer somewhere else, or for analysis,
<EM
>e.g.</EM
> a search engine which allows you to search a
Usenet article archive, like Google (<TT
CLASS="LITERAL"
>www.google.com</TT
>)
does.</P
><P
>This chapter will discuss issues in UUA software design, and bring out
essential features and efficiency and management issues. What this
chapter will certainly <EM
>never</EM
> attempt to do is catalogue all
the different UUA programs available in the world --- that is best left to
specialised catalogues on the Internet.</P
><P
>This chapter will also briefly cover special-purpose clients which
transfer articles or do other special-purpose things with them.</P
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="AEN1220">11.1. Usenet User Agents</H2
><DIV
CLASS="SECTION"
><H3
CLASS="SECTION"
><A
NAME="AEN1222">11.1.1. Accessing articles: NNTP or spool area?</H3
><P
>TO BE ADDED LATER</P
></DIV
><DIV
CLASS="SECTION"
><H3
CLASS="SECTION"
><A
NAME="AEN1225">11.1.2. Threading</H3
><P
>TO BE ADDED LATER</P
></DIV
><DIV
CLASS="SECTION"
><H3
CLASS="SECTION"
><A
NAME="AEN1228">11.1.3. Quick reading features</H3
><P
>TO BE ADDED LATER</P
></DIV
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="AEN1231">11.2. Clients that transfer articles</H2
><P
>We will discuss Suck and <TT
CLASS="LITERAL"
>nntpxfer</TT
> from the NNTP server
distribution here. Suck has already discussed earlier. We will be happy
to take contributed additions that discuss other client software.</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="AEN1235">11.3. Special clients</H2
><DIV
CLASS="SECTION"
><H3
CLASS="SECTION"
><A
NAME="AEN1237">11.3.1. NNTPCache</H3
><P
>NNTPCache is an interesting transparent cacheing proxy for
news articles. News articles are read-only by definition,
<EM
>i.e.</EM
> 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.</P
><P
>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.</P
><P
>We list it here as an NNTP client because every proxy server
is a server on one side and a client on the other.</P
></DIV
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="x1094.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="x1243.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Monitoring and administration</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
> </TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Our perspective</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
