企业官网建设流程全解析

简介：这份 IPMSG 源码资料面向希望深入理解局域网即时通讯协议与网络编程的开发者，围绕基于 UDP 的 IPMSG 协议，提供客户端、服务端及配套协议文档，适合用来拆解消息结构、认证流程、数据封装与解封装等关键环节。压缩包共 358 个文件、约 22.8MB，主要包含 36 个 h 头文件、31 个 cpp 与 29 个 c 源文件，以及 exe、lib、pdb 等编译产物和若干 txt、pdf、chm 说明文档，便于对照协议资料阅读实现代码。已有 496 人学习下载。读者可从中梳理 UDP 通信、广播与多播、I/O 复用、错误处理与跨平台兼容等实现思路，并借助源码中的模块划分和工程文件理解一个轻量即时通讯系统的组织方式，积累网络编程与协议解析经验。

1. IpMsg 源码能给你什么：一套跑在 2425 端口上的局域网协议

两台机器接在同一个交换机上，没有外网，也不想装服务端，打开一个小程序就能互相看见对方、把文件拖过去——很多人第一次接触局域网即时通讯工具，就是这个体验。IpMsg 源码这份资源的价值不在界面，而在于它把一整套跑在 UDP 2425 端口上的轻量协议原样摆了出来：32 位命令字怎么按位拆开、报文怎么用冒号拼接、文件传输为什么在信令之后另开一条 TCP 连接，都能在源码和随包的协议资料里一一对上号。

它适合三类人：想搞懂局域网发现与信令机制的初学者，手里有内网工具、需要加一段文件互传能力的开发者，以及接手了老项目、必须先把一套私有协议读懂再动刀的人。后面按协议、目录、核心模块、联调、避坑、二次开发一路拆下去，能照着跑通，也能照着改。

2. 协议拆解：32 位命令字、冒号分隔报文与 UDP/TCP 双通道

读这套源码，最省时间的路径是先读协议再读代码。代码里的分支判断看起来又多又碎，等你把协议格式记住，再看switch (cmd)就会觉得顺理成章——它基本上就是协议表格的直译。这一章把三件事说透：命令字怎么编码、报文怎么拼、两种传输通道各管什么。

2.1 命令字：一个 32 位整数塞下命令和选项

整个协议最核心的设计就是这个 32 位无符号整数。低 8 位是命令号，决定「要干什么」；高 8 位是选项位，决定「这件事怎么做」。一个整数字段同时承载动作和修饰，报文就能做到极短。

/* 低 8 位命令号，高 8 位选项位 */ #define IPMSG_CMD_MASK 0x000000FFu #define IPMSG_OPT_MASK 0xFFFFFF00u /* 命令号：低 8 位 */ #define IPMSG_BR_ENTRY 0x00000001u /* 上线宣告，UDP 广播 */ #define IPMSG_BR_EXIT 0x00000002u /* 下线通知 */ #define IPMSG_ANSENTRY 0x00000003u /* 应答别人的上线宣告 */ #define IPMSG_SENDMSG 0x00000020u /* 普通消息 */ #define IPMSG_RECVMSG 0x00000021u /* 收到确认，附加消息带原包编号 */ #define IPMSG_READMSG 0x00000030u /* 消息已被阅读 */ #define IPMSG_GETFILEDATA 0x00000060u /* 请求文件数据，走 TCP */ #define IPMSG_RELEASEFILES 0x00000061u /* 释放文件会话 */ #define IPMSG_GETDIRFILES 0x00000062u /* 请求目录结构 */ /* 选项位：高 8 位，可以和任意命令号叠加 */ #define IPMSG_SENDCHECKOPT 0x00000100u /* 要求对端回 RECVMSG */ #define IPMSG_SECRETOPT 0x00000200u /* 密封消息，需先解锁才能读 */ #define IPMSG_BROADCASTOPT 0x00000400u /* 本条是广播 */ #define IPMSG_FILEATTACHOPT 0x00200000u /* 附加消息里带文件清单 */ #define IPMSG_READCHECKOPT 0x00100000u /* 要求对端回 READMSG */

