23.1. 一些 INN 内部原理

INN 的核心程序是 innd 守护进程。innd 的任务是处理所有传入的文章，将它们存储在本地，并在需要时将它们传递给任何传出的新闻源。它在启动时启动，并作为后台进程持续运行。作为守护进程运行可以提高性能，因为它只需在启动时读取一次其状态文件。根据您的新闻源的容量，某些文件，例如历史记录（其中包含最近处理的所有文章的列表）可能从几兆字节到几十兆字节不等。

INN 的另一个重要特性是，在任何时候都只有一个 innd 实例在运行。 这也对性能非常有益，因为守护进程可以处理所有文章，而无需担心将其内部状态与其他同时在新闻 Spool 中搜索的 innd 副本同步。 然而，这种选择影响了新闻系统的整体设计。 因为尽快处理传入新闻非常重要，所以服务器被诸如为通过 NNTP 访问新闻 Spool 的新闻阅读器提供服务，或解压缩通过 UUCP 到达的新闻批处理等平凡任务所束缚是不可接受的。 因此，这些任务已从主服务器中分离出来，并在单独的支持程序中实现。 图 23-1 试图说明 innd、其他本地任务以及远程新闻服务器和新闻阅读器之间的关系。

如今，NNTP 是传输新闻文章最常用的方式，而 innd 不直接支持任何其他方式。 这意味着 innd 监听 TCP 套接字（端口 119）以进行连接，并使用 “ihave” 协议接受新闻文章。

通过 NNTP 以外的传输方式到达的文章通过让另一个进程接受文章并通过 NNTP 将其转发到 innd 来间接支持。 例如，通过 UUCP 链接传入的新闻批处理传统上由 rnews 程序处理。 INN 的 rnews 在必要时解压缩批处理，并将其分解为单独的文章； 然后，它将它们逐个提供给 innd。

当用户发布文章时，新闻阅读器可以传递新闻。 由于新闻阅读器的处理值得特别关注，我们稍后将对此进行讨论。

接收文章时，innd 首先在历史记录文件中查找其消息 ID。 重复的文章将被删除，并且可以选择记录这些事件。 对于太旧或缺少某些必需标头字段（例如主题）的文章也是如此。[1] 如果 innd 发现文章可以接受，它会查看新闻组标头行，以找出文章已发布到哪些组。 如果在active文件中找到其中一个或多个组，则该文章将被归档到磁盘。 否则，它将被归档到特殊组 junk。

单个文章保存在/var/spool/news下，也称为 新闻 Spool。 每个新闻组都有一个单独的目录，其中每篇文章都存储在一个单独的文件中。 文件名是连续的数字，因此 comp.risks 中的文章可以归档为comp/risks/217例如。 当 innd 发现它想要存储文章的目录不存在时，它会自动创建它。

除了在本地存储文章外，您可能还希望将它们传递到传出的新闻源。 这由newsfeeds文件管理，该文件列出了所有下游站点以及应馈送到它们的新闻组。

就像 innd  的接收端一样，传出新闻的处理也由单个接口处理。 innd 没有自己完成所有特定于传输的处理，而是依靠各种后端来管理文章到其他新闻服务器的传输。 传出设施统称为 通道。 根据其用途，通道可以具有不同的属性，这些属性确定 innd 传递给它的确切信息。

例如，对于传出的 NNTP 新闻源，innd 可能会在启动时 fork innxmit 程序，并且对于应通过该新闻源发送的每篇文章，将其消息 ID、大小和文件名传递给 innxmit 的标准输入。 另一方面，对于传出的 UUCP 新闻源，它可能会将文章的大小和文件名写入一个特殊的日志文件，该日志文件由另一个进程定期读取，以便创建批处理并将它们排队到 UUCP 子系统。

除了这两个示例之外，还有其他类型的通道不完全是传出的新闻源。 例如，这些通道用于在归档某些新闻组或生成概述信息时。 概述信息旨在帮助新闻阅读器更有效地对文章进行线程处理。 旧式新闻阅读器必须单独扫描所有文章才能获得线程处理所需的标头信息。 这会对服务器机器造成巨大的压力，尤其是在使用 NNTP 时； 此外，速度非常慢。[2] 概述机制通过在单独的文件（称为.overview）中预先记录每个新闻组的所有相关标头来缓解此问题。 然后，新闻阅读器可以通过直接从 Spool 目录读取此信息，或者在使用 NNTP 连接时使用 XOVER 命令来获取此信息。 INN 让 innd 守护进程将所有文章馈送到 overchan 命令，该命令通过通道连接到守护进程。 稍后当我们讨论配置新闻源时，我们将了解这是如何完成的。