一种串口通讯新模型的研究与应用

摘要：该文借鉴I/O完成端口模型（IOCP）的核心思想，建立了一个适用于协议性串口通讯的新模型。该模型提出了一个协议性串口通讯的最小单位——“通讯元”，将“通讯元”提交到事件队列线程中自动处理，简化了处理过程并提高了运行效率。同时，该文基于该模型设计出了一个协议性串口通讯模块，以封装通讯底层的细节，从而提供方便的通讯接口。将该模块应用于工业造气炉监控组态软件设计中，实际运行表明：该模型具有简单的接口和稳定、高效的运行机制。

关键词：IOCP；串口通讯；通讯元

中图分类号：TN915 文献标识码：A 文章编号：1009-3044（2013）04-0689-04

The Research and Application of a New Serial Communication Model

CHEN Geng

（College of Information Science & Technology， Xiamen University， Xiamen 361005， China）

Abstract： In this paper， the core idea of I/O Completion Port Model is borrowed to build a new model， which is suitable for the serial communication based on protocol. A minimum unit called ‘communication unit’ is put forward in this model. The ‘communication unit’ is submitted to an event-queue-thread and is dealt automatically. It will help to simplify the process and increase operational efficiency. Meanwhile， in this paper， a serial communication module based on the model is designed to offer a convenient communication interface. The module is applied in the snoopware of industrial gasifier. It’s proved that this model has a simple interface and efficient operation mechanism.

Key words： IOCP； serial communication； communication unit

Web服务器、网络游戏服务器等应用经常会面对海量的客户端连接请求以及数据通信，这种海量的并发的连接请求与数据通信，往往成为制约服务器正常工作的因素。这些与服务器的数据传输具有共同的特点：客户连接量是海量的，但每个连接上收发的数据包容量是较小的。微软公司在Winsock2中引入的完成端口（Completion Port，IOCP）模型提供了最好的伸缩性和最高的数据吞吐率，是处理大量并发连接的最佳方案。

在上位机与多台下位机通过串口通信的环境中，随着连接数的增多，系统通信的速度降低，通信错误率增加，如何有效的管理和协调众多线程，是一个比较困难的问题。该文基于IOCP核心思想提出了一个通讯元模型，并针对实际应用设计了一个支持多串口通讯模块。该模块应用于工业造气炉监控组态软件设计中，实际运行表明：该模型具有简单的接口和稳定、高效的运行机制。

1 I/O完成端口模型（IOCP）简介

1.1完成端口

完成端口是Windows提供的一种高效的I/O模型，它利用少量的工作线程来完成大量的异步I/O处理，使得I/O处理和非I/O处理能够重叠并行的进行，从而满足大并发量管理工作。完成端口的目标就是利用多线程来最大化提高并行执行的效率，避免线程上不必要的阻塞，减少线程上下文切换带来的资源和时间开销。

1.2完成端口工作原理

完成端口会创建一个消息队列和一个线程池。根据计算机系统中的处理器数目，建立相应的工作者线程，这些线程专门用来处理和客户端通信。当客户端建立新的socket连接时，该socket连接的句柄就与完成端口绑定起来。该socket的网络通信请求按照先进先出的方式进入到完成端口的消息队列中去。线程池取出空闲的线程，让线程扫描完成端口中的消息队列，取出队列里面的通信请求（如发送数据、接收数据）并处理。等处理完毕后再扫描队列里面的下一个网络通信请求，如此循环。

需要注意的是，完成端口对工作线程的管理具有一定的原则：首先在创建完成端口时要制定最大的并发线程数（补充的后文流程），一般情况是一个处理器对应一个并发线程，而工作线程的数量大于或等于最大并发线程书。考虑到线程会进入挂起的状态，为了让应用程序有足够的工作线程为I/O请求服务，一般创建工作线程的个数为CPU个数的两倍。

1.3完成端口优势

多线程的方式来处理客户端的socket通信请求，每一个客户端要求连入socket时，都要启动一个新的线程与客户端进行通信。CPU不得不在运行的线程之间进行上下文的切换。因为线程切换是相当占用CPU时间的，当客户端的连入线程过多时，CPU的执行效率将变得非常低下。微软提出完成端口模型，就是为了解决“one-treat-per-client”的问题。完成端口模型能够在只有少量工作者线程的情况下处理大量的socket操作，从而避免多线程造成的线程切换开销，最大限度的提高了网络通信的性能。

2 协议性串口通讯的新模型

2.1 串口通信的一般方式