代码里判定一个包，标准写法是先掩码再分支，两个动作分开做，不要图省事直接拿整个mode去switch：

unsigned int cmd = mode & IPMSG_CMD_MASK; /* 动作 */ int need_ack = (mode & IPMSG_SENDCHECKOPT) != 0; /* 修饰 */ int has_file = (mode & IPMSG_FILEATTACHOPT) != 0; switch (cmd) { case IPMSG_BR_ENTRY: add_to_host_list(addr, pkt); /* 加入成员表 */ send_ansentry(addr); /* 必须回一个应答 */ break; case IPMSG_SENDMSG: show_message(pkt); if (need_ack) send_recvmsg(addr, pkt->packet_no); if (has_file) handle_file_attach(pkt); break; default: break; }

这里的血泪经验是BR_ENTRY必须回ANSENTRY。两个人几乎同时启动时，双方的广播可能在网络上交错，如果只单向广播不回应答，就会出现「我能看见你、你看不见我」的经典状态，用户第一反应是软件坏了，其实是一个应答没发。

参数上还要注意：命令号只占低 8 位，所以最大值是0xFF；已用命令号集中在0x01到0x62之间，后面大段是空的，这正是二次开发时可以安全扩展的区间，第 6 章会展开。

2.2 报文字段与分隔符：五个冒号切出六个字段

一条 IpMsg 报文是纯文本，六个字段用冒号分隔，末尾可以跟一个\0：

版本号:包编号:用户名:主机名:命令字:附加消息

举一条真实的发送消息报文，能看到它有多朴素：

1:127:dev01:dev01-pc:32:午饭吃什么

第一位1是协议版本号，目前固定为 1，接收方一般不强校验。第二位127是包编号，从 1 开始自增，回绕后重新从 1 开始，它是整个协议里唯一的「请求-响应」匹配依据——对方回RECVMSG时，附加消息里放的就是这个编号。第三、第四位是显示名和主机名，成员列表上显示的是前者，后者主要用于排查。第五位是刚才讲的命令字，注意这里是十进制字符串，不是十六进制。第六位之后是附加消息，可能很长，也可能为空。

解析时最容易翻车的地方就是附加消息里本身就带冒号。协议给的解法是转义：附加消息中的单个:写成::，接收方解析时再还原。所以解析器的正确姿势不是strtok，而是「只切前五个冒号，剩下的整段当附加消息」：

int parse_packet(char *raw, ipmsg_pkt *out) { char *p = raw; out->version = (unsigned int)strtoul(p, &p, 10); if (*p != ':') return -1; p++; out->packet_no = (unsigned int)strtoul(p, &p, 10); if (*p != ':') return -1; p++; out->user = p; p = strchr(p, ':'); if (!p) return -1; *p++ = '\0'; out->host = p; p = strchr(p, ':'); if (!p) return -1; *p++ = '\0'; out->mode = (unsigned int)strtoul(p, &p, 10); /* 十进制！ */ if (*p != ':') return -1; p++; out->extra = p; /* 剩下整段，含 ':' 都保留 */ unescape_colon(out->extra); /* 把 '::' 还原成 ':' */ return 0; }

三个细节值得记一下。命令字用strtoul的十进制模式，写错成十六进制解析，32会变成0x32，后面所有分支全部对不上。extra指针指向原始缓冲区内部，这意味着缓冲区不能在回调结束前释放，我一般会把整包拷进消息队列再解析。转义还原要么原地做（需要一个读写指针），要么解析时按::跳过，两种都行，但别在拼装端忘了转义——发送端不转义、接收端硬切五刀，中文文件名里带个冒号就丢字段。

2.3 双通道：UDP 管发现和信令，TCP 管搬数据

协议把传输拆成两条腿，这是它最值得抄的地方。UDP 走 2425 端口，承担上线广播、下线通知、普通消息、文件传输前的握手信令；TCP 同样走 2425 端口，只在真正传文件时建立，用来倒字节流。

