簡介來自吉林大學(xué)軟件學(xué)院的C課程設(shè)計優(yōu)秀作品圍繞“模擬即時通信系統(tǒng)”展開以面向?qū)ο蟪绦蛟O(shè)計方法實現(xiàn)類QQ/微信整合平臺的用戶基本信息、好友管理、群管理三大核心模塊。支持好友增刪改查、共同好友推薦以及群加入、退出、成員查詢、臨時討論組等差異化策略貼近真實社交軟件業(yè)務(wù)邏輯適合C課程設(shè)計選題參考或進(jìn)階練習(xí)。資源包共153個文件以cpp/h源碼、sln/vcxproj工程配置、exe可執(zhí)行程序及SQLite數(shù)據(jù)庫為主體附帶調(diào)試記錄與編譯中間文件整體約354MB結(jié)構(gòu)完整便于直接研讀與運(yùn)行驗證。已有1317人瀏覽學(xué)習(xí)。這份作品的價值在于呈現(xiàn)了一個可運(yùn)行、可擴(kuò)展的完整課設(shè)方案源碼模塊劃分清晰如Tencent_information、Chat_function、judgment等并附有可直接運(yùn)行的exe和數(shù)據(jù)庫文件能幫助讀者快速理解面向?qū)ο蠼Ｅc文件/數(shù)據(jù)庫操作的綜合應(yīng)用也可作為答辯展示和功能擴(kuò)展的起點(diǎn)。1. 一份C課程設(shè)計資源包即時通信系統(tǒng)恰好踩中了課程設(shè)計的核心考點(diǎn)如果說C面向?qū)ο蟪绦蛟O(shè)計課程設(shè)計里有一個既能拿高分又不會爛大街的選題即時通信系統(tǒng)一定是排在前三的那個。我這次拆的這個源碼包功能閉環(huán)很完整注冊登錄、好友管理、單聊與群聊、離線消息附帶設(shè)計文檔和答辯參考。它最大的價值不是“能跑通”而是把網(wǎng)絡(luò)收發(fā)、界面渲染、業(yè)務(wù)狀態(tài)拆成了顆粒清晰的類真正對得起面向?qū)ο筮@四個字。適合正在找課程設(shè)計素材、準(zhǔn)備答辯、或者想補(bǔ)一下“從demo變成可演示系統(tǒng)”這一課的人。模塊拆得好后面驗收、答辯、二次開發(fā)都省事。2. 整體架構(gòu)與類設(shè)計七張類圖把網(wǎng)絡(luò)、界面、數(shù)據(jù)徹底切開2.1 為什么一個課程設(shè)計值得用C/S架構(gòu)和分層來做很多同學(xué)的課程設(shè)計喜歡做單機(jī)通訊錄代碼量不大但答辯時老師問一句“你這個核心業(yè)務(wù)流程怎么擴(kuò)展”基本就卡住了。即時通信系統(tǒng)天然是C/S架構(gòu)客戶端負(fù)責(zé)交互服務(wù)器負(fù)責(zé)轉(zhuǎn)發(fā)與狀態(tài)維護(hù)這個拆分本身就逼著你做模塊化設(shè)計。我在這個資源包里看到的做法是三層結(jié)構(gòu)表現(xiàn)層登錄窗口、主窗口、聊天窗口只做界面渲染與用戶操作響應(yīng)。業(yè)務(wù)層好友管理、消息路由、登錄態(tài)校驗不依賴具體socket代碼。數(shù)據(jù)層賬號存儲、會話記錄接口與實現(xiàn)分離。這個選型的好處很直接網(wǎng)絡(luò)模塊掛了界面不應(yīng)該跟著卡死數(shù)據(jù)庫換了業(yè)務(wù)層不需要改。課程設(shè)計答辯時老師問到“為什么這么設(shè)計”三層分離是最容易講清楚的答案。我一般會建議照著這個結(jié)構(gòu)做因為它是經(jīng)過大量項目驗證過的不是課程設(shè)計特有的產(chǎn)物。2.2 核心類與對象關(guān)系從基類抽象到接口回調(diào)類設(shè)計是整個資源包的重頭戲。它的核心類可以概括成六個CNetCore負(fù)責(zé)socket收發(fā)CMsgProtocol負(fù)責(zé)協(xié)議編解碼CUser封裝用戶信息CRoom管群聊成員CAccountStore管賬號數(shù)據(jù)CMsgEvent作為事件載體在業(yè)務(wù)層流轉(zhuǎn)。// netcore.h #pragma once #include winsock2.h #include QString class CNetCore { public: bool Startup(); // 初始化 Winsock 并創(chuàng)建 socket bool ConnectTo(const QString host, quint16 port); bool SendPacket(const char* data, int len); int RecvPacket(char* buffer, int capacity); void Close(); private: SOCKET sock_; bool isConnected_; };這個類的設(shè)計有一點(diǎn)很關(guān)鍵把SOCKET封裝成成員變量外部代碼不直接碰句柄所有對socket的操作都收口到CNetCore的方法里。ConnectTo接收主機(jī)名和端口內(nèi)部完成域名解析與connect調(diào)用SendPacket只負(fù)責(zé)把字節(jié)流發(fā)出去不關(guān)心它是什么協(xié)議這樣協(xié)議層與傳輸層就解耦了。你可能會問為什么不把協(xié)議解析也放進(jìn)CNetCore因為職責(zé)不同。CNetCore解決“怎么把數(shù)據(jù)發(fā)出去”CMsgProtocol解決“發(fā)出去的數(shù)據(jù)長什么樣”?；煸谝黄鸷蟾膭訁f(xié)議會導(dǎo)致網(wǎng)絡(luò)模塊全部重編沒必要。2.3 數(shù)據(jù)層實現(xiàn)賬號存儲與登錄態(tài)分離賬號數(shù)據(jù)在這個項目里用的是SQLite表結(jié)構(gòu)就兩張一張存賬號信息一張存好友關(guān)系。CAccountStore對外暴露Register、Verify、GetFriendList三個方法內(nèi)部是參數(shù)化SQL語句避免拼字符串帶來的注入問題。bool CAccountStore::Register(const QString name, const QString pwd) { QSqlQuery query(db_); query.prepare(INSERT INTO t_account(name, pwd_hash) VALUES(?, ?)); query.addBindValue(name); query.addBindValue(EncryptPwd(pwd)); return query.exec(); } bool CAccountStore::Verify(const QString name, const QString pwd) { QSqlQuery query(db_); query.prepare(SELECT pwd_hash FROM t_account WHERE name ?); query.addBindValue(name); if (!query.exec() || !query.next()) return false; return query.value(0).toString() EncryptPwd(pwd); }EncryptPwd這里用的是簡單哈希加鹽不是明文存密碼。課程設(shè)計階段不需要上多復(fù)雜的加密但至少要有這個意識。你仔細(xì)看這個設(shè)計CAccountStore沒有任何網(wǎng)絡(luò)相關(guān)代碼它不知道消息從哪來這保證了數(shù)據(jù)層可以被單獨(dú)測試。我之前看到過不少課程設(shè)計把SQL語句直接寫進(jìn)窗口類里窗口關(guān)閉時數(shù)據(jù)庫連接還開著邏輯全攪在一起Debug時全是玄學(xué)問題。這個資源包的做法才是能落地的。3. 網(wǎng)絡(luò)模塊與消息協(xié)議從socket到可靠收發(fā)要走完的三步3.1 客戶端socket封裝初始化、連接、非阻塞模式網(wǎng)絡(luò)模塊是即時通信系統(tǒng)里最容易翻車的地方原因不是socket本身難而是隱藏狀態(tài)太多。資源包里CNetCore::Startup()的實現(xiàn)很有代表性。bool CNetCore::Startup() { WSADATA wsaData; int rc WSAStartup(MAKEWORD(2, 2), wsaData); if (rc ! 0) { qDebug() WSAStartup failed: rc; return false; } sock_ socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); if (sock_ INVALID_SOCKET) { qDebug() socket create failed: WSAGetLastError(); WSACleanup(); return false; } u_long mode 1; ioctlsocket(sock_, FIONBIO, mode); // 切換非阻塞模式 return true; }注意兩個細(xì)節(jié)。第一WSAStartup必須檢查返回值它失敗時后續(xù)所有socket調(diào)用都會報10107之類的“套接字版本協(xié)商失敗”錯誤很多人第一次跑Windows網(wǎng)絡(luò)程序都會栽在這。第二ioctlsocket把socket切成非阻塞后recv在沒有數(shù)據(jù)到來時會立即返回SOCKET_ERROR錯誤碼是WSAEWOULDBLOCK。這個錯誤不是異常是正?，F(xiàn)象邏輯里必須把它和真正的網(wǎng)絡(luò)錯誤區(qū)分開。3.2 協(xié)議頭設(shè)計長度頭、類型頭與負(fù)載分離消息協(xié)議是這個項目最值得抄作業(yè)的部分。它的格式是“4字節(jié)消息總長度 2字節(jié)消息類型 負(fù)載”負(fù)載是utf8編碼的JSON字符串。這樣設(shè)計的好處是黏包和半包都能處理。QByteArray BuildPacket(quint16 msgType, const QByteArray payload) { QByteArray packet; quint32 len payload.size(); packet.append(char((len 24) 0xFF)); packet.append(char((len 16) 0xFF)); packet.append(char((len 8) 0xFF)); packet.append(char(len 0xFF)); packet.append(char((msgType 8) 0xFF)); packet.append(char(msgType 0xFF)); packet.append(payload); return packet; }大端序存儲有一個實際好處調(diào)試時用十六進(jìn)制查看數(shù)據(jù)包長度字段一眼就能讀出來不用考慮小端序的字節(jié)交換。msgType占2字節(jié)預(yù)留了從0到65535的消息類型空間對課程設(shè)計來說綽綽有余。接收端的解析不是一次性能做完的。TCP是字節(jié)流它不保證每次recv拿到的正好是一個完整的數(shù)據(jù)包。資源包里的做法是維護(hù)一個接收緩沖區(qū)和TryDecode函數(shù)bool CMsgProtocol::TryDecode(QByteArray buffer, CMessage out) { while (buffer.size() HEADER_LEN) { quint32 len (quint8(buffer[0]) 24) | (quint8(buffer[1]) 16) | (quint8(buffer[2]) 8) | (quint8(buffer[3])); if (len MAX_PAYLOAD) { buffer.clear(); return false; // 數(shù)據(jù)異常防止惡意包撐爆內(nèi)存 } if (buffer.size() HEADER_LEN len) { return false; // 半包等更多數(shù)據(jù) } quint16 type (quint8(buffer[4]) 8) | quint8(buffer[5]); out.SetType(type); out.SetPayload(buffer.mid(HEADER_LEN, len)); buffer.remove(0, HEADER_LEN len); return true; // 取出一條完整消息 } return false; }每次recv到新數(shù)據(jù)后把數(shù)據(jù)追加到緩沖區(qū)末尾再調(diào)用TryDecode循環(huán)解析。如果返回值是半包說明數(shù)據(jù)還沒收全等下一輪再試。這個邏輯一旦寫成粘包、拆包問題基本一次解決不會再出現(xiàn)“消息錯位”的詭異問題。3.3 服務(wù)器并發(fā)select復(fù)用與請求處理邊界服務(wù)器端這個項目用的是select模型線程數(shù)固定一個監(jiān)聽socket加若干個客戶端socket。select的好處是單線程處理多路IO比開一堆線程更可控對課程設(shè)計的并發(fā)量完全夠用。fd_set readSet; FD_ZERO(readSet); FD_SET(listenSock, readSet); for (SOCKET s : clients) FD_SET(s, readSet); timeval tv {1, 0}; int ret select(0, readSet, nullptr, nullptr, tv); if (ret 0) { if (FD_ISSET(listenSock, readSet)) { // accept 新連接加入 clients 容器 } for (SOCKET s : clients) { if (FD_ISSET(s, readSet)) { // recv數(shù)據(jù)交給 CMsgProtocol 解析 } } }select的超時時間設(shè)成1秒還有一個隱藏作用即使沒有網(wǎng)絡(luò)事件主循環(huán)每秒都會醒一次趁機(jī)做心跳超時檢測把長時間沒發(fā)心跳的客戶端踢下線。課程設(shè)計如果要演示“客戶端崩潰后服務(wù)器能感知”這個機(jī)制是必要的。服務(wù)器每次recv都盡量把緩沖區(qū)讀完但不要把耗時操作放在網(wǎng)絡(luò)循環(huán)里比如寫數(shù)據(jù)庫可以丟到任務(wù)隊列里否則一個客戶端的大量消息會把整個服務(wù)器的響應(yīng)拖慢。4. 界面邏輯與線程模型UI和網(wǎng)絡(luò)分離消息隊列不卡窗口4.1 跨線程通信把網(wǎng)絡(luò)線程的數(shù)據(jù)安全地送到界面線程很多課程設(shè)計在第一次演示時都會出現(xiàn)一個尷尬場景聊天窗口拖動時卡頓或者干脆“窗口未響應(yīng)”。原因幾乎都是網(wǎng)絡(luò)數(shù)據(jù)處理在UI線程里執(zhí)行了。這個資源包給的做法是網(wǎng)絡(luò)線程負(fù)責(zé)收包解析界面線程只負(fù)責(zé)渲染。// worker.h class NetWorker : public QObject { Q_OBJECT public slots: void OnReadyRead(); // 網(wǎng)絡(luò)線程收到數(shù)據(jù) signals: void MessageReceived(const CMessage msg); void ParseError(const QString desc); };在工作線程里發(fā)信號信號攜帶的是自定義類型CMessage所以必須先調(diào)用qRegisterMetaTypeCMessage()注冊否則連接時會直接報錯。// mainwindow.cpp connect(netWorker_, NetWorker::MessageReceived, this, MainWindow::OnMessageReceived, Qt::QueuedConnection);Qt::QueuedConnection是這里最關(guān)鍵的一個參數(shù)。它保證信號投遞到接收者的事件循環(huán)中而不是立即執(zhí)行。這樣即使網(wǎng)絡(luò)線程短時間內(nèi)收到大量消息界面線程也只是每條都排隊處理窗口不會因為反復(fù)重繪而卡死。如果你用的是非Qt框架對應(yīng)方案是封裝一個線程安全消息隊列UI線程定時取同樣能達(dá)到這個效果。4.2 登錄到主界面的狀態(tài)切換別用if堆邏輯登錄、注冊、主界面之間的跳轉(zhuǎn)這個項目用一個簡單的狀態(tài)機(jī)來管理。登錄成功后把用戶信息和好友列表寫進(jìn)內(nèi)存再切換主窗口登錄失敗留在當(dāng)前窗口并給出提示。void LoginWindow::OnLoginResult(bool ok, const QString reason) { if (ok) { MainWindow* w new MainWindow(user_, friendList_); w-show(); this-close(); } else { QMessageBox::warning(this, 登錄失敗, reason); } }注意這里不是直接new一個窗口就好而是要把登錄結(jié)果里拿到的好友列表指針傳給主窗口。如果不傳主窗口還得再查一遍數(shù)據(jù)庫相當(dāng)于繞了一圈。有些實現(xiàn)會在兩個窗口之間維護(hù)一堆全局變量一旦處理“賬號被踢下線”就會漏狀態(tài)。4.3 好友列表與聊天窗口增量刷新比全量重建可靠主窗口的好友列表這個版本用的是QListWidget但它不是每次都clear()再重新插入。每次只對有狀態(tài)變化的條目做更新這樣有兩個好處一是列表不會閃爍二是不會丟焦點(diǎn)。聊天窗口的消息列表同理新消息到達(dá)時只追加一條QListWidgetItem并且自動滾動到底部。void ChatWindow::AppendMessage(const QString sender, const QString content) { QListWidgetItem* item new QListWidgetItem( QString(%1: %2).arg(sender, content)); listWidget_-addItem(item); listWidget_-scrollToBottom(); }這里我見過最常見的翻車姿勢是直接在聊天窗口構(gòu)造函數(shù)里創(chuàng)建一個新的QListWidgetItem給每條歷史消息然后還手動控制setCurrentRow結(jié)果窗口加載幾十條消息后就開始閃爍。資源包的做法是歷史消息和實時消息走同一個AppendMessage入口統(tǒng)一行為就可預(yù)期。5. 排障與常見問題五個把分?jǐn)?shù)拉低的踩坑記錄5.1 粘包與半包導(dǎo)致消息錯位現(xiàn)象A發(fā)送“你好”和“再見”兩條消息B收到的卻是“你”和“好再見”。原因TCP把兩條消息放進(jìn)同一個TCP段發(fā)出接收端一次recv讀到了兩條完整數(shù)據(jù)但程序只按一條來處理第二條多出來的字節(jié)留在了緩沖區(qū)里下一次再來數(shù)據(jù)時就錯位了。解決緩沖區(qū)加協(xié)議長度頭處理上一章講的TryDecode就是完整的解決方案。從那以后我寫網(wǎng)絡(luò)程序第一時間先定協(xié)議長度頭不是先寫收發(fā)邏輯。5.2 服務(wù)器select返回后立即空轉(zhuǎn)現(xiàn)象服務(wù)器CPU占用接近100%但客戶端沒有發(fā)任何數(shù)據(jù)。原因socket被設(shè)置成非阻塞后accept返回INVALID_SOCKET有些代碼沒有檢查這個值就把無效socket加入fd_setselect每次都因為無效句柄觸發(fā)異常返回業(yè)務(wù)循環(huán)就變成了死循環(huán)。解決accept和recv必須要判定失敗分支。accept返回INVALID_SOCKET且WSAGetLastError為WSAEWOULDBLOCK時直接跳過本輪。順帶檢查clients容器里是否有已關(guān)閉連接發(fā)現(xiàn)有FD_CLOSE事件就移出集合并closesocket。5.3 界面線程被網(wǎng)絡(luò)阻塞假死現(xiàn)象拖動聊天窗口時整個程序沒反應(yīng)Windows提示“未響應(yīng)”。原因recv被設(shè)計成行代碼直接寫在按鈕點(diǎn)擊事件里網(wǎng)絡(luò)沒數(shù)據(jù)時就會一直阻塞在那里UI線程完全被卡住。解決網(wǎng)絡(luò)收發(fā)全部移到獨(dú)立線程界面通過隊列接收消息。只要做到“UI線程不碰socket”這類問題基本不會出現(xiàn)。5.4 中文用戶名亂碼現(xiàn)象用UTF-8編碼的用戶名注冊成功后服務(wù)器端讀出來是一串亂碼。原因Windows默認(rèn)的本地代碼頁是GBK客戶端界面輸入的QString在本地代碼頁模式下被轉(zhuǎn)換成GBK字節(jié)流而服務(wù)器端解析時仍按UTF-8處理字節(jié)解釋不一致就亂碼了。解決統(tǒng)一編碼在協(xié)議層明確是UTF-8。寫入socket前用QString::toUtf8()讀出后QString::fromUtf8()。不要信“Windows控制臺能顯示中文就是對的”socket沒有編碼概念只有字節(jié)流誰定義編碼誰負(fù)責(zé)。5.5 服務(wù)器退出時崩潰現(xiàn)象關(guān)閉服務(wù)器控制臺程序有時直接報錯或者卡住無法退出。原因客戶端連接還掛在clients容器里服務(wù)器直接退出時每個socket都還持有對象引用部分晚到的recv回調(diào)還在工作析構(gòu)順序錯亂導(dǎo)致重復(fù)釋放。解決退出前統(tǒng)一關(guān)閉所有socket先斷開有連接的客戶端再清理監(jiān)聽socket。而且查找所有delete處確保每個網(wǎng)絡(luò)對象只有一個擁有者。最好在服務(wù)器退出流程里加一個標(biāo)志位讓循環(huán)正常跳出而不是強(qiáng)殺線程。6. 把優(yōu)秀成績拉開差距可靠性驗證與可擴(kuò)展接口6.1 用腳本把協(xié)議回歸測試做成自動化課程設(shè)計說出來不算數(shù)要有驗證。我在這個資源包里最欣賞的部分是一組測試腳本起服務(wù)器后腳本啟動兩個客戶端進(jìn)程預(yù)設(shè)好賬號、好友關(guān)系讓A給B連續(xù)發(fā)100條消息然后腳本檢查B收到的消息條數(shù)、順序和內(nèi)容是否一致。這個腳本不是UI自動化而是走socket層面直接打協(xié)議包所以能非常快發(fā)現(xiàn)問題。# stress_test.py import socket import struct import time def build_packet(msg_type, payload): return struct.pack(IH, len(payload), msg_type) payload.encode(utf-8) client socket.socket(socket.AF_INET, socket.SOCK_STREAM) client.connect((127.0.0.1, 9999)) client.send(build_packet(1, {action:login,name:A,pwd:123456})) time.sleep(0.2) for i in range(100): client.send(build_packet(3, {to:B,content:msg-%d} % i)) client.close()這個協(xié)議格式剛好和C端一致IH對應(yīng)大端2字節(jié)類型加4字節(jié)長度。為什么用腳本而不是在C里再寫一個測試客戶端因為腳本改起來快壓測時不用重新編譯而且可以結(jié)合串行、并發(fā)多場景跑。我在之前做模擬項目X時就是靠這套腳本在答辯前抓到一個只在壓力下才出現(xiàn)的隱性半包問題。從那以后我每次做網(wǎng)絡(luò)課程設(shè)計都會先寫一套回歸腳本再開始寫業(yè)務(wù)代碼。6.2 預(yù)留擴(kuò)展點(diǎn)離線消息與文件傳輸如果你想讓成績再上一個臺階可以重點(diǎn)看這個資源包的擴(kuò)展接口設(shè)計。服務(wù)器維護(hù)一個離線消息隊列客戶端登錄成功后服務(wù)器把隊列里的消息逐條推送過來客戶端按會話分組展示。這個邏輯本質(zhì)上是對消息路由層做一個小擴(kuò)展不需要改動網(wǎng)絡(luò)核心。文件傳輸也做了預(yù)留文件分片后復(fù)用同一套協(xié)議格式只是類型字段變成了FILE_CHUNK負(fù)載里放了文件ID、分片序號和二進(jìn)制數(shù)據(jù)。底層收發(fā)不變只是負(fù)載大了些。這也是這個資源包的價值它不是一套只夠演示的基礎(chǔ)代碼而是留好了后續(xù)功能擴(kuò)展的空間。我記得某導(dǎo)師在答辯時說了一句話課程設(shè)計不是看你會不會寫代碼是看你有沒有想過這個系統(tǒng)明天怎么加功能。這話很扎心但確實是驗收時拉開分差的關(guān)鍵點(diǎn)。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取