局域網聊天系統__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
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章