INN帮助文档中经常提到 feeder（喂食者） 和 reader（读者），也有人将其翻译为上游和下游。但是根据新闻组的架构，往往难以分清这两个角色。

对于集中控制（单一服务器）的新闻组，结构非常简单，只需要一台机器控制外部来的喂信（incoming feed）、向外部喂信（outgoing feed），建立和用户的连接，提供文章发布（posting）和阅读（reading）。缺点是存在单点故障。

分布式结构有使用共享池，文章复制等结构。参见：《INN Architecture Guide》。

当INN被设定为批处理方式进行 newsfeed的情况下， News的工作流程为：

News 使用者是透过News Reader软体来读取(Read) 或发送 (Post) , 这类软体可以称之为News界面软体或者News读取软体。 当使用者发送出一封讨论信时, News Server 立刻接手处理。首先Server 会把该封讨论信放在自己的News Spool (/var/spool/news) 之下, 同时 在外送预备区 (通常是/var/spool/news/out.going/site 或 /var/spool /news/out.going/site/togo) 留下一份记录。 这里, News Server对 News Reader的服务是即时的, 也就是说, 以上这些流程是一瞬间完成, 而且是连贯的。

接下来就由News Transport软体接手, 不过, News Server到News Transport之间就不一定是即时进行, 正常的话, 负责执行传输的软体 是由 cron 定时启动, 之後依照/var/spool/news/out.going/site这份 记录, 把News外送到下游的News Server。 照内定状态, INN 与 C-News 的传输工作都必须透过 cron 来带动, 这是典型的批次处理模式。

整个Usenet的架构, 就是这样一个News Server 把讨论信传给另一 部News Server, 如此由点而面, 构成一个资讯传输网。 再次提醒读者, Usenet 中的 诸多News Server彼此之间的差异可能非常大, 诸多常见的 传送方法包括卫星传送、 NNTP over TCP/IP传送、 UUCP dialup、 UUCP over TCP/IP、 E-mail (用任何可能的Mail Transport Agent)等 等, 一部Server Server只要使用何其上下游News Server 相同的传输 方法即可, 而无须顾虑外面世界究竟如何。

另外还有一点与News Transport相关的观念, 对NNTP传输方式来说, News 的喂送, 通常是上游的News Server「主动」将News喂送到下游的 News Server。 举个例子来说, 我们所需要的Newsgroups, 是我们的上 游News依照我们所要求的 (也就是我们指定订阅的) 讨论区newsgroups, 不多不少的传送过来, 我们只需要「被动」的接受即可, 换个角度, 对 於我们这一端产生的东西, 也是我们主动传给我们的上游News Server。 这个说明适用於大部分的情况, 至於其例外, 我会在後面专门来介绍News 传输的篇幅中, 更详细的介绍。