即时通讯软件设计(一)
之前寫了移動市場的淺談,當時是想緊接著寫這個系列的。包括即時通訊、播放器等。后來因為要回家定親加上要看房子,拖延了下來。今天接著寫,算是上班打醬油吧。也趁此機會罵下樓市,真心黑。破縣城都四千多五千。廢話不說了,說正題了。
做一款軟件,首先需要明確的不是你是單機的還是分布式的,cs的還是bs的。這些都是后話。第一個遇到的問題是這款軟件要實現(xiàn)什么功能,也即是市場以及設(shè)計者開發(fā)者對于這款軟件的需求預(yù)期是什么。
因為即時通訊軟件是比較成熟的了。所以功能就很好列出來。對于功能,最實惠一目了然的描述方法就是用例圖了。不過悲劇的是公司把端口給禁用了,上傳不了圖片。萬惡的公司。所以這里我就簡單羅列下了。
功能列表:
- 聊天:這個會包括三種方式(語音聊天、視頻聊天、文字聊天)。其又擴展為兩個場合(單人、多人)。其中文字聊天又包括文本、表情、圖片。其中表情可擴展為基本表情、自定義表情。
- 傳輸:擴展為兩種,文件傳輸、文件夾傳輸。其中功能點要包括:在線傳輸、離線傳輸。而且需要實現(xiàn)斷點續(xù)傳。
- 頻道:其實這個和聊天應(yīng)該歸屬一個功能點下面的兩種。也可以說類似多人聊天,唯一不同的就是弱管理。用戶自己可申請開戶,然后再分到的頻道中發(fā)布相關(guān)信息,其他用戶可通過搜索頻道進入該電臺,然后在其中進行接受信息,并支持交互。
- 外圍方面,在硬件方面,包括移動端、PC端接入程序。即用戶可以使用手機、平板、PC等登陸。
- 客戶端:即用戶接入程序。通過接入程序,用戶可以實現(xiàn)上面的所有功能。這個包括pc版本、平板版本、手機版本等。具體還要適配一大堆類型出來。工作量不可小覷,不過總體而言,他的開發(fā)策略就是原型式的,一處編寫到處修改。所謂適配就是改改改。
- 服務(wù)器:負責處理一些必要的后臺信息,如用戶登陸時的相關(guān)鑒權(quán)以及信息登記。?因為服務(wù)器不需要適配不同的機型。服務(wù)器用什么是我們說了算,終端用戶也不關(guān)心。所以在初期可以直接指定windows還是linux下的某一款。此處就暫定windows了。這邊適用的開發(fā)策略就是迭代式的了,因為功能繁多,慢慢迭代吧。個人不覺得迭代屬于敏捷開發(fā),可能緣于個人對于敏捷的排斥,始終覺得這就是騙子,混飯吃也就罷了,還坑爹。尤其看到那些什么敏捷開發(fā)交流大會,個人感覺與傳銷無異。
即時通訊,對于互聯(lián)網(wǎng)第一個遇到的問題是負載的問題。服務(wù)器的能力畢竟有限。這個時候不得不考慮第一個服務(wù)器進行專職化,就是多些服務(wù)器,各盡其職。重要的就是彼此之間職責要清晰。于是就出現(xiàn)了幾個服務(wù)器,第一個是專門用來接收用戶登錄的,負責鑒權(quán)以及更新數(shù)據(jù)庫。第二個是專門負責通信的,即用戶與用戶想互相說話,因為網(wǎng)絡(luò)問題,他們自己說不了,于是找了個中轉(zhuǎn)站。但是負載的問題依然存在,客戶多了,通信量大了,通信服務(wù)器扛不住。于是就想到了兩個辦法,第一就是治標不治本的辦法,搞集群,一大堆中轉(zhuǎn)服務(wù)器,但是瓶頸依然存在。第二個就是分流,能不通過通信服務(wù)器的就別走通信服務(wù)器了,于是就想到了P2P。經(jīng)濟實惠的辦法還是P2P吧,雖然他的實現(xiàn)對于網(wǎng)絡(luò)有一些要求。
于是乎整個軟件的結(jié)構(gòu)就清晰了。他主要包括:客戶端、服務(wù)器兩塊。其中服務(wù)器分:登錄服務(wù)器、通信服務(wù)器。具體會話的流程如下描述。
- 登錄:用戶首先登錄服務(wù)器,表明自己在線。用戶連接登錄服務(wù)器的指定端口,發(fā)起登錄請求。請求中攜帶必要的鑒權(quán)信息。登錄服務(wù)器找鑒權(quán)服務(wù)器進行鑒權(quán),并根據(jù)鑒權(quán)結(jié)果跳轉(zhuǎn)處理策略。如果鑒權(quán)成功,則生成唯一的合法性SESSIONID(其中SESSIONID的一部分由用戶唯一ID組成),并將連接信息以及改ID打包交付數(shù)據(jù)庫服務(wù)器,其中狀態(tài)位標注為登錄,數(shù)據(jù)庫服務(wù)器負責入庫操作,存入的表為狀態(tài)表,并返回是否入庫成功。登錄服務(wù)器根據(jù)數(shù)據(jù)庫服務(wù)器的返回結(jié)果繼續(xù)跳轉(zhuǎn)處理策略。如果成功,則回復(fù)登錄成功的消息給用戶,并在消息體中攜帶連接服務(wù)器的相關(guān)信息以及SESSIONID。如果失敗則回復(fù)客戶端服務(wù)器繁忙,稍后再試。數(shù)據(jù)庫服務(wù)器定時掃描該狀態(tài)表,如果超過30s,而且狀態(tài)為非在線狀態(tài)的,則刪除該記錄。
- 連接:用戶接收到登錄服務(wù)器的返回結(jié)果,如果失敗,直接提示用戶即可。流程結(jié)束。如果成功,則從消息體中獲取連接服務(wù)器的信息,釋放與登錄服務(wù)器的連接,并使用之前的端口與連接服務(wù)器進行嘗試連接,連接失敗,直接提示用戶網(wǎng)絡(luò)超時。如果連接成功,則發(fā)送連接請求信息,其中消息體攜帶SESSIONID。連接服務(wù)器接收遠程連接之后,首先將其套接字標注為未初始化,當接收到客戶的連接請求時,從消息體中回去SESSIONID,然后將客戶端的連接信息以及SESSIONID打包發(fā)送至數(shù)據(jù)庫服務(wù)器進行進一步合法性檢查,如果數(shù)據(jù)庫服務(wù)器發(fā)現(xiàn)其一致,則回復(fù)合法,否則回復(fù)非法。連接服務(wù)器根據(jù)數(shù)據(jù)庫服務(wù)器的回復(fù)進行跳轉(zhuǎn)處理策略。如果接受到的是非法,則直接拒絕,強制中斷客戶端的連接。客戶端發(fā)現(xiàn)連接被強制中斷之后提示用戶服務(wù)異常。如果合法,則將SOCKET狀態(tài)更改為連接。并發(fā)送命令至數(shù)據(jù)庫服務(wù)器查詢該SESSIONID對應(yīng)的用戶的相關(guān)信息,如好友列表、頭像、個性簽名等等,消息中并且攜帶在線好友,數(shù)據(jù)庫服務(wù)器接收到該消息,首先將之前紀錄的狀態(tài)更新為在線,然后去查詢相關(guān)表,將查詢到的信息打包返回至連接服務(wù)器。連接服務(wù)器接到信息之后轉(zhuǎn)發(fā)給用戶。數(shù)據(jù)庫服務(wù)器定時掃描狀態(tài)表,并通過連接服務(wù)器以保證客戶端信息同步。
- 用戶需要發(fā)起會話時,首先對連接服務(wù)器發(fā)起會話請求信息。連接服務(wù)器發(fā)送響應(yīng)消息至A,消息體中攜帶通信服務(wù)器的相關(guān)連接信息。A接收消息后,根據(jù)消息體中的信息對通信服務(wù)器建立TCP連接。
- 消息中攜帶需要會話的用戶的唯一ID。連接服務(wù)器根據(jù)該唯一ID進行查詢狀態(tài)表,如果存在,則表示需要對話的用戶在線。則直接將請求消息中轉(zhuǎn)給通信服務(wù)器,通信服務(wù)器通知B用戶會話請求信息,消息中攜帶A用戶的連接信息。B接到消息之后直接對A發(fā)起一UDP數(shù)據(jù)包,消息體為空。然后B發(fā)送響應(yīng)信息至通信服務(wù)器,通信服務(wù)器通知A現(xiàn)在可以開始與B會話。其中此處UDP與TCP使用同一端口。如果B不在線,則發(fā)送消息通知A,讓其直接將信息發(fā)送至通信服務(wù)器,通信服務(wù)器負責保存本地。等B上線時再進行轉(zhuǎn)發(fā),其中保存時間可以設(shè)置。
- 離線。A斷開與連接服務(wù)器的連接。連接服務(wù)器發(fā)送命令至數(shù)據(jù)庫服務(wù)器更新狀態(tài)表中狀態(tài)為離線。數(shù)據(jù)庫服務(wù)器定時掃描狀態(tài)表,并觸發(fā)相應(yīng)流程用于通知客戶好友的上線與離線,并保證狀態(tài)表的清潔。
- 客戶端:用于讓用戶接入系統(tǒng)
- 注冊服務(wù)器:用戶接入系統(tǒng)時使用,提供鑒權(quán)等相應(yīng)處理
- 連接服務(wù)器:用于保持與所有用戶的連接,狀態(tài)消息的通知以及客戶會話請求時通信服務(wù)器相關(guān)信息的返回。
- 通信服務(wù)器:用于通信渠道的建立以及離線信息的保存。包括離線文件傳輸。根據(jù)實際情況可以考慮增加一臺文件服務(wù)器,供通信服務(wù)器使用。
- 數(shù)據(jù)庫服務(wù)器:提供對于數(shù)據(jù)庫所有的操作接口。所有關(guān)于數(shù)據(jù)庫的操作均歸必須通過該臺位。
- 鑒權(quán)服務(wù)器:可有可無,供注冊服務(wù)器使用,主要用于鑒權(quán)。
?
轉(zhuǎn)載于:https://www.cnblogs.com/BLoodMaster/archive/2012/10/08/2715369.html
總結(jié)
以上是生活随笔為你收集整理的即时通讯软件设计(一)的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: SQL SERVER 数据库清空语句 忽
- 下一篇: 《Effective C#》读书笔记——