PHP应用程序设计：一个实际的例子（2）

IRC网络基础

现在我们已经为聊天室的设计选择了一个交流标准，下面看一看I R C网络究竟是如何建立的。
理想的情况是，你应该在选择I R C之前，评价这一节所讨论的I R C网络基础。因为在已经决定使用I R C之后，才发现I R C引入了非常复杂的结构，这是非常不好的。然而到这里为止，为了应用程序规划的目的，我们已经使用有关IRC网络的“共用知识”来工作了。现在我们已经介绍了一个可以用在应用程序（I R C）上的“正确的”方法。这部分提供了你执行这个规划所需的详细信息。
I R C网络对于客户端和服务器端是有区别的。用户只需要使用一个特殊的客户端软件就可以参与网络活动，同时，这就建立了一个到服务器到客户端的连接。通过特殊服务器的连接，所有网络上的服务器之间是连通的。当前的I R C服务器执行只支持分层结构，意味着连接服务器时绝对不能有多余的方法。这形成了一个像树一样的倾向于形成网状分支的结构，但是这同时也大大的简化了路径：所有的服务器只需要把输入数据传送给所有其他连接就可以了，不用担心给一个服务器传送多余的信息。
每一个服务器可以拥有很多用户，用户数的最大值取决于这个服务器愿意接受的连接数量（当然，就网络容量和服务器负载而言，也存在限制）。如图3 - 2所示，每个服务器都可以通过穿梭或多或少的服务器中继段而连接到其他所有服务器。例如：服务器C和服务器F可以带动在同一通道中的用户（通道是I R C的聊天室—人们可以见面和聊天的地方）。在这个例子中，服务器C可以通过它的唯一的连接将数据传送给服务器B。服务器B再把数据分布给它的其他连接，即服务器A和服务器D。服务器A没有任何其他的连接，所以它不干任何事情，但是服务器D将把数据又传给服务器E，然后服务器E又传给服务器F。这非常容易实现，但有一个缺点：如果服务器A没有任何连接进来的用户参与到服务器C传送数据的通道中，那么在这个通道中的以服务器A为目标的所有数据都会浪费带宽。
I R C的R F C和互联网上所有开放的标准相似， I R C协议的基础是在一个R F C（Request For C o m m e n t s）中指定的。I R C使用的R F C是RFC 1459，例如， w w w. i r c h e l p . o rg网站上有许多关于IRC的的信息。

这是一个被设计所限制的网络的一个主要问题：所有的共用信息流都必须到达所有的服务器。但是，在我们打算执行I R C网络的时候，这些问题在连接时真的会出现吗？当然不会，因为在一个标准的服务器主机中，我们要处理的用户数量永远也不会大到有害的程度。在国际互联网中，这样的问题应该根本不会产生。
为了减少关键连接的总数量，网络可以按照它的物理拓扑结构来布局。如果一个服务器的连接超过它的剩余容量，它可以采用比其他服务器多的叶结构（连接许多叶节点到只有一个小的中枢服务器上是没有意义的）。另一个可选的方法是安装一个适合这个网络的路径。例如：美国的服务器设置在美国，而德国的服务器设置在德国等等。从法兰克福有一个到纽约的海外连接，在法兰克福的I R C服务器就应该连接到美国的服务器上（依据这个网络的物理布局）。这可以通过另一种方式来做到：法兰克福可以连接到波兰，随便举的一个例子。但是如果波兰自己没有海外连接的话，从法兰克福到波兰的这个路径的连接就需要找到其他的出口到达大洋彼岸—它可以绕到其他国家（甚至是两个，三个或者更多的国家）直到它找到一个自由的海外连接为止。这些附加的路径浪费了许多网络带宽。因而所作的尝试是为了使I R C网络结构最好地适应这个内部的物理网络结构。
这些设计问题只有在最大型的、负载有成千上万的用户的网络中才会出现。这些网络才真正地需要为它的中枢系统找到可靠的连接。典型的基于网络聊天室或者网络不太可能同时负载1 000个用户，所以你不会一开始就碰到严重的问题。然而为了避免复杂性，围绕这些最终还是会出现的各种各样的问题，作一些规划是个不错的想法。从服务器的角度来看，这个网络结构如图所示。

这里执行的结构类似于一个多路转接器、多路分解器和一个网络交换机的混合物。从客户端到网络端的方向来看，服务器压缩了从客户端传来的所有数据，然后把它传送到网络连接上。在另外一个方向上，它决定网络端的哪一个信息对哪一个用户来说是非常重要的，然后把它传送到合适的连接中。所有网络传来的要被继续传递的其他数据就直接被送走了。
这基本上就是我们需要对聊天系统所作的初始化设置。现在花一点时间试着想一下我们该如何实现我们的目标。我们需要一个正在工作的符合下列条件的服务器环境：
• 允许I R C网络连接。
• 允许I R C的用户连接。
• 提供基于互联网的用户接口。
• 尽可能容易的执行。