为什么这么分？上线广播必须是一对多，UDP 广播天然合适，丢一两个包也无所谓，下次心跳或者对方上线时再补上就行。而文件传输动辄几十兆，UDP 自己实现可靠传输等于重写一遍 TCP，不如直接开连接。所以你在代码里会看到：UDP socket 常驻监听，TCP 监听 socket 也常驻，但 TCP 连接是「用完就关」的短连接，一个文件一条连接，传完RELEASEFILES立刻断。

广播地址一般填受限广播255.255.255.255，也可以在多网卡机器上按每块网卡的子网掩码算出定向广播地址逐个发。这里有个玄学问题：机器插了两根网线、或者装了虚拟机网卡时，255.255.255.255从哪块网卡出去由路由表决定，经常只发到其中一段，另一段的同事就死活看不见你。稳妥做法是枚举本机所有网卡，逐个算定向广播地址发一遍，接收端靠报文的源 IP 自动识别对端地址，不需要额外字段。

3. 目录与构建：源码包先看哪几个文件，Windows 与 Linux 怎么编

3.1 目录划分与关键文件清单

这份包解开之后，值得先花十分钟把目录扫一遍再动手编。它的组织方式是典型的「协议层 + 界面层」两段式，协议相关的代码被压得很薄，界面反而占了大部分体积。下面是我手上这类源码包的常见结构，不同分支的文件名会有出入，但职责切分基本一致：

ipmsg/ ├── src/ │ ├── ipmsg.h # 协议常量、命令字、报文结构体、端口定义 │ ├── ipmsg.c # 报文拼装与解析、成员表增删查 │ ├── ipmsgctrl.c # 协议状态机：上线、应答、收发调度、重发队列 │ ├── hostinf.c # 成员表维护与超时回收 │ ├── filetx.c # 文件/目录传输的请求与落盘 │ ├── socket.c # UDP/TCP 的薄封装，屏蔽平台差异 │ └── ui/ # 界面层，Windows 与 GTK 各一套 ├── doc/ # 协议说明、命令字表、报文样例 └── Makefile / *.dsp / *.vcproj

真正决定你能不能改得动的，是ipmsg.h和ipmsg.c。前者是协议常量的唯一来源，把命令号、选项位、端口、结构体都放在这一个头文件里，好处是界面层引用它就能拿到全部定义，坏处是改常量时全工程重编。ipmsg.c里那几个函数是无状态的纯函数——给个缓冲区、给几个参数，拼出一条报文；给一条报文，切出结构体。无状态意味着可以单独拎出来做单元测试，这一点在第 6 章抽库时会非常省事。

ipmsgctrl.c则是有状态的，它维护了「谁在等我回确认」「哪条消息发出去还没被确认」「哪个文件会话传到了第几字节」这三类上下文，是全书最长的文件之一。刚上手别一上来就啃它，先把前两个文件看明白。

3.2 两套构建：Windows 的工程文件与 Linux 的 Makefile

Windows 那套直接用工程文件打开就能编，依赖只有系统自带的 socket 和界面库，没有第三方包，这一点对老项目很友好。要注意的是它大概率是老版本的工程格式，用新版 IDE 打开会提示升级工具集，一路确认即可，然后检查一下字符集设置——如果工程默认是 Unicode，而协议层代码是按多字节字符写的，编出来中文会全变问号，改回多字节或者统一加转换宏都行。

Linux 那套是 GTK 图形界面加一份Makefile，编译前需要开发包。用pkg-config把编译参数拉出来最省事，别手写一堆-I：

# 先确认 GTK 开发包在不在 pkg-config --modversion gtk+-2.0 # 编译（Makefile 里通常已经这么写了，这里是手动版） gcc -O2 -Wall -o ipmsg \ src/ipmsg.c src/ipmsgctrl.c src/hostinf.c src/filetx.c src/socket.c \ src/ui/main_gtk.c \ $(pkg-config --cflags --libs gtk+-2.0) # 运行，普通用户即可，但需要能绑 2425 端口 ./ipmsg