串口编程有阻塞和非阻塞两种方式。阻塞方式是指在调用函数后，当前线程会被挂起直到接收到数据。非阻塞方式指在调用函数后，该函数不会阻塞当前线程，而会立刻返回，线程可以继续进行其他操作。阻塞模型编程比较简单，但是执行效率低下，适合于并发连接数较少的系统。非阻塞模型编程难度比较大，但是程序执行效率高，适合于连接数大性能的系统。

除了效率问题之外，串口通信时经常会线程超时和串口堵塞问题。特别是在多串口通信中。这两种问题，可以通过程序设计来解决，但这样又增加了程序设计的难度。如果有一种模型，从结构上来解决效率问题，又能解决超时和数据堵塞问题，那这种模型将有深远的意义。

2.2 串口通信的新模型

该模型基于I/O完成端口模型（IOCP）的核心思想，提出了一个协议性串口通讯的最小单位——“通讯元”，每个“通讯元”包括“发送的命令（数据）”、“等待接收的命令（数据）长度”、“超时处理函数的绑定”、“接收数据处理函数的绑定”等部分组成。“通讯元”相当于IOCP中的消息一样，会被提交到事件队列中。一个“通讯元”执行过程中，事件队列线程挂起，等待“通讯元”完成。

“通讯元”结构利用了设计模式中的Composite模式（组合模式）的思想，将每次通讯底层的细节封装起来，对外提供方便的通讯接口。发送数据对象、接收数据对象、超时处理对象、数据处理对象与通讯元接口是聚合关系，且是一对多关系。这种设计结构有利于方便的为通讯元添加其他通讯相关的对象，使得通讯的处理过程更加简化高效，同时使得程序有更强的可移植性。

2.3 新模型工作机制

图2 新模型机制

程序主线程启动后，开启通讯元引擎，进行串口的初始化和通讯元的初始化。通讯元引擎创建通讯元的接收队列、发送队列、消息处理队列和超时处理队列。当串口发生通讯操作时，工作者线程启动，通讯元进入消息队列。工作者线程按照先进先出的原则，提取队头的通讯元，再从线程池中取出空闲的线程，在空闲线程中依次判断通信元是否与处理函数相绑定，是否处于发送或接收等待状态，是否已经超时，并对各种状态进行相应处理，最后将无效的通讯元清除。如此循环往复。

3 串口通讯新模块的设计

3.1 多串口通信结构

为安徽某公司设计的工业造气炉监控组态软件，是基于多串口的通信结构。上位机通过扩展配备多个串口与多台下位机通信。每台下位机负责采集或控制其监控对象的运行状态。一方面上位机通过串口向多台下位机发送控制命令，另一方面多台下位机通过串口向上位机发送状态信息。应用程序中采用了通讯元串口通信模块。

图3 多串口通信模型

多串口通信面临的最主要问题就是并发处理问题。上位机是单一串口，通过多串口扩展器与多台下位机连接。上位机有可能同时向多台下位机发出控制命令，多台下位机也有可能同时向上位机发送反馈信息。这样使得程序设计变得很复杂，一旦程序设计的逻辑考虑不够全面，就很有可能造成信息混乱。而基于IOCP的通信元模型的就很好的解决了这个问题。无论是上位机发送控制命令，还是下位机发送反馈信息，都将在程序中生成一个通信元，每个通信元里面都记录着对应下位机的信息，这样就确保了上位机能够准确的发送和接收到指定下位机的信息，提高了通信的准确率。

3.2 程序设计流程

图4 程序流程图

系统由一个主线程和指定数目的工作者线程组成。主线程主要完成的工作是：通信模块的初始化，通信元队列的创建，工作者线程的创建，串口操作的获取，通信元的入队以及程序退出时资源的释放。通信元产生时要先标记自身的状态。状态包括下位机的ID号，该通信元是发送信息通信元或者是接收信息通信元。同时，程序还要初始化通信元的数据容量，将要发送或接收的数据装入通信元中。最后标记通信元的超时处理方式，包括上位机重新发送，下位机重新发送以及不做任何处理。重新发送也包括重新发送一次或者重新发送直到发送成功。

工作者线程的作用是实现异步操作。主要完成的工作：从通信元队列中取出通信元，首先判断通信元是否处于超时状态，在不处于超时状态的情况下，解析通信元的当前状态，并对各种状态进行相应处理，最后将无效的通讯元清除。工作者线程是多线程并行工作的。程序先扫描线程池中线程的状态，取出一条空闲的线程。空闲线程从通信元队列中取出第一个通信元进行解析。在解析通信元状态时，上位机将首先获取该通信元所对应的下位机信息，以保证上位机能够准确的与对应的下位机通信。当通信元状态为发送状态时，程序先判断串口缓冲区是否为空，当串口缓冲区为空时执行该通信元。当通信元状态为接收通信元时，当前线程会先挂起，等待该通信元所指定的下位机发送信息。当通信元状态为处理状态时，程序将调用解析函数来得到通信元中的数据。当通信元被标记为无效时，程序将删掉该通信元。

