局域网聊天系统__2.服务器业务逻辑分析

服务器业务逻辑分析：
 

  首先分析服务器应该实现的功能，在需求分析中并没有提到客户端和客户端的通信是否需要通过服务器转发，这里选择的是客户端之间直接进行点对点通信，无需经过服务器处理，这样使得服务器的工作减少了很多，只需要管理和更新成员列表以及保存离线消息即可，服务器甚至不需要多线程的支持。

 在服务器与客户端交互的过程中，一个完整的流程应该是：

     1.服务器开启监听

     2.客户端输入用户名密码以及服务器信息登录

     3.服务器收到客户端请求 接收请求

     4.客户端在连接成功后，开始请求用户列表

     5.服务器收到列表请求，核查用户信息的正确性，在信息有误时向客户端发出提示，

          信息无误则将用户加入到用户列表，并更新服务器显示

     6.客户端检查到服务器发出的错误消息时，弹出该消息并退出。否则用户更新显示服务器发来的用户列表

     7.服务器检查有无新上线用户的离线消息，并转发给该用户

     8.客户端收到服务器转发的离线消息时，显示聊天内容

     9.此时服务器和该客户端已经正常连接。之后两者的交互主要在：

          服务器删除离线用户或者有用户上下线时，通知该用户更新列表

          该客户端在向离线用户发送消息时，将消息转交给服务器保存

     注：6，7步可调换 

         

---

数据包和关键数据结构设计：

     

•      服务器主窗口所需要维护的关键数据：

        CObList m_UserList; 

          该链表保存用户服务器界面显示的所有用户的详细信息。用CObList的自带的Serailize可以简化序列化通信

        CObList m_ChatterLIst：

           如同大多数C/S模型的聊天程序，这里的服务器自然要保存一个客户端类链表，这个客户端类和用户信息不同，它应该各自保存一个与对应的客户端通信的套接字，并且封装一些与客户端通信的函数。在CSocket模型中，该套接字是隐藏的，用户只需要重载OnReceive以实现接收数据，并且可以在任何需要的时候通过序列化实现发送数据。

•      客户端类应该维护的关键数据：

        CUserInfo m_UserInfo；

            这里假定CUserInfo即为我们设计出来的用户信息类，客户端类保存其对应客户端的信息是为了当该客户端类收到新的数据处理时，服务器主处理程序可以很方便的通过该类指针得到该用户信息，反之亦然。因为服务器包里面包含的应该是用户信息而不是客户端类，而服务器实际通信却是通过客户端类 

  

•      用户信息类CUserInfo：

          前面提到，由于用户信息需要通过序列化在服务器和客户端之间传送，因此它自然应该是一个支持序列化的类。这个类除了序列化函数之外，只维护一些用户的必要数据。主要包括：

          用户名 密码 IP地址 端口 登录或下线时间

          前两者用于服务器验证刚登录的用户信息合法性。后两者用与转发给其他用户，使得其他用户可以自由聊天，不经由服务器

•      另外就是服务器和客户端通信的数据包了。由于服务器和客户端通过序列化实现数据传输，因此这里的数据包当然不能只是一个简单的数据结构，它至少应该是一个支持序列化的类(可以直接派生于CObject)。这个数据包应该包含服务器和客户端所有可能交互的消息类型。包括:

     用户列表   离线消息   服务器消息(用于向客户端发送提示或警告信息)

---

     分析到这里服务器模型已经有了一个简单的框架，剔除了具体类的实现和它们的交互。这些应该在下一步分析用到。

完整源代码下载地址点击这里：http://download.csdn.net/detail/wudaijun/4911762