-Wall建议保留，这套代码年代久远，打开告警能提前发现一批「有符号/无符号比较」「隐式截断」的问题，尤其是端口和包编号都是无符号的，混着int用很容易在包编号超过 2^31 时翻车（虽然实际跑不到）。

编不过的常见原因集中在两处：GTK 版本不对（代码里用了 GTK 1.x 的旧 API，得装兼容层或者局部改掉），以及老式 K&R 风格函数声明被新编译器拒绝。后者加-std=gnu89或者逐个改成 ANSI 原型，工作量取决于你打算改多深。

3.3 编译后的第一次运行：先把防火墙放行

第一次跑起来，十有八九会遇到「自己看得见自己，看不见别人」。这不是代码问题，是端口没通。程序同时使用 UDP 和 TCP 的 2425 端口，两个都要放行，只放行一个会出现「能发消息但传不了文件」这种更迷惑的现象——因为信令走 UDP，文件走 TCP。

先在单机上验证基础功能：启动两个实例，会看到成员列表里出现本机的两条记录，给自己发一条消息，确认收发链路和字符集都正常。这个自环测试很重要，它把网络因素排除掉了，剩下的问题就只可能是协议实现。

再做双机验证。两台机器必须在同一个子网内，广播才到得了，跨网段广播默认被路由器丢掉，这是设计前提不是 bug。如果条件有限，用两台虚拟机桥接在同一张虚拟交换机上也行，但要关掉虚拟网卡的「隔离」选项，否则广播出不了虚拟机。

4. 核心模块：从上线广播到文件落盘的完整链路

这一章按时间顺序走一遍：程序启动后做了什么、别人上线时怎么响应、消息怎么收发、文件怎么从一台机器落到另一台机器的硬盘上。跟着这个顺序读代码，比按文件顺序读要快得多。

4.1 成员表：一个链表撑起整个在线列表

在线列表的本质是「最近一段时间内听见过的人」。结构体很简单，但每个字段都有明确的用途，少一个都要出问题：

typedef struct _host_entry { unsigned long addr; /* 网络字节序的对端 IPv4 地址，报文的源地址 */ char name[64]; /* 显示名，来自报文第 3 字段 */ char host[64]; /* 主机名，来自报文第 4 字段 */ unsigned int mode; /* 最近一次收到的命令字，用来判断是否处于离开状态 */ time_t last_recv; /* 最后一次收到该对端报文的时间戳 */ struct _host_entry *next; } host_entry;

addr直接用recvfrom拿到的源地址，不需要报文里再带 IP 字段，这样伪造 IP 的成本会高一些，也省了几个字节。last_recv是超时回收的唯一依据——协议没有专门的心跳包，靠的是「对方总会时不时发点什么」这个软假设，因此回收阈值不能设太短。常见做法是五分钟没收到任何报文就摘掉，界面上表现为离线。

上线流程分三步走，顺序不能乱：

/* 1. 启动时先把自己放进列表，界面立刻有东西可显示 */ host_entry *me = add_host(get_local_addr(), user_name, host_name); /* 2. 往广播地址发 BR_ENTRY，宣告「我来了」 */ send_entry(INADDR_BROADCAST); /* 3. 进入主循环，等待别人的 BR_ENTRY 和 ANSENTRY */

收到别人的BR_ENTRY时，做两件事：把发送方加进（或更新到）成员表，然后回一条ANSENTRY。回应的目的是让「同时上线」的双方都能互相看见，这是前面的老坑。收到BR_EXIT就直接摘节点，不用等超时；收到ANSENTRY只更新成员表，不再回包，否则会形成回包无限循环。

还有一个容易被忽略的细节：同一个 IP 重复发BR_ENTRY时要走「更新」而不是「新增」，否则用户改个昵称，列表里就多出一个幽灵。比较稳妥的做法是以addr为唯一键查找，找到就覆盖name、host、mode，没找到才申请新节点。

4.2 主循环：select 之上的单线程事件分发

这套代码是单线程事件驱动的，没有线程池，也没有异步框架，所有事情都在一个for(;;)里完成。在当时那个环境下这是最合理的选择：避免成员表的并发加锁，也避免了界面上要处理跨线程刷新。放到今天看，逻辑依然清晰，只是写起来啰嗦。