3.3 实验仿真

表1 模型的开销对比

由于受到串口等硬件条件的限制，所做的实验是通过串口仿真软件来完成的。主机配置是CPU：AMD Athlon Dual-Core M320 2.10GHz， RAM 3.00GB，在串口仿真软件中设置虚拟串口的数目。实验模拟向每个串口发起连接，并完成一次收发工作。

实验结果表明：基于通信元新模型的服务端在接收相同连接数时所消耗的时间比传统模型要少，随着连接数的增多，优势更加明显。主要原因通信元模型使用很少的线程，而传统模型每个连接都要创建一个线程。CPU没有在多线程中频繁的切换，因此CPU资源开销很少，系统执行速度就快了很多。但可以看到基于通信元新模型的服务端在内存开销上比传统模型要大。这是因为通信元队列中每个通信元都要开辟一块内存空间来存储数据，当通讯量很大时，内存的占用量就会很高。但是对于上位机来说，增加内存是非常方便的事情。通过消耗更多的内存来提高系统通信的速度，这种方式是值得的。所以新模型更加适合实现大规模的串口通信。

表2 模型的准确率对比

主要原因是因为在通信元模型中，每个通信元都与唯一的下位机相绑定，保证了CPU通信时都能找到对应的下位机。这样，尽管下位机的数量多，但对于上位机而言，一个CPU每次只处理与一个下位机之间的通信，这样就保证了数据通信的准确率。另外，在传统模型的串口通信中，如果串口数量过多，很容易造成数据传输超时。大量的数据堵塞在串口两端，影响了整个系统的正常执行。而通信元模型的超时率就很低，因为每个通信元中都绑定了超时处理方式，一旦发生串口数据堵塞时，程序将立刻执行通信元中的超时处理函数，从而避免了数据堵塞现象。当数据量巨大时，这种通信元超时处理的方式就更加明显。

目前固定床间歇式造气炉在我国中小型氮肥企业运用广泛，其控制主要采用集散控制系统。而以PC机为基础的集散控制系统，上位机监控软件是实现其控制任务的核心。该文讨论开发的造气炉节能监控组态软件吸收了组态的思想，包含两个部分，一个是组态部分，一个是运行部分。组态部分是一个应用开发集成环境，用于建立监控界面，配置相关参数，并自动生成说明书供工程技术人员查阅。运行部分是一个实时运行环境，用来运行组态文件，监控造气炉工作。该软件既吸收了组态软件的精华——开发效率高、成熟稳定、易于维护，又针对造气炉这个特定行业，功能纯粹、成本低廉，适合中小型企业应用实施，具有较高的工程意义和市场价值。

4 结论

IOCP思想既可以用于Socket套接字网络通信，也可以用于多串口的网络通信。基于IOCP思想设计的通讯元新模型是一种能

够合理的利用和管理多线程的机制，该模型能够有效管理多串口通信的线程，增强了程序的可移植性，提高了系统的工作效率。在为安徽某公司设计的工业造气炉监控组态软件，采用了该基于IOCP核心思想的通讯元新模型，经过压力测试，实现了2000人同时在线的项目需求。实际运行表明该模型具有简单的接口和稳定、高效的运行机制。

参考文献：

[1] Richter J. Advanced Windows （3rd edition） [M]. USA： Microsoft Press，1997.

[2] Beveridge J， Wiener R. Multithreading Applications in Win32： The Complete Guide to Threads （Addison-Wesley Microsoft Technology Series） [M]. USA： Addson-Wesley Professional，1996.

[3] Jones A， Ohlund J. Network Programming for Microsoft Windows （2nd edition） [M]. USA： Microsoft Press， 2002.

[4] Jones A， Deshpande A. Windows Sockets 2.0： Write Scalable Winsock Apps Using Completion Ports [J]. MSDN Magazine， Microsoft Press， October 2000：30-35.

[5] Asche R. Writing Windows NT Server Applications in MFC Using I/O Completion Ports [J].MSDN Magazine， Microsoft Press， September 1996：25-30.

[6] Atanasova M， Cleeton L， Mike Flasko. Get Connected With The .Net Framework 3.5[J].MSDN Magazine， Microsoft Press， September 2007：42-49.

[7] Lee H， Park T. Design and Implementation of an Online 3D Game Engine [J]. Lecture Notes in Computer Science， Springer Berlin / Heidelberg， 2004：837-842.

[8] Kim G B. A method of generating massive virtual clients and model-based performance test [J]. Fifth International Conference on Quality Software， 2005：250-254.