要做聊天功能,首要要解決的就是伺服器對客戶端訊息推送的問題.
方法有三:
1.輪詢.客戶端與伺服器使用http協議,客戶端定時去訪問伺服器,達到一種"偽實時推送"的效果.缺點就是這個時間間隔不好把握.而且可能會比較耗電.在http1.1以前,每次客戶端訪問伺服器預設是建立乙個tcp連線,即每次都要三次握手建立連線.在http1.1後,http頭中連線預設是保持的,第一次訪問建立,以後訪問將使用與上一次同乙個連線.保持連線可以減輕伺服器的壓力,但是沒根本解決http協議的缺陷,只能夠客戶端訪問,伺服器被動響應.要做到伺服器主動推送是不大可能的.
2.建立持久連線. 自己動手使用socket進行網路程式設計.tcp(我是用tcp),udp
3.簡訊推送.這個不多說了,最大問題是成本高
伺服器由主資料庫、資料介面伺服器、聊天伺服器三部分組成。
資料介面伺服器可實現使用者與資料庫資料交換與共享。本軟體實現了以下功能指標
（1）安全的使用者驗證機制、對關鍵的傳輸內容進行rsa加密，保障使用者個人資訊、賬號的安全。同時伺服器端進行防注入加強。防止使用者資訊被註解。
（2）採用http協議進行通訊，具有統一的資料輸出介面。保證客戶端傳送請求後伺服器按需進行資料返回。
聊天伺服器實現使用者的即使聊天功能以及系統訊息推送。
（1） 聊天伺服器與資料介面伺服器分離，減輕伺服器壓力。
（2） 使用tcp協議建立伺服器-使用者的連線，使用者傳送資料後經伺服器**給其他使用者，實現實時聊天功能。同時，通過tcp長連線，系統可以向使用者推送即使訊息。
（3） 聊天伺服器通過共享資料介面伺服器的使用者驗證機制。保證使用者聊天功能的安全性。
主資料庫存放所有的資料表，向以上兩個伺服器提供共享資料。使用資料庫為伺服器共享資料，減少了資料的冗餘度，避免重複建立資料
NND 那個聊天室的基本結構設計完了
伺服器 接受到訊息然後然後廣播給所有的使用者 socket 採用udp 通訊 所有訊息並顯示於其它的客戶端中 客戶端下線或斷開連線傳送訊息給伺服器端，伺服器刪除其 socket 定義一下資料報結構 struct messagedata 資料報的結構 recvbuffer imessagetype 0...
一套能體現 RBAC 的表結構設計
3 總結 rbac role based access control 即基於角色的訪問控制，是一種許可權設計思想。在 rbac 中，許可權與角色相關聯，使用者通過成為適當角色的成員來獲得這些角色的許可權。相較傳統的訪問控制 自主訪問 強制訪問 來說，rbac 能更好的支援最小許可權 責任分離和資料...
領悟到一點資料結構設計思想
物件導向思想 就以資料庫設計為例子，比如對於乙個變電站裝置的端子排，要描述乙個端子排的所有接線資訊。對於這個問題，我們可以從物件導向的角度出發，劃分出這個問題所涉及到的所有物件以及物件之間的關係，由此得，物件有 裝置 進出端子 芯線 端子互聯線 電纜5個物件，物件間的關係是端子所屬乙個裝置，電纜包裹...