简介一份面向网络编程学习者的Flash游戏与服务器通信案例包涵盖Flash赛车小游戏、基于TCP的控制台服务器程序及完整工程源码重点演示了select模型在并发连接处理中的实际应用。资源共15个文件压缩包大小仅649KB包含cpp源文件、exe可执行程序、pdb调试信息、dsp/dsw工程文件及h头文件等便于读者在VC6.0环境下直接编译、运行并跟踪调试服务器响应过程。案例包中的服务器采用命令行控制台形式与flash_car2客户端通过TCP交换数据包完整展现了玩家操作指令、游戏状态同步等协议字段设计可帮助理解包头、标识符等关键概念。已有235人学习下载适合正在学习网络编程、I/O多路复用或希望动手实践TCP服务器开发的读者。通过阅读源码和运行程序可以直观看到select如何监控多个套接字、处理非阻塞读写并掌握早期Flash游戏与服务器交互的典型实现思路。1. 一个Flash小游戏服务器的完整形态TCP select 模型的实战闭环把一份打包好的 Flash 小游戏和配套服务器源码拆开看第一反应是这年头还有谁用 ActionScript 写游戏但恰恰是这个看似过时的组合把 tcp select模型 讲得最透彻。服务器用纯 C 实现单线程里管理几百个 Socket 连接客户端是 AS3 写的打飞机小游戏通过自定义二进制协议收发数据。如果你正在做联机小游戏后端或者想搞懂 select 模型到底怎么在工作中落地这份资源值得你下载跑一遍——它能让你看到一套完整、可运行的长连接游戏服务器骨架从登录验证、心跳保活到断线重连全都有改一改就能当成自己项目的通信底座。2. 技术选型与协议设计为什么是 TCP 长连接而不是 HTTP 轮询2.1 Flash 客户端的网络约束AS3 Socket 的硬限制Flash 客户端在网络上的玩法要比普通桌面程序麻烦不少最典型的是沙箱限制。AS3 的 Socket 类在 connect 之前会先自动尝试加载安全策略文件在网页里运行时还会检查目标域名是否被授权。这个机制直接决定了想把游戏服务器跑起来必须先搞定 crossdomain.xml 或者 843 策略服务器的配置否则客户端连握手都做不完。但换一个角度看只要这层跨过去Socket 就是一条干净的 TCP 长连接实时性比 HTTP 轮询好很多。打飞机这类游戏玩家位置和子弹轨迹实时变化用 HTTP 轮询的话延迟高不说每次请求都要重新建连接服务器压力也大。一条 TCP 连接建立后可以持续双向收发数据服务器还能主动往客户端推消息这是 HTTP 轮询做不到的。所以项目在早期就定了 TCP 长连接方案没有走 HTTP 短轮询的弯路这也符合现在多数联机对战游戏的做法——先建立一条长连接再在上面跑自定义协议而不是为每个动作重新请求一次。AS3 Socket 与服务器配合时有两个硬限制要记住。第一调用 connect 之后不能马上 write必须等 Event.CONNECT 事件触发否则数据发不出去第二Socket 的接收是驱赶式触发底层 TCP 会分段应用层收到的数据不是一个完整消息得自己做缓冲和分包处理。很多从 HTTP 时代过来的人第一次写 AS3 Socket 都在这里搭进去大半天的时间。这两个限制直接决定了客户端网络层要封装成什么样子后面联调章节会贴具体写法。2.2 select 模型的工作机制单线程管理多路 IO服务器选型用的 C 语言加 select 模型没有上 epoll 也没有用多线程。原因是这个小游戏服务器的连接规模一般在几百个以内select 模型完全够用而且逻辑简单容易调试。select 的核心机制是把一组文件描述符交给内核内核帮忙监视这些 fd 上的读、写、异常事件调用返回后再逐个 FD_ISSET 判断是哪一个 fd 就绪。这里直接看主循环的骨架fd_set read_fds; struct timeval timeout; while (server_running) { FD_ZERO(read_fds); FD_SET(listen_fd, read_fds); int max_fd listen_fd; for (int i 0; i MAX_CONN; i) { if (clients[i].fd 0) { FD_SET(clients[i].fd, read_fds); if (clients[i].fd max_fd) max_fd clients[i].fd; } } timeout.tv_sec 0; timeout.tv_usec 50000; // 50ms int ret select(max_fd 1, read_fds, NULL, NULL, timeout); if (ret 0) { if (errno EINTR) continue; break; } if (ret 0) { // 超时顺带做心跳检测 check_heartbeat(); continue; } if (FD_ISSET(listen_fd, read_fds)) { accept_new_connection(); } for (int i 0; i MAX_CONN; i) { if (clients[i].fd 0 FD_ISSET(clients[i].fd, read_fds)) { handle_client_read(clients[i]); } } }这里有几个必须写对的地方。FD_ZERO 一定要放在每次循环的最前面因为 select 返回时会原地修改 fd_set把没有就绪的 fd 清掉不重置的话第二次循环就全乱了max_fd 1 这个参数告诉内核扫描的范围传小了会漏掉大 fd 的事件timeout 这里故意设置成 50ms既能让心跳检测及时执行又不会因为频繁空转打满 CPU。select 与多线程方案的区别在于它把等着看有多少个 fd 就绪这件事交给内核做用户态省掉了为每个连接开一个线程的成本。线程切换、栈空间、锁竞争这些问题在单线程 select 里都不存在代码天然是串行的也不会出现两个线程同时操作同一个玩家数据结构的情况。代价是每条消息处理不能做耗时操作这直接影响了后续的模块划分后面会讲怎么绕开这个坑。2.3 应用层协议消息头加消息体解决粘包拆包TCP 是流式协议没有消息边界。客户端连续发两条消息出来服务器一次 recv 可能收到两条的数据也可能一条消息被拆成两次 recv 才收到。处理这类问题需要在应用层定义自己的消息边界项目用的是最常见的定长头加变长体方案。消息头定义如下#pragma pack(1) typedef struct _msg_header { unsigned short magic; // 固定 0xA55A用来快速校验 unsigned short len; // 消息体长度不包含头部本身 unsigned char type; // 消息类型1登录 2移动 3射击 4心跳 unsigned char version; // 协议版本号 } msg_header_t; #pragma pack()magic 字段用两个字节的魔数 0xA55A收到数据后先对魔数对不上就说明连接异常或数据错位直接断开重连len 字段告诉接收方一个完整消息里面消息体有多少字节type 是业务路由的依据。这个头总共 6 个字节紧凑且解析简单。收到数据后的处理流程是先把 recv 到的数据追加进每个连接自己的 recv_buffer然后循环检查 recv_buffer 里够不够一个消息头够的话再检查头部里的 len 字段如果总长度够就切出一个完整的包交给业务层。这里最容易犯的错误是用 recv 的返回值直接当消息长度那会把 TCP 分段当成业务消息后续所有逻辑都会错位。我第一次写这个服务器的时候就在这儿翻过车后来在 buffer 开头打印十六进制才看出来是两个半截消息黏在一起。3. 核心模块拆解一条消息从进入到返回的完整链路3.1 主循环与事件分发accept 和 recv 是两条不同的路select 返回可读事件之后要分两种情况处理。listen_fd 可读意味着有新客户端请求连接走 accept 流程客户端 fd 可读意味着有数据到达走 recv 流程。这两条路径处理逻辑完全不同新手最容易混在一起——在客户端 fd 上调用 accept或者在 listen_fd 上调用 recv都会直接报错。accept 新连接时要留意accept 返回的新 fd 建议立刻设置成非阻塞模式这样后续 recv 在数据没到达时会立即返回 EAGAIN 而不是卡住整个单线程循环。伪代码是这样static void accept_new_connection(void) { struct sockaddr_in addr; socklen_t len sizeof(addr); int cfd accept(listen_fd, (struct sockaddr *)addr, len); if (cfd 0) return; // 设置非阻塞避免单个客户端拖垮循环 int flags fcntl(cfd, F_GETFL, 0); fcntl(cfd, F_SETFL, flags | O_NONBLOCK); // 找到一个空闲的 client 槽位 for (int i 0; i MAX_CONN; i) { if (clients[i].fd 0) { clients[i].fd cfd; clients[i].state STATE_CONNECTED; clients[i].last_heartbeat g_game_time; snprintf(clients[i].name, sizeof(clients[i].name), player_%d, i); break; } } }当 accept 过来的客户端 fd 是可读状态时recv 读到的数据存储在临时缓冲区里再追加到该连接的 recv_buffer。recv 的返回值有三类情况大于 0 说明读到了数据等于 0 说明对端正常关闭小于 0 时再看 errno如果是 EAGAIN 或 EWOULDBLOCK说明非阻塞模式下暂时没有数据直接返回即可如果是其他错误就关闭连接。这里有个细节临时缓冲区的大小不要贪大2KB 足够recv_buffer 才是真正积累数据的地方。static void handle_client_read(client_t *c) { char tmp[2048]; ssize_t n recv(c-fd, tmp, sizeof(tmp), 0); if (n 0) { if (n 0 (errno EAGAIN || errno EWOULDBLOCK)) return; close_connection(c); return; } append_to_buffer(c, tmp, n); parse_and_dispatch(c); }append_to_buffer 做的事是把 tmp 里的数据拷贝到 c-buf 尾部同时更新 c-buf_len。普通实现里要检查缓冲区剩余空间这部分一般用固定数组手动管理如果接满 64KB 还没有构成完整消息说明协议有问题或者对端在乱发数据直接断开连接是比较稳妥的选择。3.2 消息解析与路由把字节流变成业务调用parse_and_dispatch 是服务器的核心解析函数。它会在一个 while 循环里反复尝试从 recv_buffer 头部切出一个完整消息切成功就交给对应处理函数切不出来就说明数据还没凑齐退出循环等下次 recv 再继续。这个循环结构是处理粘包拆包的关键。static void parse_and_dispatch(client_t *c) { for (;;) { if (c-buf_len (int)sizeof(msg_header_t)) break; msg_header_t *hdr (msg_header_t *)c-buf; if (hdr-magic ! 0xA55A) { close_connection(c); return; } int total (int)sizeof(msg_header_t) hdr-len; if (c-buf_len total) break; // 半包等下一次 recv switch (hdr-type) { case MSG_LOGIN: handler_login(c, hdr); break; case MSG_MOVE: handler_move(c, hdr); break; case MSG_SHOOT: handler_shoot(c, hdr); break; case MSG_HEARTBEAT: handler_heartbeat(c); break; default: close_connection(c); return; } // 消费完一个包把已处理的数据移出缓冲区 int consumed (int)sizeof(msg_header_t) hdr-len; memmove(c-buf, c-buf consumed, c-buf_len - consumed); c-buf_len - consumed; } }因为消息头是 #pragma pack(1) 紧凑排列的可以直接把 c-buf 强制转换成 msg_header_t 指针来读取字段这在单线程模型里没有对齐问题。handler 函数内部拿到 hdr 指针之后根据 len 字段在缓冲区里定位消息体内容再按协议文档解析业务字段。每个 handler 执行完整个包就从缓冲区头部移出循环继续处理下一个包。路由到 handler 之后业务逻辑才能访问玩家数据。比如 handler_move 会读出玩家最新坐标更新玩家结构体同时给同房间的其他玩家广播位置同步消息。广播的逻辑是遍历所有已登录玩家把要发送的数据写入各自的可写缓冲区真正调用 send 的操作统一在 select 主循环的写事件处理里完成。这样做的好处是业务 handler 里不直接阻塞在 send 上而是把发送动作延迟到统一的写事件检查避免某一个客户端网速慢导致整个服务器卡住。3.3 玩家会话管理心跳、超时与断线处理每个连接对应一个 client_t 结构体但玩家登录前后这个结构体里的内容不一样。登录之前叫连接登录之后才被填充玩家名和坐标。结构体大概长这样typedef struct _client { int fd; int state; // STATE_CONNECTED / STATE_LOGINED int session_id; char name[16]; int pos_x; int pos_y; int last_heartbeat; // 最近一次心跳时间 char buf[65536]; // 接收缓冲区 int buf_len; char send_buf[4096]; // 待发送缓冲区 int send_len; } client_t;心跳机制的实现思路其实很朴素。服务器里有一个全局 g_game_time每隔一秒由主循环的 timeval 超时之后递增一次。每次从客户端收到任何消息都会刷新 last_heartbeat。check_heartbeat 函数会在每次 select 超时后遍历所有客户端如果当前时间减去 last_heartbeat 超过 30 秒就判断这个客户端已经掉线主动 close 连接并释放槽位。断线处理的难点在于玩家正玩到一半突然网络抖动的情况。服务器这边选择了先保守断开客户端那边再做重连机制。重连时客户端会带上自己上一次的 session_id服务器如果发现玩家结构体还在内存里就恢复坐标继续游戏如果已经超时清理就当作新玩家处理。这套逻辑人少的时候够用但真要做全区全服的断线重连还是得引入注册中心之类的组件那是后话了。4. 工程落地目录结构、配置文件与 Flash 客户端联调4.1 工程骨架src、include、client 三个目录各司其职拿到这份源码先看目录结构能少走很多弯路。项目分成三个顶层目录服务器代码在 server 下Flash 客户端在 client 下协议文档放在 doc 下。server 目录又细分了 include 和 src头文件放 includeC 文件放 src。Makefile 放在 server 根目录。game_project/ ├── server/ │ ├── include/ │ │ ├── protocol.h # 消息头定义、消息类型枚举 │ │ └── server.h # 客户端结构体、全局变量声明 │ ├── src/ │ │ ├── main.c # 入口加载配置、启动主循环 │ │ ├── reactor.c # select 主循环、accept、recv │ │ ├── protocol.c # 缓冲区管理、拆包、路由分发 │ │ └── handler_login.c # 登录、移动、射击、心跳处理 │ ├── Makefile │ └── config.ini ├── client/ │ └── src/ │ ├── Game.as # 游戏主逻辑 │ └── NetClient.as # Socket 封装 └── doc/ ├── protocol.md # 协议文档 └── deploy.md # 部署说明这种按功能拆分的目录结构到今天也是主流好处是 protocol.c 只管数据帧解析reactor.c 只管 IO 事件handler 只管业务。协议一旦变更只需要改 protocol.h 和对应的 handler主循环不受影响。我从这个项目里学到的习惯是网络层、协议层、业务层必须严格隔离不然到后期改一个字段能牵连十几个文件。Makefile 里编译用的是 gcc编译命令大致是gcc -Wall -O2 -Iinclude src/main.c src/reactor.c src/protocol.c src/handler_login.c -o game_server -lpthread实际项目里还会加 -D_GNU_SOURCE 之类的宏来启用某些非标准接口但核心编译参数就这几个。要调试时去掉 -O2 换成 -g 就能用 gdb 断点调试。4.2 配置项与启动参数端口、最大连接数、心跳超时主程序启动时读一个 config.ini配置项不多但每个都直接影响服务器行为。默认参数如下配置项默认值说明listen_port8080监听端口客户端 connect 用max_conn256最大客户端连接数对应数组大小heartbeat_timeout30心跳超时秒数log_level10 关闭日志1 只打错误2 打全部bind_ip0.0.0.0监听地址内网调试用 127.0.0.1启动方式支持从命令行覆盖配置方便测试不同参数组合./game_server --port8080 --max-conn128 --heartbeat-timeout30命令行解析用的是最简单的 getopt_long没有引入外部依赖。这种方式的好处是手边没有配置文件时也能直接跑起来适合快速验证。日志会按 log_level 的开关把关键事件比如新连接接入、登录成功、心跳超时踢出等打到标准输出要排查问题时把级别调到 2 看全量日志。4.3 Flash 客户端 AS3 Socket 连接写法与联调Flash 客户端这侧的网络层封装在 NetClient.as 里。核心代码量不大但每一步都有讲究。首先是连接建立private function connect(host:String, port:int):void { socket new Socket(); socket.addEventListener(Event.CONNECT, onConnect); socket.addEventListener(ProgressEvent.SOCKET_DATA, onData); socket.addEventListener(IOErrorEvent.IO_ERROR, onIOError); socket.addEventListener(SecurityErrorEvent.SECURITY_ERROR, onSecurityError); socket.connect(host, port); } private function onConnect(event:Event):void { // 必须等这个事件触发之后才能 write sendLogin(); }注意 connect 之后不要立刻 writeAS3 的 Socket 在连接建立成功之前调用 write 会直接丢数据。登录消息构造好之后通过 writeBytes 写入字节数组再调用 flush 真正发送。Flash 端没有自动分包能力所以 write 的数据要保证是一个完整消息包括消息头。收到服务器数据时SOCKET_DATA 事件会触发socket.readBytes 可以读出一段字节。客户端同样要做粘包拆包处理但因为是同一个协议逻辑和服务器端一致。这里有个常见玄学问题明明服务器发了两条消息客户端一次性都读出来了如果客户端不做拆包第二条消息的解析必然错乱。解决办法就是在客户端也维护一个 receive buffer跟服务器端用同样的解析循环。联调时先用最简单的文本协议确认通路再切二进制协议。我习惯在客户端加一个 debug 面板把收到的原始字节按十六进制打出来。这样服务器广播了一条消息客户端能立刻看到数据帧长什么样协议对不上时不用猜。5. 联调中的常见坑与排查手段select 模型实战踩坑记录5.1 坑一客户端能发能收但收不到服务器主动推送现象客户端点击按钮可以正常发消息给服务器服务器也能在日志里看到消息进来但服务器广播给所有玩家的事件客户端始终收不到。原因服务器端广播时直接调用了 send但 send 在非阻塞模式下如果对方接收窗口已满或者对端处理不过来会返回 EAGAIN。更隐蔽的是select 主循环只监听了 read_fds没有监听 write_fds导致 send_buf 里的数据迟迟没有机会被发送出去客户端自然看不到推送。这个坑是典型的只写了发送代码没做发送调度。解决把发送行为也纳入 select 的写事件管理。需要发送数据时先把数据追加到该连接的 send_buf然后把该 fd 加入 write_fds。select 返回后如果 FD_ISSET 检测到这个 fd 可写再从 send_buf 里取数据调用 send。这样即使某次 send 遇到 EAGAIN数据也还在缓冲区里下次写事件触发时会继续发不会丢消息。5.2 坑二CPU 打满但连接数没多少现象服务器启动后没几个玩家CPU 却稳定在 100%风扇转得厉害。原因八成是 select 的 timeout 设置出了问题。如果把 timeval 的 tv_sec 和 tv_usec 都设为 0select 会变成纯非阻塞轮询每次调用立即返回主循环就变成死循环空转CPU 直接拉满。另一种可能是在 select 前忘记重置 fd_set导致每次都要遍历大量无效 fd但这个一般不会把 CPU 打到 100%。解决timeout 设 50ms 是个比较合适的值。有数据时 select 会立刻返回没有数据时最多等 50ms 才空转一次既保证实时性又不费 CPU。如果对响应时间要求高可以缩短到 10ms但不建议设成 0。我后来查这类问题第一件事就是看 timeout 赋值第二件事才是看连接数。5.3 坑三Flash 沙箱安全策略导致握手失败现象Flash 客户端调 connect 后直接抛 SecurityError连不上服务器。浏览器控制台提示安全沙箱冲突。原因Flash Player 在建立 Socket 连接前会先自动去目标服务器请求安全策略文件。默认是在 843 端口请求一个 XML失败后会尝试在目标端口请求 /crossdomain.xml。如果这两个都拿不到连接会被直接掐断。开发者常常只把注意力放在游戏端口上忘了处理策略文件端口。解决在服务器旁边放一个 crossdomain.xml内容大致是允许所有域名连接。内网联调时最省事的做法是在监听端口上直接响应策略请求或者用一个独立的策略文件服务器监听 843。把 crossdomain.xml 放到 Web 服务器根目录也能解决大部分情况。这个问题在本地 file 协议打开 swf 时几乎必定出现我一般会用 debug 版 Flash Player 加载 swf再配合本地 Web 服务器来避免沙箱干扰。5.4 坑四select 返回可读但 recv 只读到半个包现象客户端发了一个完整消息服务器日志里显示数据长度不对后续消息解析全部错位有时候需要断开重连才能恢复。原因这是 TCP 流式传输的正常现象。一个消息在传输过程中被拆成了两个 TCP 段服务器第一次 recv 只读到前一半第二次 recv 才读完整。如果业务代码直接按 recv 返回长度当成消息长度来处理必然会在第一次 recv 时误判。解决严格按缓冲区分包流程处理。recv 到的数据先追加到 recv_buffer再循环检查缓冲区里是否已经凑齐一个完整消息凑不齐就等待下一条数据。关键判断是缓冲区字节数大于等于消息头长度且大于等于头里声明总长度。半包时 break 退出循环完整包时正常消费并从缓冲区移除。这个逻辑我曾经重写过三次前两次都是贪图方便直接用 recv 返回值血的教训。6. 二次开发从单服到多区、从单线程到线程池的改造思路6.1 用模拟客户端做连接压测的验证方法项目自带的手动联调只能验证单机功能要验证服务器在并发场景下的表现最方便的是写一个模拟客户端脚本。Python 的 socket 库足够做基础压测我一般会写一个脚本创建 200 个 Socket全部连上服务器后循环发送心跳和移动消息观察服务器日志里有没有异常。验证的重点不是跑多快而是确认连接数达到上限时新连接是否被正确拒绝心跳超时后客户端是否被踢出压力下消息解析有没有出现错位。import socket import time import threading clients [] def worker(index): s socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((127.0.0.1, 8080)) # 发送登录消息这里省略消息封装 s.send(b\x5a\xa5\x06\x00\x01\x00) clients.append(s) while True: s.send(b\x5a\xa5\x06\x00\x04\x00) # 心跳 time.sleep(2) for i in range(200): threading.Thread(targetworker, args(i,)).start()压测脚本不要追求模拟真实游戏行为重点是能持续产生连接和心跳流量。跑一段时间后去看服务器内存占用和连接数曲线能发现 recv_buffer 泄漏类的隐性问题。这是我每次改造网络层之前必做的一步。6.2 改造方向消息队列加工作线程池select 单线程模型的短板是无法处理耗时业务比如数据库查询、加密计算。我的改造思路是保持主线程只管 IO业务逻辑丢给一个消息队列由一组工作线程消费。主线程在 recv 之后只做拆包得到完整消息后放入队列立刻返回继续处理下一个套接字。工作线程从队列里取消息执行业务逻辑构造响应消息再通过一个发送队列交回给主线程。这个改造的收益是select 循环不会被单条消息卡在 handler 里几百毫秒整体吞吐量提升明显。但要注意加锁问题消息队列要保证多线程安全主线程和工作线程之间需要一个互斥锁保护队列头部。结构设计上玩家数据结构也要与连接数据结构分离工作线程只操作玩家数据不操作套接字这样锁的粒度可以控制得比较小。改造完记得用模拟客户端压测对比改造前后的吞吐和延迟数据会说话。6.3 收尾这个服务器项目我后来翻出来重构过好几轮每次都在同一个地方栽跟头先写完业务逻辑才回头补协议边界处理。有一次上线前才发现半包问题没有彻底解决客户端偶尔会卡在一个状态里收不到广播排查了一整天才定位到是拆包循环里少了一个 break。从那以后我每次接手网络项目都强制自己先打开协议头文件把消息边界画清楚再谈功能。希望帮到你。本文还有配套的精品资源点击获取