用 C 语言函数表实现通信传输层抽象

用 C 语言函数表实现通信传输层抽象在嵌入式 Linux 或工业控制类程序中一个应用经常需要同时接入多种通信链路例如 UDP、串口、CAN、TCP 或 Unix Socket。这些链路的底层实现差异很大UDP 基于 socket串口基于 tty 设备CAN 基于 SocketCAN不同链路的打开、关闭、收发、文件描述符获取方式都不同如果上层业务直接调用这些底层接口代码很容易变得混乱。业务逻辑中会到处出现sendto、read、write、ioctl、recvfrom等底层调用。一旦增加新的链路或者替换某个链路实现就可能牵动大量业务代码。一种更稳妥的方式是用 C 语言函数表抽象通信传输层再用select在单线程中统一监听多个输入源。1. 为什么要抽象传输层对上层业务来说它通常并不关心底层是 UDP、串口还是 CAN。它真正需要的能力只有几类open();close();send();recv();get_fd();is_open();也就是说上层只关心“这个通道能不能打开、能不能收发、能不能被事件循环监听”。因此可以定义一个统一的传输接口typedefstructtransporttransport_t;typedefstruct{int(*open)(transport_t*t);void(*close)(transport_t*t);int(*send)(transport_t*t,constuint8_t*data,uint16_tlen);int(*recv)(transport_t*t,uint8_t*buf,uint16_tlen,uint32_ttimeout_ms);int(*get_fd)(transport_t*t);int(*is_open)(transport_t*t);}transport_ops_t;structtransport{consttransport_ops_t*ops;void*ctx;};这里的transport_ops_t是一张函数表。它的作用类似面向对象语言里的接口transport_t表示一个抽象传输对象ops表示这个对象支持哪些操作ctx保存具体实现的数据例如 UDP socket、串口 fd、CAN socket 等上层只拿到transport_t *通过t-ops-send()发送数据通过t-ops-recv()接收数据不需要知道底层实现细节。2. 如何把不同设备统一成 transport_t以 UDP 为例可以定义一个具体结构体typedefstruct{transport_tbase;intfd;charremote_ip[32];uint16_tremote_port;intopened;}udp_transport_t;然后实现 UDP 对应的操作函数staticintudp_open(transport_t*t){udp_transport_t*u(udp_transport_t*)t-ctx;u-fdsocket(AF_INET,SOCK_DGRAM,0);if(u-fd0){return-1;}u-opened1;return0;}staticvoidudp_close(transport_t*t){udp_transport_t*u(udp_transport_t*)t-ctx;if(u-opened){close(u-fd);u-opened0;}}staticintudp_send(transport_t*t,constuint8_t*data,uint16_tlen){udp_transport_t*u(udp_transport_t*)t-ctx;returnsend(u-fd,data,len,0);}staticintudp_recv(transport_t*t,uint8_t*buf,uint16_tlen,uint32_ttimeout_ms){udp_transport_t*u(udp_transport_t*)t-ctx;(void)timeout_ms;returnrecv(u-fd,buf,len,0);}staticintudp_get_fd(transport_t*t){udp_transport_t*u(udp_transport_t*)t-ctx;returnu-fd;}staticintudp_is_open(transport_t*t){udp_transport_t*u(udp_transport_t*)t-ctx;returnu-opened;}再把这些函数组装成一张操作表staticconsttransport_ops_tudp_ops{.openudp_open,.closeudp_close,.sendudp_send,.recvudp_recv,.get_fdudp_get_fd,.is_openudp_is_open};初始化时把具体对象和抽象接口绑定起来voidudp_transport_init(udp_transport_t*u){memset(u,0,sizeof(*u));u-base.opsudp_ops;u-base.ctxu;}transport_t*udp_transport_as_transport(udp_transport_t*u){returnu-base;}这样UDP 就被包装成了一个transport_t。串口、CAN 也可以用同样的方法包装transport_t*udpudp_transport_as_transport(udp_obj);transport_t*serialserial_transport_as_transport(serial_obj);transport_t*cancan_transport_as_transport(can_obj);上层看到的都是transport_t *不会再直接依赖 UDP、串口或 CAN 的具体类型。3. 上层如何避免关心底层类型有了统一接口后上层发送数据可以写成这样intchannel_send(transport_t*t,constuint8_t*data,uint16_tlen){if(!t||!t-ops||!t-ops-send){return-1;}if(t-ops-is_open!t-ops-is_open(t)){return-1;}returnt-ops-send(t,data,len);}接收数据也可以统一intchannel_recv(transport_t*t,uint8_t*buf,uint16_tlen){if(!t||!t-ops||!t-ops-recv){return-1;}returnt-ops-recv(t,buf,len,0);}如果以后新增 TCP只需要实现一组tcp_ops并把 TCP 包装成transport_t。业务层的收发逻辑不需要修改。这就是函数指针表的价值把变化隔离在底层把稳定接口暴露给上层。基于 select 的单线程事件循环设计如果每个链路开一个线程当然也能工作。但线程多了以后会带来新的复杂度线程同步共享数据加锁退出流程复杂调试困难时序问题更隐蔽如果通信压力不大或者业务逻辑适合串行处理那么单线程事件循环是很好的选择。核心思路是从每个transport_t里取出 fd加入fd_set调用select哪个 fd 可读就读取哪个通道然后统一做协议解析和业务处理4. 用 select 同时监听多个链路示例代码voidevent_loop(transport_t**channels,size_tcount){while(1){fd_set rfds;intmaxfd-1;FD_ZERO(rfds);for(size_ti0;icount;i){transport_t*tchannels[i];if(!t||!t-ops||!t-ops-get_fd){continue;}intfdt-ops-get_fd(t);if(fd0){continue;}FD_SET(fd,rfds);if(fdmaxfd){maxfdfd;}}structtimevaltv;tv.tv_sec0;tv.tv_usec50*1000;intretselect(maxfd1,rfds,NULL,NULL,tv);if(ret0){for(size_ti0;icount;i){transport_t*tchannels[i];if(!t||!t-ops||!t-ops-get_fd){continue;}intfdt-ops-get_fd(t);if(fd0FD_ISSET(fd,rfds)){uint8_tbuf[1500];intnt-ops-recv(t,buf,sizeof(buf),0);if(n0){handle_input(t,buf,(size_t)n);}}}}elseif(ret0){/* * 实际工程中要处理 EINTR。 * 如果只是被信号中断不一定是致命错误。 */}poll_periodic_tasks();}}这里有一个关键点select的 timeout 不只是等待 IO它还决定了周期任务的调度粒度。例如 timeout 设置为 50ms那么即使没有任何 IO 输入主循环最多也会在 50ms 后醒来一次检查定时任务是否到期。5. 周期任务如何放进事件循环很多程序除了接收数据还需要周期性执行任务例如心跳发送状态上报超时检查定期查询重发控制可以封装一个简单的周期定时器typedefstruct{uint64_tperiod_ms;uint64_tnext_ms;}periodic_timer_t;inttimer_expired(periodic_timer_t*timer,uint64_tnow_ms){if(now_mstimer-next_ms){return0;}timer-next_msnow_mstimer-period_ms;return1;}在主循环里使用periodic_timer_theartbeat_timer{.period_ms1000,.next_msnow_ms()1000};periodic_timer_tstatus_timer{.period_ms200,.next_msnow_ms()200};while(1){uint64_tnownow_ms();if(timer_expired(heartbeat_timer,now)){send_heartbeat();}if(timer_expired(status_timer,now)){send_status();}run_select_once();decode_all_channels();}这种设计的好处是IO 事件和周期任务都在一个线程里处理不需要锁也不会出现多个线程同时修改同一份状态的问题。6. IO 接收、协议解析、业务处理如何拆层一个比较清晰的结构可以分成三层transport 层负责 open / close / send / recv channel 层负责缓存、协议解析、组帧 business 层负责处理解析后的业务消息不要在recv后立刻写复杂业务逻辑。更好的方式是intntransport_recv(...);if(n0){ring_buffer_write(channel-rb,buf,n);}protocol_feed(channel-codec,data,len);while(protocol_pop(channel-codec,frame)){message_parse(frame,msg);message_dispatch(msg);}这样做有几个好处transport只负责字节收发codec只负责帧同步和校验message_parse只负责业务字段解析message_dispatch只负责业务分发每一层都比较纯后期排查问题会轻松很多。7. timeout 怎么设置selecttimeout 太长会影响周期任务响应速度太短又会导致主循环频繁醒来增加 CPU 占用。一般可以按实时性要求选择1000ms适合低频后台任务 100ms 适合普通控制程序 50ms 比较常见的折中值 10ms 响应更快但 CPU 唤醒更频繁更精细的做法是动态计算 timeouttimeoutmin(next_timer_deadline-now,max_select_timeout);这样事件循环可以在最近一个定时任务到期前醒来而不是固定睡眠。但在很多嵌入式程序里固定 10ms、20ms、50ms 已经足够简单可靠。8. 单线程事件循环的优缺点优点结构简单没有锁竞争状态修改顺序清晰调试更容易适合 fd 数量不多、处理逻辑较快的程序缺点某个处理函数耗时太长会阻塞整个循环不能充分利用多核fd 数量很多时select不如epollselect有FD_SETSIZE限制所有业务都需要避免长时间阻塞所以单线程事件循环适合这种场景链路数量有限 单次业务处理很快 状态一致性要求高如果连接数很多或者业务处理耗时较长可以考虑epollworker 线程池IO 线程 业务线程消息队列解耦9. 核心收益用函数表抽象传输层用select做单线程事件循环本质上解决了两个问题。第一屏蔽底层链路差异。上层不再关心 UDP、串口、CAN 各自怎么打开、怎么收发只面向统一的transport_t接口编程。第二集中管理 IO 和周期任务。所有 fd 的输入、周期定时器、协议解析、业务分发都在一个主循环中完成程序行为更可预测。最终结构可以概括为UDP transport \ Serial transport - channel - codec - message - dispatcher CAN transport / select event loop: 1. poll timers 2. wait readable fds 3. recv bytes 4. decode frames 5. dispatch messages这是一种非常适合嵌入式 Linux C 程序的工程结构简单、直接、可扩展也足够稳定。