简介这套基于C与QT开发的P2P共享文件系统源码面向希望学习分布式文件共享与QT客户端开发的中高级开发者完整提供服务器端与客户端两套工程可直接编译运行或作为二次开发基础。资源共27个文件以11个cpp、9个h源码文件为主涵盖tcp_meta、tcp_server、p2p_server、p2p_download等核心模块另有pro工程文件和QT Creator配置辅助文件整体压缩包仅29KB结构紧凑便于对照学习。目前已有223人学习下载。通过这份源码读者可以深入理解P2P节点发现、资源索引与文件传输机制掌握QT信号槽、多线程网络通信、自定义协议封装等关键实现同时参考服务器与客户端的协作方式对构建完整C/S架构应用具有直接的参考价值。1. P2P共享文件系统为什么值得用C和QT写先定服务器端和客户端的边界P2P共享文件系统不是新概念但能在自己的机器上编译、改分块逻辑、看节点上下线的源码样本远没有想象中多。用C和QT写一套核心收益在于C把每个TCP包、每段文件缓冲和线程对象控制在手里QT把窗口、事件循环和跨平台差异收掉一套代码能同时覆盖Windows和Linux测试环境。这套源码里的服务器端和客户端边界用一句话说清服务器端只维护索引不存文件内容客户端负责大文件分块、向服务器端登记元数据、从多个节点拉块并校验。很多半成品实现恰恰死在边界不清——服务器端想转发文件客户端又反复传整个文件最后既不是P2P也不是网盘。这套分工方式适合团队内部共享资料、安装包或代码镜像门槛比自建私有网盘低控制力又比网盘接口强。2. 服务器端设计用QTcpServer登记P2P节点索引拿QTimer清理失联节点2.1 带中心索引的P2P服务器端只登记“哪个块在哪个节点”不存文件内容服务器端在整个P2P共享文件系统里的职责是索引不是代理。节点启动后把它持有的文件名、文件大小、文件哈希、块大小和块哈希表登记到服务器端服务器端把这些信息记在内存哈希表里。另一个客户端想下载时先向服务器端发lookup命令服务器端返回持有目标块的节点列表之后真正传文件内容走的是客户端与客户端之间的socket。这是常见的中心化索引P2P搜索是中心的传输是点对点的。不要一上来就把文件内容往服务器端写写多了就成了中央转发服务器。P2P共享文件系统源码里服务器端要做的事只有三件register、lookup、heartbeat。实现这一层时不建议开QMainWindow让服务器端作为控制台程序运行继承QCoreApplication就够了。没有界面不等于没有事件循环QTcpServer的回调、QTimer的清理动作仍然由这套事件循环驱动。节点身份用节点ID而不是socket指针做索引表主键。客户端断线重连会换socket但节点ID不变这样它持有的块记录不会因为一次断网就全部失效。节点ID建议用随机生成的十六进制串避免以IP加端口当ID带来的NAT和端口复用问题。2.2 客户端注册与查找协议QTcpServer按4字节长度前缀拆JSON包客户端和服务器端之间的协议决定源码后期好不好维护。常见做法是把传输格式定为“4字节大端帧长度加JSON体”帧体里带cmd字段。TCP是字节流readAll到的内容可能只是半个请求也可能一次包含两三个请求必须自己维护帧边界。class IndexServer : public QObject { Q_OBJECT public: explicit IndexServer(quint16 port, QObject* parent nullptr) : QObject(parent) { m_server new QTcpServer(this); // listen 失败多半是端口被占用不要忽略这个返回值 if (!m_server-listen(QHostAddress::AnyIPv4, port)) { qCritical() listen failed: m_server-errorString(); } connect(m_server, QTcpServer::newConnection, this, IndexServer::onNewConnection); } private slots: void onNewConnection() { QTcpSocket* socket m_server-nextPendingConnection(); connect(socket, QTcpSocket::readyRead, this, [this, socket]() { handleRead(socket); }); connect(socket, QTcpSocket::disconnected, this, [this, socket]() { m_buffers.remove(socket); // 连接关闭时清掉半包缓冲 nodeList.remove(socket); // 同时移出节点表 socket-deleteLater(); // 等事件循环回到主循环再释放 }); } private: void handleRead(QTcpSocket* socket) { m_buffers[socket].append(socket-readAll()); // 先积累不急着解析 while (m_buffers[socket].size() 4) { const char* head m_buffers[socket].constData(); quint32 len qFromBigEndianquint32(head); if (len MAX_FRAME_SIZE) { // 限制单帧大小防内存被打满 socket-abort(); return; } if (m_buffers[socket].size() 4 len) return; // 帧还没到齐 QByteArray body m_buffers[socket].mid(4, len); m_buffers[socket].remove(0, 4 len); handleCommand(socket, QJsonDocument::fromJson(body).object()); } } void handleCommand(QTcpSocket* socket, const QJsonObject req) { const QString cmd req.value(cmd).toString(); if (cmd register) { // 记录该节点持有哪些块哈希后续 lookup 才能把块位置查出来 } else if (cmd lookup) { // 按 file_hash block_index 返回持有节点的 ip:port 列表 } else if (cmd heartbeat) { // 更新该节点最后存活时间超时清理用 } } QTcpServer* m_server; QHashQTcpSocket*, QByteArray m_buffers; QHashQTcpSocket*, QString nodeList; // socket 与节点ID 的映射 };这段代码里的长度前缀是关键它避免了两种常见错误把半包当完整请求处理或者在一个数据包到来时漏掉下一个请求。MAX_FRAME_SIZE建议设为8MBJSON元数据很少超过这个值超过就abort掉防止异常节点用虚大的长度字段拖垮服务器端内存。m_buffers和nodeList都以socket为键disconnected信号里必须清掉对应项否则长时间运行的服务器端内存只涨不降。命令字段可以按下面的表约定后面客户端和服务器端共用这套字段名命令方向关键字段register节点 → 服务器端node_id, file_hash, block_hashes, listen_portlookup客户端 → 服务器端file_hash, block_indexheartbeat节点 → 服务器端node_id这里的listen_port指该节点对外提供文件块服务的端口与它连接服务器端所用的端口可以不同。尤其在多网卡机器上回包里的本机地址常常不是对方能访问的地址注册时主动上报listen_port更可靠。2.3 心跳超时与失联清理QTimer驱动last_seen扫描P2P节点随时可能断电退出索引必须让失效记录自动过期。常见做法是在节点表里维护last_seen时间戳节点每次心跳就更新它服务器端另起一个QTimer周期扫描并移除超时的节点。// 收到 heartbeat 时更新时间戳 m_lastSeen[nodeId] QDateTime::currentMSecsSinceEpoch(); // 服务器端定时清理失联节点 connect(m_cleanTimer, QTimer::timeout, this, [this]() { const qint64 staleMs 90 * 1000; // 90 秒没有心跳就算失联 const qint64 now QDateTime::currentMSecsSinceEpoch(); QMutableHashIteratorQString, qint64 it(m_lastSeen); while (it.hasNext()) { it.next(); if (now - it.value() staleMs) { removeNodeBlocks(it.key()); // 把它持有的所有块索引一起删掉 it.remove(); } } }); m_cleanTimer.start(30 * 1000); // 每 30 秒扫一遍三个时间参数要分开设置客户端心跳间隔、服务器端超时阈值、清理扫描周期。建议超时阈值至少是心跳间隔的3倍否则一次网络抖动就把在线节点误判成失联。下面的参数是局域网环境常用的起点值参数建议值位置心跳间隔15秒客户端QTimer失联阈值90秒服务器端清理逻辑清理周期30秒服务器端QTimer清理失联节点时不止要删last_seen条目还必须把该节点对应的块索引全部清掉。只删节点不删块索引lookup会返回一批已经下线的节点客户端逐个去连接白白消耗超时时间。3. 客户端实现主线文件分块、SHA-256校验与断点续传3.1 固定分块大小选1MB还是256KB先算索引膨胀和请求次数客户端共享一个文件前先按固定大小切块。块大小是整个P2P共享文件系统源码里最影响体验的参数块越大分块数量越少索引越小但某一块传输失败后重试的代价也越大块越小断点续传的粒度越细但请求次数和哈希计算次数成倍上升。拿1GB文件做估算1MB分块得到1024个块每块64字节哈希元数据才64KB改成256KB后变成4096个块元数据变成256KB连接请求次数翻到四倍。局域网内一般用1MB外网和移动网络环境降到256KB更大的镜像文件可以选择2MB。分块信息要写进文件元数据。文件哈希不能只基于文件名应该对块哈希列表整体再算一次SHA-256这样修改文件任意一块根哈希都会变化重名文件也能区分。元数据里的必要字段有file_size、block_size、block_count、block_hashes和root_hash服务器端注册时提交这份JSON下载端拿root_hash做查找键。3.2 用QCryptographicHash按块算SHA-256最后一个块未必足长分块计算的实现要一次性只读一块不能把整个文件读进内存再切。下面是一个直接可用的函数static const qint64 BLOCK_SIZE 1024 * 1024; // 1MB所有节点保持一致 QByteArray hashBlock(const QString path, qint64 offset) { QFile file(path); if (!file.open(QIODevice::ReadOnly)) { qWarning() cannot open file path; return {}; } if (!file.seek(offset)) return {}; QByteArray data file.read(BLOCK_SIZE); // 最后一块可能不足 1MBread 返回短数据 QCryptographicHash h(QCryptographicHash::Sha256); h.addData(data); // 可以用 addData 分多次喂避免一次复制大块内存 return h.result().toHex(); // 返回 64 字节小写十六进制字符串 }计算时以offset为文件内偏移offset必须是目标节点承认的偏移也就是块索引乘块大小。所有节点必须使用同一个BLOCK_SIZE否则同一个块在不同节点算出的哈希不一致下载合并时就会错位。这个常量不能只放在客户端代码里写元数据时也要一起登记下载端拿到元数据后先检查本地的BLOCK_SIZE是否一致。关于哈希计算放哪个线程后面第4章会统一讲。这里要强调的是比较哈希时不要拿文件名当依据文件内容变化后文件名没变只有block_hashes和root_hash能反映真实内容。3.3 断点续传和块位图part文件落盘、哈希比对、重试退避断点续传的实现不是记住“整个文件下了40%”而是记住“哪些块完整落盘”。客户端在cache目录下建一个以root_hash命名的目录每个成功校验的块单独写成一个固定编号的part文件同时维护QBitArray作为完成的位图。程序重启后扫描part目录大小等于BLOCK_SIZE的块直接标记完成最后一块用元数据里的精确长度判断。这个方案的好处是崩溃后最多重传一个损坏块不用从头开始。struct BlockInfo { qint64 offset; // 源文件中的偏移量 index * BLOCK_SIZE qint32 size; // 实际字节数最后一块可能不足 BLOCK_SIZE QByteArray sha256; // 该块的 SHA-256 十六进制串 }; bool saveVerifiedBlock(const QString cacheDir, int index, const BlockInfo info, const QByteArray data) { QByteArray actual QCryptographicHash::hash(data, QCryptographicHash::Sha256); if (actual ! info.sha256) { qWarning() block index hash mismatch; return false; // 不落盘调用方换节点或重试 } const QString partName cacheDir QStringLiteral(/%1.part).arg(index, 5, 10, QLatin1Char(0)); QFile part(partName); if (!part.open(QIODevice::WriteOnly | QIODevice::Truncate)) return false; part.write(data); return part.flush(); // 每一块强制落盘进程崩溃后已完成的块仍然可用 }这里的重试策略可以定成3次同一块失败后换一个节点再拉连续失败3次就把该块标记为暂不可用等新一轮调度。退避时间从2秒起步每次翻倍。用QBitArray比用QFileInfo列表判断完成状态快得多1GB文件分1024块位图只有128字节检查一次几乎零成本。进度显示这块如果直接用QProgressBar每收到一个块更新一次就行想要更细的显示效果可以自绘一个进度条paintEvent里按块位图画填充矩形块完成时调用update()。自绘能避免QProgressBar在频繁setValue时反复触发样式重算块数量大时这个差别很明显。4. 线程模型与网络缓冲区QT写P2P共享文件系统最容易错的地方4.1 哈希计算交给QtConcurrent线程池QTcpSocket仍留在原线程内看过muduo源码的读者会熟悉“单线程事件循环加非阻塞IO”的写法QT其实也遵循同一套约束IO回调在事件循环线程执行回调里绝不能做耗时操作。分块哈希、文件合并这类占用几十毫秒到几百毫秒的操作放进工作线程QTcpSocket本身不跨线程移动它的发送和接收仍由主线程事件循环处理。比较省事的写法是用QtConcurrent::run把哈希计算甩给全局线程池再用QFutureWatcher把结果带回主线程// 在 hashBlock 自由函数存在的前提下启动异步哈希 QFutureQByteArray future QtConcurrent::run(hashBlock, path, offset); QFutureWatcherQByteArray* watcher new QFutureWatcherQByteArray(this); connect(watcher, QFutureWatcherQByteArray::finished, this, [this, watcher]() { QByteArray digest watcher-result(); // 拿到工作线程计算的哈希 emit blockHashReady(index, digest); // 回到主线程后再更新UI或发网络请求 watcher-deleteLater(); }); watcher-setFuture(future);如果工程用qmake记得在pro文件里加QT network concurrent改用CMake时则要显式链接Qt6::Network和Qt6::Concurrent这两个组件。这里把deleteLater放在读取result之后因为lambda里仍需要访问watcher的结果。不要随手把QTcpSocket构造在工作线程里又拿回主线程发信号QTcpSocket要求在创建它的线程里调用read和write真需要在工作线程跑独立连接就整个对象用moveToThread迁移别把同一个socket拆给两个线程用。4.2 readyRead异步拼帧而不是waitForReadyRead阻塞等待新写QT网络代码的人容易图省事去用waitForReadyRead和waitForBytesWritten这两个同步等待方法在控制台小程序里能用放在带界面的客户端里就出问题它们在指定毫秒数内阻塞调用线程如果主线程因此卡死界面、定时器、其他socket的回调全部停摆。P2P共享文件系统的客户端往往同时从好几个节点拉块一个socket阻塞等待其他节点的数据全被压住。正确姿势是把收到数据当成事件在readyRead里拼帧void PeerSocket::onReadyRead() { m_inBuffer.append(socket-readAll()); // 先积累保证收到完整帧再处理 while (m_inBuffer.size() 4) { quint32 frameLen qFromBigEndianquint32(m_inBuffer.constData()); if (frameLen MAX_FRAME_SIZE) { // 帧长异常断开这个对端 abort(); return; } if (m_inBuffer.size() 4 frameLen) return; // 帧还没到齐继续等 QByteArray frame m_inBuffer.mid(4, frameLen); m_inBuffer.remove(0, 4 frameLen); parseFrame(frame); // 解析完立即返回不在回调里做重型IO } }和一个节点建立连接后socket对象需要保留收包缓冲m_inBuffer的状态直到disconnected。这样代码虽然比readAll一把梭长但多节点并发时不会因为某个节点发送速度慢而影响其他节点的解析。4.3 传输相关的7个参数从socket缓冲到重试退避下面7个参数可以集中放在一个配置头文件或QSettings里改动时不用翻散落在各处的魔法数字参数推荐初值作用位置与调整思路BLOCK_SIZE10485761MB客户端切块与下载端请求范围局域网可加大单节点并发连接4一个节点同时发起的下载任务数太高容易把对端打满连接超时5000msQTcpSocket::connectToHost 后的超时判断读超时10000ms两个相邻数据帧间隔超过该值判该节点失速socket读缓冲6553664KBsetReadBufferSize 控制内部分组缓冲重试次数3次同一块同节点失败计数的上限重试退避2s、4s、8s连续失败后指数退避避免块风暴socket缓冲大小可以直接设置但要注意系统上限socket-setReadBufferSize(64 * 1024); socket-setSocketOption(QAbstractSocket::SendBufferSizeSocketOption, 128 * 1024); socket-setSocketOption(QAbstractSocket::LowDelayOption, 1); // 小文件多时关闭Nagle聚合高频小文件传输时把LowDelayOption打开能让首包更快出去传大块时则保持默认让协议栈聚合大包减少系统调用。读缓冲设64KB是折中值设太大会让每个连接都预占较多内存服务器端几千连接的场景容易被拖垮。5. 同一局域网跑通服务器端和客户端再谈慢速网络下怎么查瓶颈5.1 最小验证路径起索引、登记文件、拉取、比对哈希编译得到p2p-server和p2p-client后先在命令行验证最基本的四个环节索引服务能监听端口、客户端能注册、另一个客户端能查到块、下载后哈希一致。下面这条路径假设server和client支持命令行参数没有界面时的验证就用它。# 启动服务器端监听 6699 端口 ./p2p-server --port 6699 # 检查端口监听是否生效 ss -lnt | grep 6699 # 客户端A把 sample.bin 的块信息登记进索引 ./p2p-client --server 127.0.0.1:6699 --register /tmp/share/sample.bin # 客户端B按 root_hash 拉取文件下载到的块写进 /tmp/out/ ./p2p-client --server 127.0.0.1:6699 --fetch root_hash --out /tmp/out/ # 比较原始文件和合并后的文件输出两个一样的 SHA-256 才算通过 sha256sum /tmp/share/sample.bin /tmp/out/sample.bin这一连串命令里没有GUI正好能确认网络和分块逻辑没被界面包住。如果第二个sha256sum对不上先看客户端B的调试输出里是否有block 12 hash mismatch有就是块数据被中间截断或节点返回了错误块没有就检查文件合并时的seek偏移对不对。5.2 传输慢先看块完成日志再用QElapsedTimer分开计时磁盘与网络传输慢时不着急改BLOCK_SIZE先把慢这个现象精确定位到网络、磁盘还是哈希计算。给每个块的saveVerifiedBlock调用加上计时QElapsedTimer diskTimer; diskTimer.start(); bool ok saveVerifiedBlock(cacheDir, index, info, data); qDebug() block index disk-ms diskTimer.elapsed();数据到达后再写这段日志记录的是哈希校验加落盘的总耗时。如果disk-ms只有零点几毫秒说明磁盘不是瓶颈往后去查socket收发如果disk-ms随索引增大而明显变大多半是并发块写得太分散导致随机写把并发写入的块数降到1到2条再测。如果每个块都要等2秒以上才进入重试先把失败节点列表打出来确认是不是lookup返回的节点已经失联心跳超时阈值从这里调。动手前先给每个块的传输状态单独打一行日志格式固定为blockIndex/total elapsedMs retryCount用awk就能统计平均块耗时和长尾分布。P2P共享文件系统做分布式调优时这一行日志比界面上的总进度百分比更有用。本文还有配套的精品资源点击获取
基于C++与Qt的P2P文件共享系统：服务器端索引与客户端分块实战
简介这套基于C与QT开发的P2P共享文件系统源码面向希望学习分布式文件共享与QT客户端开发的中高级开发者完整提供服务器端与客户端两套工程可直接编译运行或作为二次开发基础。资源共27个文件以11个cpp、9个h源码文件为主涵盖tcp_meta、tcp_server、p2p_server、p2p_download等核心模块另有pro工程文件和QT Creator配置辅助文件整体压缩包仅29KB结构紧凑便于对照学习。目前已有223人学习下载。通过这份源码读者可以深入理解P2P节点发现、资源索引与文件传输机制掌握QT信号槽、多线程网络通信、自定义协议封装等关键实现同时参考服务器与客户端的协作方式对构建完整C/S架构应用具有直接的参考价值。1. P2P共享文件系统为什么值得用C和QT写先定服务器端和客户端的边界P2P共享文件系统不是新概念但能在自己的机器上编译、改分块逻辑、看节点上下线的源码样本远没有想象中多。用C和QT写一套核心收益在于C把每个TCP包、每段文件缓冲和线程对象控制在手里QT把窗口、事件循环和跨平台差异收掉一套代码能同时覆盖Windows和Linux测试环境。这套源码里的服务器端和客户端边界用一句话说清服务器端只维护索引不存文件内容客户端负责大文件分块、向服务器端登记元数据、从多个节点拉块并校验。很多半成品实现恰恰死在边界不清——服务器端想转发文件客户端又反复传整个文件最后既不是P2P也不是网盘。这套分工方式适合团队内部共享资料、安装包或代码镜像门槛比自建私有网盘低控制力又比网盘接口强。2. 服务器端设计用QTcpServer登记P2P节点索引拿QTimer清理失联节点2.1 带中心索引的P2P服务器端只登记“哪个块在哪个节点”不存文件内容服务器端在整个P2P共享文件系统里的职责是索引不是代理。节点启动后把它持有的文件名、文件大小、文件哈希、块大小和块哈希表登记到服务器端服务器端把这些信息记在内存哈希表里。另一个客户端想下载时先向服务器端发lookup命令服务器端返回持有目标块的节点列表之后真正传文件内容走的是客户端与客户端之间的socket。这是常见的中心化索引P2P搜索是中心的传输是点对点的。不要一上来就把文件内容往服务器端写写多了就成了中央转发服务器。P2P共享文件系统源码里服务器端要做的事只有三件register、lookup、heartbeat。实现这一层时不建议开QMainWindow让服务器端作为控制台程序运行继承QCoreApplication就够了。没有界面不等于没有事件循环QTcpServer的回调、QTimer的清理动作仍然由这套事件循环驱动。节点身份用节点ID而不是socket指针做索引表主键。客户端断线重连会换socket但节点ID不变这样它持有的块记录不会因为一次断网就全部失效。节点ID建议用随机生成的十六进制串避免以IP加端口当ID带来的NAT和端口复用问题。2.2 客户端注册与查找协议QTcpServer按4字节长度前缀拆JSON包客户端和服务器端之间的协议决定源码后期好不好维护。常见做法是把传输格式定为“4字节大端帧长度加JSON体”帧体里带cmd字段。TCP是字节流readAll到的内容可能只是半个请求也可能一次包含两三个请求必须自己维护帧边界。class IndexServer : public QObject { Q_OBJECT public: explicit IndexServer(quint16 port, QObject* parent nullptr) : QObject(parent) { m_server new QTcpServer(this); // listen 失败多半是端口被占用不要忽略这个返回值 if (!m_server-listen(QHostAddress::AnyIPv4, port)) { qCritical() listen failed: m_server-errorString(); } connect(m_server, QTcpServer::newConnection, this, IndexServer::onNewConnection); } private slots: void onNewConnection() { QTcpSocket* socket m_server-nextPendingConnection(); connect(socket, QTcpSocket::readyRead, this, [this, socket]() { handleRead(socket); }); connect(socket, QTcpSocket::disconnected, this, [this, socket]() { m_buffers.remove(socket); // 连接关闭时清掉半包缓冲 nodeList.remove(socket); // 同时移出节点表 socket-deleteLater(); // 等事件循环回到主循环再释放 }); } private: void handleRead(QTcpSocket* socket) { m_buffers[socket].append(socket-readAll()); // 先积累不急着解析 while (m_buffers[socket].size() 4) { const char* head m_buffers[socket].constData(); quint32 len qFromBigEndianquint32(head); if (len MAX_FRAME_SIZE) { // 限制单帧大小防内存被打满 socket-abort(); return; } if (m_buffers[socket].size() 4 len) return; // 帧还没到齐 QByteArray body m_buffers[socket].mid(4, len); m_buffers[socket].remove(0, 4 len); handleCommand(socket, QJsonDocument::fromJson(body).object()); } } void handleCommand(QTcpSocket* socket, const QJsonObject req) { const QString cmd req.value(cmd).toString(); if (cmd register) { // 记录该节点持有哪些块哈希后续 lookup 才能把块位置查出来 } else if (cmd lookup) { // 按 file_hash block_index 返回持有节点的 ip:port 列表 } else if (cmd heartbeat) { // 更新该节点最后存活时间超时清理用 } } QTcpServer* m_server; QHashQTcpSocket*, QByteArray m_buffers; QHashQTcpSocket*, QString nodeList; // socket 与节点ID 的映射 };这段代码里的长度前缀是关键它避免了两种常见错误把半包当完整请求处理或者在一个数据包到来时漏掉下一个请求。MAX_FRAME_SIZE建议设为8MBJSON元数据很少超过这个值超过就abort掉防止异常节点用虚大的长度字段拖垮服务器端内存。m_buffers和nodeList都以socket为键disconnected信号里必须清掉对应项否则长时间运行的服务器端内存只涨不降。命令字段可以按下面的表约定后面客户端和服务器端共用这套字段名命令方向关键字段register节点 → 服务器端node_id, file_hash, block_hashes, listen_portlookup客户端 → 服务器端file_hash, block_indexheartbeat节点 → 服务器端node_id这里的listen_port指该节点对外提供文件块服务的端口与它连接服务器端所用的端口可以不同。尤其在多网卡机器上回包里的本机地址常常不是对方能访问的地址注册时主动上报listen_port更可靠。2.3 心跳超时与失联清理QTimer驱动last_seen扫描P2P节点随时可能断电退出索引必须让失效记录自动过期。常见做法是在节点表里维护last_seen时间戳节点每次心跳就更新它服务器端另起一个QTimer周期扫描并移除超时的节点。// 收到 heartbeat 时更新时间戳 m_lastSeen[nodeId] QDateTime::currentMSecsSinceEpoch(); // 服务器端定时清理失联节点 connect(m_cleanTimer, QTimer::timeout, this, [this]() { const qint64 staleMs 90 * 1000; // 90 秒没有心跳就算失联 const qint64 now QDateTime::currentMSecsSinceEpoch(); QMutableHashIteratorQString, qint64 it(m_lastSeen); while (it.hasNext()) { it.next(); if (now - it.value() staleMs) { removeNodeBlocks(it.key()); // 把它持有的所有块索引一起删掉 it.remove(); } } }); m_cleanTimer.start(30 * 1000); // 每 30 秒扫一遍三个时间参数要分开设置客户端心跳间隔、服务器端超时阈值、清理扫描周期。建议超时阈值至少是心跳间隔的3倍否则一次网络抖动就把在线节点误判成失联。下面的参数是局域网环境常用的起点值参数建议值位置心跳间隔15秒客户端QTimer失联阈值90秒服务器端清理逻辑清理周期30秒服务器端QTimer清理失联节点时不止要删last_seen条目还必须把该节点对应的块索引全部清掉。只删节点不删块索引lookup会返回一批已经下线的节点客户端逐个去连接白白消耗超时时间。3. 客户端实现主线文件分块、SHA-256校验与断点续传3.1 固定分块大小选1MB还是256KB先算索引膨胀和请求次数客户端共享一个文件前先按固定大小切块。块大小是整个P2P共享文件系统源码里最影响体验的参数块越大分块数量越少索引越小但某一块传输失败后重试的代价也越大块越小断点续传的粒度越细但请求次数和哈希计算次数成倍上升。拿1GB文件做估算1MB分块得到1024个块每块64字节哈希元数据才64KB改成256KB后变成4096个块元数据变成256KB连接请求次数翻到四倍。局域网内一般用1MB外网和移动网络环境降到256KB更大的镜像文件可以选择2MB。分块信息要写进文件元数据。文件哈希不能只基于文件名应该对块哈希列表整体再算一次SHA-256这样修改文件任意一块根哈希都会变化重名文件也能区分。元数据里的必要字段有file_size、block_size、block_count、block_hashes和root_hash服务器端注册时提交这份JSON下载端拿root_hash做查找键。3.2 用QCryptographicHash按块算SHA-256最后一个块未必足长分块计算的实现要一次性只读一块不能把整个文件读进内存再切。下面是一个直接可用的函数static const qint64 BLOCK_SIZE 1024 * 1024; // 1MB所有节点保持一致 QByteArray hashBlock(const QString path, qint64 offset) { QFile file(path); if (!file.open(QIODevice::ReadOnly)) { qWarning() cannot open file path; return {}; } if (!file.seek(offset)) return {}; QByteArray data file.read(BLOCK_SIZE); // 最后一块可能不足 1MBread 返回短数据 QCryptographicHash h(QCryptographicHash::Sha256); h.addData(data); // 可以用 addData 分多次喂避免一次复制大块内存 return h.result().toHex(); // 返回 64 字节小写十六进制字符串 }计算时以offset为文件内偏移offset必须是目标节点承认的偏移也就是块索引乘块大小。所有节点必须使用同一个BLOCK_SIZE否则同一个块在不同节点算出的哈希不一致下载合并时就会错位。这个常量不能只放在客户端代码里写元数据时也要一起登记下载端拿到元数据后先检查本地的BLOCK_SIZE是否一致。关于哈希计算放哪个线程后面第4章会统一讲。这里要强调的是比较哈希时不要拿文件名当依据文件内容变化后文件名没变只有block_hashes和root_hash能反映真实内容。3.3 断点续传和块位图part文件落盘、哈希比对、重试退避断点续传的实现不是记住“整个文件下了40%”而是记住“哪些块完整落盘”。客户端在cache目录下建一个以root_hash命名的目录每个成功校验的块单独写成一个固定编号的part文件同时维护QBitArray作为完成的位图。程序重启后扫描part目录大小等于BLOCK_SIZE的块直接标记完成最后一块用元数据里的精确长度判断。这个方案的好处是崩溃后最多重传一个损坏块不用从头开始。struct BlockInfo { qint64 offset; // 源文件中的偏移量 index * BLOCK_SIZE qint32 size; // 实际字节数最后一块可能不足 BLOCK_SIZE QByteArray sha256; // 该块的 SHA-256 十六进制串 }; bool saveVerifiedBlock(const QString cacheDir, int index, const BlockInfo info, const QByteArray data) { QByteArray actual QCryptographicHash::hash(data, QCryptographicHash::Sha256); if (actual ! info.sha256) { qWarning() block index hash mismatch; return false; // 不落盘调用方换节点或重试 } const QString partName cacheDir QStringLiteral(/%1.part).arg(index, 5, 10, QLatin1Char(0)); QFile part(partName); if (!part.open(QIODevice::WriteOnly | QIODevice::Truncate)) return false; part.write(data); return part.flush(); // 每一块强制落盘进程崩溃后已完成的块仍然可用 }这里的重试策略可以定成3次同一块失败后换一个节点再拉连续失败3次就把该块标记为暂不可用等新一轮调度。退避时间从2秒起步每次翻倍。用QBitArray比用QFileInfo列表判断完成状态快得多1GB文件分1024块位图只有128字节检查一次几乎零成本。进度显示这块如果直接用QProgressBar每收到一个块更新一次就行想要更细的显示效果可以自绘一个进度条paintEvent里按块位图画填充矩形块完成时调用update()。自绘能避免QProgressBar在频繁setValue时反复触发样式重算块数量大时这个差别很明显。4. 线程模型与网络缓冲区QT写P2P共享文件系统最容易错的地方4.1 哈希计算交给QtConcurrent线程池QTcpSocket仍留在原线程内看过muduo源码的读者会熟悉“单线程事件循环加非阻塞IO”的写法QT其实也遵循同一套约束IO回调在事件循环线程执行回调里绝不能做耗时操作。分块哈希、文件合并这类占用几十毫秒到几百毫秒的操作放进工作线程QTcpSocket本身不跨线程移动它的发送和接收仍由主线程事件循环处理。比较省事的写法是用QtConcurrent::run把哈希计算甩给全局线程池再用QFutureWatcher把结果带回主线程// 在 hashBlock 自由函数存在的前提下启动异步哈希 QFutureQByteArray future QtConcurrent::run(hashBlock, path, offset); QFutureWatcherQByteArray* watcher new QFutureWatcherQByteArray(this); connect(watcher, QFutureWatcherQByteArray::finished, this, [this, watcher]() { QByteArray digest watcher-result(); // 拿到工作线程计算的哈希 emit blockHashReady(index, digest); // 回到主线程后再更新UI或发网络请求 watcher-deleteLater(); }); watcher-setFuture(future);如果工程用qmake记得在pro文件里加QT network concurrent改用CMake时则要显式链接Qt6::Network和Qt6::Concurrent这两个组件。这里把deleteLater放在读取result之后因为lambda里仍需要访问watcher的结果。不要随手把QTcpSocket构造在工作线程里又拿回主线程发信号QTcpSocket要求在创建它的线程里调用read和write真需要在工作线程跑独立连接就整个对象用moveToThread迁移别把同一个socket拆给两个线程用。4.2 readyRead异步拼帧而不是waitForReadyRead阻塞等待新写QT网络代码的人容易图省事去用waitForReadyRead和waitForBytesWritten这两个同步等待方法在控制台小程序里能用放在带界面的客户端里就出问题它们在指定毫秒数内阻塞调用线程如果主线程因此卡死界面、定时器、其他socket的回调全部停摆。P2P共享文件系统的客户端往往同时从好几个节点拉块一个socket阻塞等待其他节点的数据全被压住。正确姿势是把收到数据当成事件在readyRead里拼帧void PeerSocket::onReadyRead() { m_inBuffer.append(socket-readAll()); // 先积累保证收到完整帧再处理 while (m_inBuffer.size() 4) { quint32 frameLen qFromBigEndianquint32(m_inBuffer.constData()); if (frameLen MAX_FRAME_SIZE) { // 帧长异常断开这个对端 abort(); return; } if (m_inBuffer.size() 4 frameLen) return; // 帧还没到齐继续等 QByteArray frame m_inBuffer.mid(4, frameLen); m_inBuffer.remove(0, 4 frameLen); parseFrame(frame); // 解析完立即返回不在回调里做重型IO } }和一个节点建立连接后socket对象需要保留收包缓冲m_inBuffer的状态直到disconnected。这样代码虽然比readAll一把梭长但多节点并发时不会因为某个节点发送速度慢而影响其他节点的解析。4.3 传输相关的7个参数从socket缓冲到重试退避下面7个参数可以集中放在一个配置头文件或QSettings里改动时不用翻散落在各处的魔法数字参数推荐初值作用位置与调整思路BLOCK_SIZE10485761MB客户端切块与下载端请求范围局域网可加大单节点并发连接4一个节点同时发起的下载任务数太高容易把对端打满连接超时5000msQTcpSocket::connectToHost 后的超时判断读超时10000ms两个相邻数据帧间隔超过该值判该节点失速socket读缓冲6553664KBsetReadBufferSize 控制内部分组缓冲重试次数3次同一块同节点失败计数的上限重试退避2s、4s、8s连续失败后指数退避避免块风暴socket缓冲大小可以直接设置但要注意系统上限socket-setReadBufferSize(64 * 1024); socket-setSocketOption(QAbstractSocket::SendBufferSizeSocketOption, 128 * 1024); socket-setSocketOption(QAbstractSocket::LowDelayOption, 1); // 小文件多时关闭Nagle聚合高频小文件传输时把LowDelayOption打开能让首包更快出去传大块时则保持默认让协议栈聚合大包减少系统调用。读缓冲设64KB是折中值设太大会让每个连接都预占较多内存服务器端几千连接的场景容易被拖垮。5. 同一局域网跑通服务器端和客户端再谈慢速网络下怎么查瓶颈5.1 最小验证路径起索引、登记文件、拉取、比对哈希编译得到p2p-server和p2p-client后先在命令行验证最基本的四个环节索引服务能监听端口、客户端能注册、另一个客户端能查到块、下载后哈希一致。下面这条路径假设server和client支持命令行参数没有界面时的验证就用它。# 启动服务器端监听 6699 端口 ./p2p-server --port 6699 # 检查端口监听是否生效 ss -lnt | grep 6699 # 客户端A把 sample.bin 的块信息登记进索引 ./p2p-client --server 127.0.0.1:6699 --register /tmp/share/sample.bin # 客户端B按 root_hash 拉取文件下载到的块写进 /tmp/out/ ./p2p-client --server 127.0.0.1:6699 --fetch root_hash --out /tmp/out/ # 比较原始文件和合并后的文件输出两个一样的 SHA-256 才算通过 sha256sum /tmp/share/sample.bin /tmp/out/sample.bin这一连串命令里没有GUI正好能确认网络和分块逻辑没被界面包住。如果第二个sha256sum对不上先看客户端B的调试输出里是否有block 12 hash mismatch有就是块数据被中间截断或节点返回了错误块没有就检查文件合并时的seek偏移对不对。5.2 传输慢先看块完成日志再用QElapsedTimer分开计时磁盘与网络传输慢时不着急改BLOCK_SIZE先把慢这个现象精确定位到网络、磁盘还是哈希计算。给每个块的saveVerifiedBlock调用加上计时QElapsedTimer diskTimer; diskTimer.start(); bool ok saveVerifiedBlock(cacheDir, index, info, data); qDebug() block index disk-ms diskTimer.elapsed();数据到达后再写这段日志记录的是哈希校验加落盘的总耗时。如果disk-ms只有零点几毫秒说明磁盘不是瓶颈往后去查socket收发如果disk-ms随索引增大而明显变大多半是并发块写得太分散导致随机写把并发写入的块数降到1到2条再测。如果每个块都要等2秒以上才进入重试先把失败节点列表打出来确认是不是lookup返回的节点已经失联心跳超时阈值从这里调。动手前先给每个块的传输状态单独打一行日志格式固定为blockIndex/total elapsedMs retryCount用awk就能统计平均块耗时和长尾分布。P2P共享文件系统做分布式调优时这一行日志比界面上的总进度百分比更有用。本文还有配套的精品资源点击获取