for (;;) { fd_set rfds; struct timeval tv = { 1, 0 }; /* 1 秒超时，用来跑周期性任务 */ int maxfd = -1; FD_ZERO(&rfds); FD_SET(udp_fd, &rfds); /* 常驻：收信令和消息 */ FD_SET(tcp_listen_fd, &rfds); /* 常驻：收文件请求 */ if (udp_fd > maxfd) maxfd = udp_fd; if (tcp_listen_fd > maxfd) maxfd = tcp_listen_fd; /* 正在传输的文件连接也要加进监听集合 */ for (file_sess *s = sessions; s; s = s->next) { FD_SET(s->fd, &rfds); if (s->fd > maxfd) maxfd = s->fd; } int n = select(maxfd + 1, &rfds, NULL, NULL, &tv); if (n > 0) { if (FD_ISSET(udp_fd, &rfds)) do_udp_recv(); if (FD_ISSET(tcp_listen_fd, &rfds)) do_tcp_accept(); for (file_sess *s = sessions; s; s = s->next) if (FD_ISSET(s->fd, &rfds)) do_file_recv(s); } else if (n == 0) { /* 超时分支才是真正干周期活的地方 */ sweep_hosts(); /* 清掉超时未见的成员 */ retry_unacked(); /* 重发等待确认的消息 */ flush_ui(); /* 批量刷新界面，别每条消息都刷 */ } }

select的超时参数是关键。传NULL会永久阻塞，超时回收和重发就永远跑不到；传太小的值（比如 100 毫秒）会让 CPU 空转。1 秒是个合适的折中，人的感知阈值远大于这个数。

retry_unacked那段值得单独说：带SENDCHECKOPT的消息发出去之后，要记进待确认队列，记录包编号、目标地址、发送时间、重试次数。超过一定时间没收到RECVMSG，就重发；重试三次还没确认，就在界面上标一个叹号。没有这套机制，UDP 丢一个包，用户就会以为对方没收到，实际上对方收到了但确认丢了——这是最容易吵起来的 bug。

4.3 文件传输：信令在 UDP，数据在 TCP

这是整套协议里最绕的一段，把它拆成五个动作就清楚了：

1. 发送方通过 UDP 发SENDMSG，命令字里带上IPMSG_FILEATTACHOPT，附加消息不再是文本，而是一份文件清单。清单里每一项用\0分隔，每项内部用:分段：文件名:文件大小:修改时间:文件属性，后三个都是十六进制。
2. 接收方弹窗让用户选接收还是拒绝。同意就回RECVMSG确认；拒绝就回一条普通消息说明原因。
3. 接收方为每个文件建一条 TCP 连接，连到发送方的 2425 端口，发GETFILEDATA，附加消息是文件ID:偏移量，两个都是十六进制。文件 ID 是发送方在清单里按顺序分配的，从 1 开始；偏移量首次为 0。
4. 发送方收到请求，打开对应文件，lseek到偏移量，然后在这条 TCP 连接上源源不断地写文件内容，直到文件结束，关闭连接。
5. 全部收完，接收方发RELEASEFILES通知对方清理会话。

偏移量这个设计直接把断点续传做好了。传输中断后，接收方只要记住已经落盘的字节数，重连时把偏移量填进去，发送方从那个位置继续写就行，协议层面不需要任何额外命令。我见过不少自己实现的传文件功能，把续传做成了「重传整个文件」，用上这套协议就白捡了这个能力。

一个必须注意的实现细节：TCP 上没有消息边界。发送方写的是裸文件字节，接收方不能假设一次recv就是一个完整块，必须循环读、按清单里声明的大小截断。经常有人在这里算错——多收了下一个文件的头几个字节，解决方案是严格按「本文件剩余字节数」控制每次读的长度。

4.4 拼装与解析：两个函数把协议落成代码

协议层最值得抄的就是这两个函数，短小、无状态、可单测。先看拼装：

