中途加油
       
       这个系列写到四的时候，因为博客中国升级，被中断了。搬家之后，一直想早些续上，可总有一口气提不起来的感觉，迟迟不能动笔。正应了那句老话：一鼓作气，再而衰，三而竭。

       还算好的是，现在还在再而衰的阶段，还没有气竭，还可以再鼓一下，继续往下写。

IM

       上回的末尾，提出一个问题：为什么这个系统叫PIMS？IM从何而来？

       IM就是Instant Messaging的缩写，即时消息的意思。那么，即时消息又是什么意思呢？

       即时消息，意思就是消息在信道中总是即时传递的。消息在信道中传递的过程中，遵循如下的简单规则：

       是否有未拥塞路径通往消息的接收者？有，则往路径的下一个节点发送；没有，则将消息丢弃，并回送错误消息。（注意，错误消息路径如果中断，则简单丢弃，不再回送错误的错误。）

       这个规则，意味着，消息无错漏，无重发等等，都是由应用中的两个端点来保证。这有点象IP网络，有点象UDP协议。事实上，目前主流的IM系统，在主体上都是基于UDP来做的。

       作为应用层面的对照，大家可以参考一下熟知的Message Queue的概念。

       把这个系统实现成IM系统，源于当时我不小心看到的一个IM开源项目的启发。（那个开源项目的名字，忘掉了，对不起）

实施

       设计完成了之后，在实施上只存在一个困难：如何维护路由？收到一个即时消息之后，如何寻找其传递路径？

       我上网查了一下资料，发现路由的实现，大致上可分为两种策略：

       一。在每一个路由节点处维护一份网络节点图。当网络状态发生改变（节点间的连接建立或者拆除）时，当事节点向网络广播适当的路由信息。节点收到路由信息包时，更新网络图，并重算所有节点的最短路径。当数据包到达节点时，节点依据目的地址的最短路径发送。

       二。在每一个路由节点处只维护到达所有节点的最短路径。对于一个节点来说，维护到达另一个节点的最短路径，只需要存储下一个相邻节点就可以了。当节点收到路由信息包时，更新通往所有节点最短路径的下一个节点。这个算法稍微复杂一些，但是存储量相对较少。

       我们选择了第一种策略，理由是：

       一。作为企业级的应用平台，网络节点是相对有限，可数的。所以在每个路由处维护网络地图，可以接受。这样可保证算法的简单。

       二。作为管理的需要，我们希望在每个路由处都能观察网络全景。当然，这也极大地方便了我们的测试。

平台

       有了PIMS这个平台，我们只花了一个月的时间就在上面构造了新的网络交易系统。

       一个月后，在市场需求的刺激下，我们又做了一个CA证书的申请，发布和管理系统。也是在这个PIMS上做的，历时一个月。

       这个平台的潜力是非常巨大的。不足之处在于其中用到了盛润的安全库。