/* 返回值：成功返回缓冲区指针，失败返回 NULL */ static char *build_packet(char *buf, size_t cap, unsigned int packet_no, const char *user, const char *host, unsigned int mode, const char *extra) { char esc[1024]; escape_colon(esc, sizeof(esc), extra ? extra : ""); /* ':' -> '::' */ int n = snprintf(buf, cap, "%u:%u:%s:%s:%u:%s", IPMSG_VERSION, packet_no, user ? user : "", host ? host : "", mode, esc); if (n < 0 || (size_t)n >= cap) return NULL; /* 截断了就当失败 */ return buf; }

snprintf的返回值必须判，很多人只看< 0，不看>= cap，结果超长消息被悄悄截断，收端解析出的附加消息缺尾巴，表现为「长消息发到一半就没了」，排查半天以为缓冲区溢出，其实是截断。参数上mode用%u输出十进制，packet_no同理，这两个都不能用%d，无符号值超过INT_MAX时会打出负数。

再看上面 2.2 节那份解析函数，它做了三件事：切字段、转十进制、还原转义。配合一个包编号生成器，协议层就齐了：

static unsigned int g_packet_no = 0; unsigned int next_packet_no(void) { g_packet_no++; if (g_packet_no == 0) g_packet_no = 1; /* 0 保留，回绕后从 1 重新开始 */ return g_packet_no; }

包编号 0 保留不用的原因很简单：有些实现对 0 做了特殊判断，用它当普通编号会踩到兼容性问题。回绕用if而不是取模，是为了明确跳过 0，代价是每次多一条分支，可以忽略。

5. 常见问题排查：广播收不到、中文乱码、文件传一半

5.1 两边都能上网，就是看不见对方

现象：两台机器在同一间办公室，各自都能正常上网，程序都启动了，成员列表里只有自己。

原因：广播报文没有跨过第一跳。三种可能——防火墙默认丢弃入站 UDP 2425；机器有多块网卡，广播只从默认路由那块发出去；两台机器虽然物理上在一起，但划分在不同 VLAN，广播域不同。

解决：先把防火墙的 UDP 和 TCP 2425 都放行，注意两个协议都要放，只放 UDP 会出现能发消息不能传文件。多网卡的机器改成枚举所有网卡分别算定向广播地址，逐个发送，不要只发255.255.255.255。VLAN 隔离这个没法从应用层解决，属于网络配置问题，跨网段部署时得考虑单播发现或者手工添加对端地址。

5.2 中文用户名显示成问号或者方块

现象：Windows 端发的消息，Linux 端收到是一串问号；反过来则是乱码方块。

原因：协议本身是纯文本但没有规定字符编码，谁写的就用谁的本地编码。Windows 上默认是多字节字符集，实际是 GBK；Linux 上通常是 UTF-8。两边都按自己的编码解读对方，必然对不上。

解决：短期方案是把界面语言统一，比如全部改成英文，先排除编码因素验证功能。要真正互通，就得在协议层做转换——发送前统一转成 UTF-8 再拼报文，接收后按本机编码转回来。这一步在 Windows 端需要调系统 API 做转换，在 Linux 端反而简单。不建议在报文里加编码标识字段，那会破坏和老客户端的兼容性，除非你能控制两端都升级。

5.3 文件传到一半卡住，然后连接被重置

现象：几百 K 的小文件没问题，几十兆的大文件传到某个位置就停了，接收端提示连接断开。

原因：多个可能，按出现频率排序。一是发送方用阻塞 socket 写，接收方处理慢（比如在 UI 线程里直接写磁盘），TCP 发送缓冲区满后写操作阻塞，把整个主循环卡住了，其他消息全部超时。二是接收方recv之后按固定大小当完整块处理，字节数算错，下一次读就越界或者错位。三是偏移量用了long在 32 位平台上不够，超过 2G 的文件直接负数。

解决：把文件 socket 设成非阻塞或者放在独立处理路径里，至少不能阻塞主循环，进度更新交给超时分支批量刷新。接收逻辑严格按「剩余字节数」算本次读多少，recv返回值小于预期就是没读完，继续循环。偏移量统一用 64 位整型，并且打印日志时用对应的格式符，别用%d。这三条我都踩过，第二条最难查，因为小文件永远正常。

5.4 消息偶尔重发，对方收到两条一模一样的

现象：网络稍有抖动，接收方就会看到同一条消息出现两三次。

原因：发送方带SENDCHECKOPT的超时重发机制在起作用，但接收方没有做去重。UDP 上「确认丢失」和「消息丢失」对发送方来说长得一模一样，只能重发，去重的责任在接收方。

解决：接收方维护一个最近收到包编号的小窗口，按源地址加包编号做去重，窗口大小覆盖重试周期就够了。别用全局的包编号集合，包编号是每个发送端独立自增的，两台机器可能同时发 100 号。另外要注意重发的是同一条消息，界面上不应该重复弹窗，应该更新原有那条的状态。

5.5 启动就报端口占用，程序起不来

现象：双击运行立刻退出，日志里写绑定失败。

原因：2425 端口被占。最常见的是自己上一次没正常退出，进程还挂在后台；其次是另开了一个实例；少数情况是别的程序占用了这个端口。

解决：先查是谁占的，Linux 上用ss -lunp | grep 2425或ss -ltnp | grep 2425看 UDP 和 TCP 分别被谁占着。如果是自己的残留进程，正常退出走BR_EXIT广播，让别人的列表立刻清掉你，不要直接杀进程，否则对端要等超时才会把你摘掉，看起来像是「人走了名字还挂在列表上」。

提示：UDP 和 TCP 用的是同一个端口号，这是协议设计的一部分，排查时要两个都查，只查一个容易漏。

6. 二次开发：把协议层抽出来当库用

这套源码最值钱的用法，不是把它当成品改界面，而是把协议层抽出来，接进你自己的系统。我一般这么做：新建一个目录，只把ipmsg.h和ipmsg.c搬过去，这两个文件不依赖界面、不依赖平台 socket，纯粹是字符串进、结构体出。编译成静态库之后，上层想怎么用都行——命令行工具、桌面程序、甚至嵌到别的运行时里。

抽出来之后第一件事是给上层设计回调，而不是让上层直接调recv：

typedef struct { void (*on_host_online)(const char *name, const char *host, unsigned long addr); void (*on_host_offline)(unsigned long addr); void (*on_message)(unsigned long addr, const char *text); void (*on_file_offer)(unsigned long addr, const char *name, unsigned long long size); } ipmsg_cb;

回调一立起来，界面层就变成了订阅者，换 UI 不用碰协议代码，加日志也不用改协议。

第二件事是扩展命令号。低 8 位里0x70往后的区间是空的，挑一个没用过的当自己的命令，比如0x00000080，配上你自己的高 8 位选项位。扩展的时候有两个硬约束：一是别复用已占用的编号，二是别指望原版客户端能懂你的新命令——它们收到未知命令会走default分支静默丢弃，这正好是安全的降级行为，不会崩。所以自定义命令只在同版本客户端之间生效，做内部功能足够。

验证手法上，别一上来就写完整业务，按这个顺序走：先只发BR_ENTRY和ANSENTRY，抓包确认两台机器的成员列表都能正确建立；再接SENDMSG和RECVMSG，确认包编号能对上；最后接文件传输，先传一个 1KB 的小文件确认流程，再传一个 100MB 的确认偏移量和阻塞处理。每一步都能用tcpdump或者抓包工具看到明文报文，这也是这套协议最大的好处——纯文本，出问题肉眼就能读出来，不用对着二进制猜。

有一个我自己的教训：早期改这套代码时，为了图快直接把协议处理和界面刷新写在一个函数里，结果加一个自定义命令要同时改三处 UI 代码，后来加第二个命令时整个文件已经改得面目全非。从那以后我每次碰这类老协议代码，都强制先花半天把协议层和 IO 层切开，哪怕当时觉得没必要。切开之后你会发现，后面所有的功能扩展都变成了「加一个回调 + 加一个命令号」两件事，改起来心里有底。希望帮到你。

本文还有配套的精品资源，点击获取