- 1. 范围
- 2. 客户机/服务器模型
- 3. 规范性引用文件
- 4. 协议描述
- 5. 总体通信结构
- 6. TCP/IP上的MODBUS应用data单元
- 7. MBAPmessage头描述
- 8. MODBUSfunction code描述
- 9. TCPconnect管理
- 10. connect管理模块
- 11. Operation模式对TCPconnect的影响
- 12. 访问控制模块
- 13. TCP/IP栈的使用
- 14. BSD套接字接口的应用
- 15. TCP层参数配置
- 16. IP层的参数配置
- 17. 通信应用层
- 18. MODBUS客户端
- 19. MODBUS服务器端
- 20. 对象模型示意图
- 21. TCP管理程序包
- 22. 通信层程序包
- 23. 接口类
- 24. 通信实现的类的示意图
- 25. Sequence图
- 26. 类和方法的描述
- 27. MODBUS服务器端的类
- 28. MODBUS客户机类
- 29. 接口的类
- 30. connect管理类
- 31. Modbus协议在TCP／IP上的实现指南
引言
范围
这个文件的范围是介绍TCP/IP上的MODBUSmessage传输服务，提供参考信息以帮助软件developer使用这种服务。这个文中不包括MODBUSfunction code的Coding内容，这些信息请参阅MODBUS协议规范[2]。
这个文件准确而全面地描述了MODBUSmessage传输服务的实现。其目的是便于在那些使用MODBUSmessage传输服务equipment之间进行可互Operation。
这个文件主要由三部分组成：
- 在TCP/IP上的MODBUS协议概述
- MODBUS客户机、服务器和网关Tools的Function描述
- 针对一个MODBUS实现实例的目标模型建议的实现准则。
客户机/服务器模型
MODBUSmessage传输服务提供设备之间的客户机/服务器通信，这些设备联接在一个Ethernet（以太网） TCP/IP网络上。
这个客户机/服务器模式是基于4种Typemessage：
- MODBUS Request
- MODBUS 证实
- MODBUS 指示
- MODBUS Response
MODBUSRequest是客户机在网络上send用来启动事务处理的message
MODBUS指示是服务端receive的Requestmessage
MODBUSResponse是服务器send的Response信息
MODBUS证实是在客户端receive的Response信息
MODBUSmessage传输服务（客户机/服务器模型）用于实时信息交换：
- 在两A device应用程序之间
- 在设备应用和其它设备之间
- 在HMI/SCADA应用程序和设备之间
- 在一个PC和一个提供在线服务equipment程序之间
规范性引用文件
这章给出了在这个文件之前喜欢阅读的文件列表：
[2] MODBUS协议规范
[4] RFC1122
缩略语
ADU — 应用data单元
IETF — 因特网工程工作组
IP — 互连网协议
MAC — 介质访问控制
MB — MODBUS
MBAP — MODBUS协议
PDU — 协议data单元
PLC — 可编程序逻辑控制器
TCP — 传输控制协议
BSD — 伯克利软件分配
MSL — 最大段寿命
背景概要
协议描述
总体通信结构
MODBUS TCP/IP的通信system可以包括不同Typeequipment：
- connect至TCP/IP网络的MODBUS TCP/IP客户机和服务器设备
- 互连设备，例如：在TCP/IP网络和串行链路子网之间互连的网桥、路由器或网关，联接，该子网允许将MODBUS串行链路客户机和服务器终端设备connect起来。
图1：MODBUS TCP/IP通信结构
MODBUS协议定义了一个与基础通信层无关的简单协议data单元（PDU）。特定总线或网络上的MODBUS协议映射能够在应用data单元（ADU）上引入一些附加域。
图2：通用MODBUS帧
启动MODBUS事务处理的客户机建立MODBUS应用data单元。这个function code向服务器指示执行执行哪种Operation。
TCP/IP上的MODBUS应用data单元
这节描述了MODBUS TCP/IP网络中进行的MODBUSRequest或Response的封装。
图3：TCP/IP上的MODBUS的Request/Response
在TCP/IP上使用一种专用message头识别MODBUS应用data单元。将这种message头称为MBAPmessage头（MODBUS协议message头）。
这种message头提供一些与串行链路上使用的MODBUS RTU应用data单元比较的差别：
- 用MBAPmessage头中的单个byteUnit identifier取代MODBUS串行链路上通常使用的MODBUS从address域。这个Unit identifier用于设备的通信，这些设备使用单个IPaddress支持多个独立MODBUS终端单元，例如：网桥、路由器和网关。
- 用receive者可以验证Completemessage的方式设计所有MODBUSRequest和Response。对于MODBUS PDU有固定Length的function code来说，仅function code就足够了。对于在Request或Response中携带一个可变data的function code来说，data域包括byte count。
- 当在TCP上携带MODBUS时，即使将message分成多个信息包来传输，办事在MBAPmessage头上携带附加Length信息，以便receive者能识别message边界。显式和隐式LengthRules的existence以及CRC-32差错校验码的使用（在以太网上）将对Request或Responsemessage产生极小的未检出干扰。
MBAPmessage头描述
MBAPmessage头包括下列域：
| 域 | Length | 描述 | 客户机 | 服务器 |
| 事务元标识符 | 2个byte | MODBUSRequest/Response事务处理的识别码 | 客户机启动 | 服务器从receive的Request中重新Copy |
| Protocol Identifier | 2个byte | 0=MODBUS协议 | 客户机启动 | 服务器从receive的Request中重新Copy |
| Length | 2个byte | 以下byte的quantity | 客户机启动（Request） | 服务器（Response）启动 |
| Unit identifier | 1个byte | 串行链路或其它总线上connect的远程从站的识别码 | 客户机启动 | 服务器从receive的Request中重新Copy |
message头为7个byte长：
事务处理标识符：用于事务处理配对。在Response中，MODBUS服务器CopyRequest的事务处理标识符。
Protocol Identifier：用于system内的多路复用。通过值0识别MODBUS协议。
Length：Length域是下一个域的byte count，包括Unit identifier和data域。
Unit identifier：为了system内路由，使用这个域。专门用于通过以太网TCP-IP网络和MODBUS串行链路之间的网关对MODBUS或MODBUS+串行链路从站的通信。MODBUS客户机在Request中设置这个域，在Response中服务器必须利用相同的值返回这个域。
在Register的502端口上利用TCPsend所有MODBUS/TCP ADU。
注：用Big-endianCoding不同域。
MODBUSfunction code描述
在MODBUS协议规范[2]中详细说明了MODBUSapplication layer protocol上使用的标准function code。
Function描述
这里提供的MODBUS组件结构是一个既包含MODBUS客户机又包含MODBUS服务器组件的通用模型，适用于任何设备。
有些设备可能仅提供服务器或客户机组件。
本章的第一部分，给出一个有关MODBUSmessage传输服务组件结构的简要概述，然后，给出结构模型内部每一个组件的描述。
MODBUS组件结构模型
图4 MODBUSmessage传输服务概念结构
- 通信应用层
一个MODBUS设备可以提供一个客户机和/或服务器MODBUS接口。
可提供一个MODBUS后台接口，允许间接的访问用户应用对象。
此接口由四部分组成：离散量输入、离散量输出（线圈）、register输入和register输出。此接口与用户应用data之间的映射必须加以定义（本地问题）。
| 基本data表 | 对象Type | 属性 | 说明 |
| 离散量输入 | 1位 | 只读 | 此类data可来自I/Osystem |
| 线圈 | 1位 | 读-写 | 此类data可被应用程序修改 |
| register输入 | 16位字 | 只读 | 此类data可来自I/Osystem |
| register输出 | 16位字 | 只写 | 此类data可被应用程序修改 |
- MODBUS客户机
MODBUS客户机允许用户应用清晰地控制与远端设备的信息交换。MODBUS客户机根据用户应用向MODBUS客户接口send的需求中所包含的参数生成一个MODBUSRequest。
MODBUS客户机调用一个MODBUS的事务处理，事务处理管理包括MODBUS证实的等待和处理。
- MODBUS客户机接口
MODBUS客户机接口提供一个接口，使得用户应用能够生成对包括访问MODBUS应用对象在内的各类MODBUS服务的Request。尽管在实现模型中以实例说明，但是MODBUS客户机接口（API）在这里不进行描述。
- MODBUS服务器
在收到一个MODBUSRequest以后，模块激活一个本地Operation进行读、写、或Complete其他Operation。这些Operation的处理对应用程序开发人员来说都是透明的。MODBUS服务器的主要Function是等待来自TCP502口的MODBUSRequest，处理这一Request，然后生成一个MODBUS应答，应答取决于设备状况（场境）。
- MODBUS后台接口
MODBUS后台接口是一个从MODBUS服务器到定义应用对象的用户应用之间的接口。
- TCP管理层
message传输服务的主要Function之一是管理通信的建立和End，管理建立在TCPconnect上的data流。
- connect管理
在客户机和服务器的MODBUS模块之间的通信需要调用TCPconnect管理模块。它负责全面管理message传输TCPconnect。
connect管理中existence两种可能：用户应用自身管理TCPconnect，或All由这个模块进行connect管理，而对用户应用透明。后一种方案灵活性较差。
TCP 502口的侦听是为MODBUS通信保留的。在缺省状态下，强制侦听这个口。然而，有些市场或应用可能需要其他口作为TCP上MODBUS的通信之用。当需要与非施奈德（Schneider）产品进行互Operation时，就属于这种情况，例如：在建筑控制中。为此，强烈建议：客户机和服务器均应向用户提供对TCP口号上的MODBUS参数进行配置的可能性。重要的是：即使在某一个特定的应用中为MODBUS服务配置了其他TCP服务器口，除一些特定应用口外，TCP服务器502口必须仍然是可用的。
- 访问控制模块
在某些至关重要的场合，必须禁止不需要的主机对设备内部data的访问。这既是为什么需要安全模式，也是在需要时实现安全处理的原因。
- TCP/IP栈层
TCP/IP的栈可以进行参数配置，以便于使得data流控制、address管理和connect管理适应于特定的产品或system的不同的约束。一般说来，BSD套接字接口就用来管理TCPconnect。
- 资源管理和data流控制
为了平衡MODBUS客户机与服务器之间进出message传输的data流，在MODBUSmessage传输栈的所有各层均设置了data流控制机制。资源管理和data流控制模块首先是基于TCP内部data流控制，附加data链路层的某些data流控制，以及用户应用层的data流控制。
TCPconnect管理
connect管理模块
总体描述
MODBUS通信需要建立客户机与服务器之间的TCPconnect。
connect的建立可以由用户应用模块直接实现，也可以由TCPconnect管理模块自动Complete。
在第一种情况下，用户应用模块必须提供应用程序接口，以便完全管理connect。这种方式为应用开发人员提供了灵活性，但需要TCP/IP机制方面的专长。
在第二种方案中，TCPconnect管理完全不出现，用户应用仅需要send和接受MODBUSmessage。TCPconnect管理模块负责在需要时建立新的TCPconnect。
TCP客户机和服务器connectquantity的定义不属于本文件的范畴（在本文中采用n）。根据设备能力，TCPconnect的quantity会不同。
实现Rules：
- 如果没有明确的用户需求，建议采用自动的TCPconnect管理
- 建议：打开并保持与远端设备的connect，而不要在每次MODBUS/TCP事务处理时打开和Closeconnect。注：然而，MODBUS客户必须能够receive来自服务器的CloseRequest，并Closeconnect。当需要时，connect可以被重新打开。
- 建议：每一个MODBUS客户至少要打开与远端MODBUS服务器的TCPconnect（同一IPaddress）。一个应用建立一个connect是好的选择。
- 几个MODBUS事务处理可以在同一个TCPconnect上被同时激活注：如果以此方式，MODBUS事务处理标识必须被用来唯一地识别Request与Response的匹配。
- 在两个远端MODBUS设备（一个客户机和一个服务器）之间双向通信的情况下，有必要为客户机data流和服务器data流分别建立connect。
- 一个TCP帧只能传送一个MODBUS ADU。建议：不要在同一个TCP PDU中send多个Request或应答。
图7：TCPconnect管理Operation图
1． 显式TCPconnect管理
用户应用模块负责管理所有的TCPconnect：主动的和被动的connect建立、connectEnd………。对客户机与服务器间所有的connect进行这种管理。BSD套接字接口用在用户应用模块中来管理TCPconnect。这种方案提供了完全的灵活性，但也意味着应用开发人员要具备充分的有关TCP的知识。
考虑到设备的能力和需求，必须进行配置客户机与服务器间connect数的限制。
2． 自动TCPconnect管理
TCPconnect管理对用户应用模块是完全透明的。connect管理模块可以接受足够quantity的客户机/服务器connect。否则，在超过所授权quantity的connect时必须有一种实现机制。在这种情况下，我们建议：Close最早建立的不使用的connect。
在收到第一个来自远端客户机或本地用户应用的data包后，就建立了与远端对象的connect。如果一个网络进行终止或本地设备决定终止，此connect将被Close。在receiveconnectRequest时，访问控制选项可用来禁止未授权客户访问设备的可能性。
TCPconnect管理模块采用栈接口（通常BSD套接字接口）来与TCP/IP栈进行通信。
为了保持system需求与服务器资源之间的兼容，TCP管理将保持两个connect库。
- 第一个库（优先connect库）由那些从不被本地主动Close的connect组成。必须提供一个配置来建立这个库。实现的原理是将这个库的每一个可能的connect与一个特定的IPaddress联系起来。具有这个IPaddressequipment被称为“标记的”。任何一个被“标记的”设备的新的connectRequest必须被receive，并从优先connect库中取出。还有必要设置允许每个远端设备最多建立connect的quantity，以避免同一设备使用优先connect库中所有的connect。
- 第二个库（非优先connect库）包括了非标记设备的connect。这里采用的Rules是：当有来自非标记设备的新的connectRequest，以及库中没有connect可用时，Close早些时候建立的connect。
一个配置可作为选项提供来分配每个库中可用connect的quantity。然而（非强制性的），如果需要，设计人员可在设计期间设定connect的quantity。
connect管理描述
- connect建立
MODBUSmessage传输服务必须在502口上提供一个侦听套接字，允许receive新的connect和与其他设备交换data。
当message传输服务需要与远端服务器交换data时，它必须与远端502口建立一个新的客户connect，以便与远距离交换data。本地口必须高于1024，并且每个客户connect各不相同。
图8：MODBUS TCP/IPconnect建立
如果客户机与服务器的connectquantity大于授权的connectquantity，则最早建立的无用的connect被Close。激活访问控制机制检查远端客户机的IPaddress是否是经过授权的。如果未经授权，将拒绝新的connect。
- MODBUSdata变换
基于已经打开的正确的TCPconnectsendMODBUSRequest。远端设备的IPaddress用于寻找所建的TCPconnect。在与同一个远端设备建立多个connect时，必须选择其中一个connect用于sendMODBUSmessage，可以采取不同的选择策略，例如：最早的connect、第一个connect。在MODBUS通信的全过程中，connect必须始终保持打开。如同下列各章所描述的一样，一个客户机可以向一个服务器启动多个事务处理，而不必等待前序事物处理End。
- connectClose
当客户机与服务器间的MODBUS通信End时，客户机必须Close用于通信的connect。
Operation模式对TCPconnect的影响
某些Operation模式（两Operation端点之间通信断开、一个端点的故障和重新启动、………）会对TCPconnect产生影响。一个connect可被视为在这一侧Close或异常终止而没有另一侧的Confirm，称这种connect为“半打开”的connect。
本章描述每种主要Operation模式的特性。假设在connect的两端采用了“ 保持connect ”TCP机制。
两Operation端之间通信断开
通信断开的原因可以是服务器侧以太网connect电缆断开。预期的特性是：
- 如果在connect上没有正在senddata包：
如果通信断开持续的time短于“保持connect”计时器的值，将察觉不到通信断开。如果通信断开time超过“保持connect”计时器的值，将一个Error返回到TCPconnect层，由其复位connect。
- 如果在connect断开的前后send一些data包：
TCP重新传输算法（Jacobson算法、Karn算法以及指数补偿算法）被激活。这可能导致在“保持connect”计时器终止之前TCP栈connect层复位。
服务器端的故障和重新启动
在服务器故障和重新启动以后，客户端处于“半打开”connect状态。预期的特性是：
- 如果在半打开的connect上没有senddata包：
只要“保持connect”计时器还在计时中，从客户端看，connect是半打开的。之后，将返回一个Error到TCP管理层，由其复位connect。
- 如果在半打开的connect上send一些data包：
服务器在does not exist的connect上receivedata。TCP层的栈send一个复位指令来Close客户端的半打开的connect。
客户机端的故障和重新启动
在客户机故障和重新启动以后，服务器侧处于“半打开”connect状态。预期的的状态是：
- 如果在半打开的connect上没有senddata包：
只要“保持connect”计时器还在计时中，从服务器端看，这种connect是半打开的。之后，将返回一个Error到TCP管理层，由其复位connect。
- 如果在“保持connect”计时器Complete计时前，客户机打开一个新的connect：
必须分两种情况研究：
- 所打开的connect与服务器侧半打开的connect具有相同的特性（相同的源和目的口、相同的源和目的IPaddress），所以，在connect建立超时后（伯克利实现的多数情况下为75ms），TCP栈层将不能打开connect。为了避免较长超时time内不能进行通信，建议：在客户机端重新启动后，确保使用与原有connect不同的源口号建立connect。
- 所打开的connect与服务器侧半打开的connect具有不同的特性（不同的源口和相同的目的口、相同的源和目的IPaddress），所以，在TCP栈层上打开connect，并向服务器侧的TCP管理层send信号。
如果服务器侧TCP管理层仅支持一个远端客户机IPaddress的connect，那么可以Close原来的半打开的connect，使用新的connect。
如果服务器侧TCP管理层支持多个远端客户机IPaddress的connect，那么新的connect保持打开状态，原来的connect也保持半打开状态，直到“保持connect”计时器计时End，此时，将返回一个Error到TCP管理层。之后，TCP管理层将能够复位原有的connect。
访问控制模块
这个模块的目的是检查每一个新的connect，对照一个合法授权的远程IPaddress列表，它可以授权或禁止一个远端客户机的TCPconnect。
在至关重要的场合，应用开发人员需要选择访问控制模块来保证网络的访问。在这种情况下，需要对每个远端IP授权或禁止访问。用户需提供一个IPaddress的列表，并特别注明每个IPaddress是否合法授权。在缺省情况下，在安全模式中，用户未配置的IPaddress均被禁止。所以，借助于访问控制模式，Close来自Unknown的IPaddress的访问connect。
TCP/IP栈的使用
TCP/IP栈提供了一个接口，用来管理connect、send和receivedata，还可以进行参数配置，以使得栈的特性适应于设备或system的限制。
本章的目的是给出有关栈接口的综述，以及一些与栈的参数配置有关的信息。总揽综述主要是MODBUSmessage传输所使用的一些特性。
对于More的信息，建议阅读RFC 1122，这个RFC 1122为厂商和开发商提供了互联网通信软件的指南。RFC 1122详述了一个connect到互联网的主机必须采用的标准协议，以及一组明确的需求和选项。
栈接口一般是基于本文件中描述的BSD（伯克利软件分配代码）接口。
BSD套接字接口的应用
注：有些TCP/IP栈从性能考虑提出其他Type的接口。MODBUS客户机或服务器可以使用这些特定的接口，但是在本文件中对这种使用不做描述。
一个套接字是一个通信端点，它是通信中的基本构成块。通过套接字send和receivedata可以执行一个MODBUS通信。TCO/IP库仅提供了使用TCP和提供基于connect的通信服务的流套接字。
socket()函数用来创建套接字。返回的一个套接字号被创建者用来访问套接字。套接字创建时没有address（IPaddress和口号）。直到一个口被绑定到该套接字时，方可receivedata。
bind()函数用来绑定一个口号到套接字。bind()函数在套接字与所指定的口号之间建立一个connect。
为了初始化一个connect，客户端必须sendconnect()函数来指定套接字号、远端IPaddress和远端侦听口号（主动connect建立）。
为了Completeconnect，服务器端必须sendaccept()函数指定以前在listen()调用中所指定的套接字号（被动connect建立）。一个新的套接字被创建，并具有与最初相同的特性。这个新的套接字connect到客户机的套接字，而将套接字号返回到服务器端。于是，释放初始套接字，以便为其他欲与服务器connect的客户机使用。
在TCPconnect建立以后，data即可被传递。将Send()和recv()函数专门地设计成与已经connect的套接字一道使用。
setsockopt()函数允许套接字的创建者用套接字建立若干选项。这些选项描述了套接字的Operation特征。
select()函数允许编程人员测试所有套接字上的事件。
shutdown()函数允许套接字的使用者来终止send()和/或recv()。
一旦不再需要套接字，可以使用close()函数来放弃套接字的描述信息。
图9：MODBUS信息交换
上图给出了客户机与服务器间的完整的MODBUS通信过程。客户机建立一个connect，向服务器send3个MODBUSRequest，而不等待第一个Request的应答到来。在收到所有的应答后，客户机正常地Closeconnect。
TCP层参数配置
可以调整TCP/IP栈的一些参数以使得其特性满足产品或system的限制。TCP层的下列参数可以进行调整：
- 每个connect的参数
SO-RCVBUF, SO-SNDBUF:
这些参数允许为send和receive用套接字接口设定高限位。可以通过调整这些参数来实现流量控制管理。receive缓存区的的大小即为每个connectadvertised window的maximum。为了提高性能，必须增加套接字缓存区的大小。否则，这些值必须小于内部驱动器的资源，以便在内部驱动器的资源耗尽之前CloseTCP窗口。
receive缓存区大小取决于TCP窗口大小、TCP最大段的大小和receive输入帧所需的time。由于最大段的尺寸为300个字（一个MODBUSRequest需要最大256字+MBAPmessage头）,如果需要3帧进行缓存，可将套接字缓存区大小调整为900字。为了满足最大的缓存需求和预定的time，可以增加TCP窗口的大小。
TCP-NODELAY:
通常，小message（称为：tinygrams）在局域网（LAN）上的传输不会产生问题，因为多数局域网是不拥堵的，但是，这些tinygrams在广域网上将会造成拥堵。一个称为“NAGLE算法”的简单方案是：收集小量的data，当前面message的TCPConfirm到达时再用单个进行send。
为了获得更好的实时特性，建议：将小量的data直接send，而不要试图将其收集到一个段内再send。这就是为什么建议强制TCP-NODELAY选项，这个选项禁用客户机和服务器connect的“NAGLE算法”。
SO-REUSEADDR:
当MODBUS服务器Close一个由远端客户启动的TCPconnect时，在这个connect处于“time等待”状态（两个MSL：最大段寿命）的过程中，该connect所用的本地口号不能被再次用来打开一个新的connect。
建议：为每个客户机和服务器connect，指明SO-REUSEADDR选项，以迂回这个限制。此选项允许为自身分配一个口号，它作为connect的一部分在2MSL期间内等待客户机并侦听套接字接口。
SO-KEEPALIVE:
TCP/IP协议缺省状态下，不通过空闲的TCPconnectsenddata。因此，如果在TCPconnect端这个过程没有senddata，在两个TCP模块间就没有交换任何data。这就假设客户机端应用和服务器端应用均采用计数器来探测connect的存活性，以便Closeconnect。
建议：在客户机与服务器connect两端均采用KEEPALIVE选项，以便查询另一端得知对方是否故障并死机，或故障并重新启动。
然而，我们必须牢记，采用KEEPALIVE可能引起一个非常良好的connect，在瞬间故障时通信中断，如果保持connect计时器计时周期太短，将占用不必要的网络带宽。
- 整个TCP层的参数
TCPconnect建立超时:
多数伯克利推出的system将新connect建立的时限设定为75秒，这个缺省值应该适应于实时的应用限制。
保持connect参数:
connect的缺省空闲time是2小时。超过此空闲time将触发一个保持connect试探过程。第一个保持connect试探后，在最大次数内每隔75秒send一个试探，直到收到对试探的应答为止。
在一个空闲connect上发出保持connect试探的最大数是8次。如果发出最大试探次数之后而没有收到应答，TCP向应用发出一个Error信号，由应用来决定Closeconnect。
超时与重发参数:
如果检测到一个TCPmessage丢失，将重发此message。检测丢失的方法之一是管理重发超时（RTO），如果没有收到来自远端的Confirm，超时终止。
TCP进行RTO的动态评估。为此，在send每个非重发的message后测量往返time(RTT)。往返time（RTT）是指message到达远端设备并从远端设备获得一个Confirm所用的time。一个connect的往返time是动态计算的，然而，如果TCP不能在3秒钟内获得RTT的估计，那么，就设定RTT的缺省值为3秒。
如果已经估算出RTO，它将被用于下一个message的send。如果在估算的RTO终止之前没有收到下一个message的Confirm，Enable指数补偿算法。在一个特定的time段内，允许相同message最大次数的重发。之后，如果收不到Confirm，connect终止。
可以对某些栈设置connect终止之前重发的最大次数和重发的最长time。
在TCP标准中定义了一些重发算法：
- Jacobson RTO估计算法用来估计重发超时(RTO)；
- Karn算法指出，在重发段，不应进行RTO估计；
- 指数补偿算法定义：对于64秒time上限内每一次重发，加倍重发超时；
- 快速重发算法允许在收到3个重复Confirm之后进行重发。考虑这个算法是因为：在LAN上，可能会导致message丢失的检测快于等待RTO终止的检测。
在MODBUS实现中，Recommended for use这些算法。
IP层的参数配置
IP参数
下列参数必须在MODBUS实现的IP层进行配置：
- 本地IPaddress：IPaddress可以是A、B或C类的一种。
- 子网掩码：可基于各种原因，将IP网络划分成子网：使用不同的物理介质（例如：以太网、广域网等）、更effective的使用网络address、以及控制网络流量的能力。子网掩码必须与本地IPaddress的Type相一致。
- 缺省网关：缺省网关的IPaddress必须与本地IPaddress在同一子网内。禁止使用0.0.0.0的值。如果没有定义网关，那么此值可设为127.0.0.1或本地IPaddress。
注：MODBUS报文传输服务在IP层上不要求段Function。
应该利用本地IPaddress、子网掩码和省缺网关（不同于0.0.0.0）配置本地IP端。
通信应用层
MODBUS客户端
图10：MODBUS客户端
MODBUS客户端设计
MODBUS/TCP协议使得能够对一个客户端进行简单的设计。下图描述了客户端sendMODBUSRequest并处理MODBUS应答的主要处理过程。
图11：MODBUS客户端Operation示意图
一个MODBUS客户机可以receive三类事件：
- 一个来自用户应用的sendRequest的新需求，在这种情况下，必须对MODBUSRequest进行Coding，并使用TCP管理组件服务通过网络进行sendMODBUSRequest。下层（TCP管理模块）会返回一个Error信息，这些Error信息是由于TCPconnectError或其他Error信息所导致的。
- 来自TCP管理的一个Response，在这种情况下，客户端必须分析Response的内容，并向用户应用send一个证实。
- 由于无Response而超时End。可以通过网络send一个重试电文，或向用户应用send一个否定证实。
注：这些重试是由MODBUS客户机启动的，可以在无TCPConfirm的情况下由TCP层来进行其它Type的重试。
MODBUSRequest的生成
在收到来自用户应用的需求后，客户端必须生成一个MODBUSRequest，并send到TCP管理。
可以将生成MODBUSRequest分解成为几个子任务：
- MODBUS事务处理的实例化，使客户机能够存储所有需要的信息，以便将Response与相应的Request匹配，并向用户应用send证实。
- MODBUSRequest（PDU+MPABmessage头）的Coding。启动需求的用户应用必须提供所有需要的信息，使得客户机能够将RequestCoding。根据MODBUS协议进行MODBUS PDU的Coding（MODBUSfunction code、Related参数和应用data[2]）。填充MBAPmessage头的所有域。然后，将MBAPmessage头作为PDU前缀，生成MODBUSRequestADU。
- sendMODBUSRequestADU到TCP管理模块，TCP管理模块负责对远端服务器寻找正确TCP的套接字。除了MODBUS ADU以外，还必须传递目的IPaddress。
下图比图17更深入地描述了Request生成的过程。
图12：Request生成Operation示意图
下面给出了实例：从address为05的远端服务器读1个字的MODBUSRequestADUCoding
- MODBUSRequestADUCoding：
| 说明 | 大小 | 实例 | |
| MBAPmessage头 | 事务处理标识符Hi | 1 | 0x15 |
| 事务处理标识符Lo | 1 | 0x01 | |
| Protocol Identifier | 2 | 0x0000 | |
| Length | 2 | 0x0006 | |
| Unit identifier | 1 | 0xFF | |
| MODBUSRequest | function code（*） | 1 | 0x03 |
| starting address | 2 | 0x0005 | |
| number of registers | 2 | 0x0001 |
（*）参见MODBUS协议规范[2]
- 事务处理标识符
事务处理标识符用于将Request与未来Response之间建立联系。因此，对TCPconnect来说，在同一时刻，这个标识符必须是唯一的。有几种使用此标识符的方式：
- 例如：可以作为一个带有计数器的简单“TCP顺Serial number”，在每一个Request时增加计数器；
- 也可以用作智能索引或指针，来识别事务处理的内容，以便记忆当前的远端服务器和未处理的Request。
通常，在MODBUS串行链路上，客户机必须一次send一个Request。这意味着这个客户机在send第二个Request之前必须等待对第一个Request的回答。在MODBUS TCP上，可以向同一个服务器send多个Request而不需等待服务器的证实。MODBUS/TCP到MODBUS串行链路之间的网关负责保证这两种Operation之间的兼容性。
服务器收接受的Requestquantity取决于其容量，即：服务器资源量和TCP窗口尺寸。同样，客户机同时启动事务处理的quantity也取决于客户机的资源容量。这个实现参数称为“NnmberMaxofClientTransaction”，必须作为MODBUS客户机的一个特性进行描述。根据设备的Type，此参数取值为1～16。
- Unit identifier
在MODBUS或MODBUS+串行链路子网中对设备进行寻址时，这个域是用于路由的目的。在这种情况下，“Unit Identifier”携带一个远端设备的MODBUSslave address：
– 如果MODBUS服务器connect到MODBUS+或MODBUS串行链路子网，并通过一个桥或网关配置address这个服务器，MODBUSUnit identifier对识别connect到网桥或网关后的子网的从站设备是必需的。目的IPaddress识别了网桥本身的address，而网桥则使用MODBUSUnit identifier将Request转交给正确的从站设备。
– 分配串行链路上MODBUS从站Device address为1～247（decimal），address0作为广播address。
对TCP/IP来说，利用IPaddress寻址MODBUS服务器；因此，MODBUSUnit identifier是无用的。必需使用值0xFF。
– 当对直接connect到TCP/IP网络上的MODBUS服务器寻址时，建议不要在“Unit identifier”域使用effective的MODBUSslave address。在一个自动system中重新分配IPaddress的情况下，并且如果以前分配给MODBUS服务器的IPaddress又被指配给网关，使用一个effective的slave address可能会由于网关的路由不畅而引起麻烦。使用Invalid的slave address，网关仅是简单地废弃MODBUD PDU，而不会有任何问题。建议：在采用0xFF作为“Unit identifier”的Invalid值。
注：0也可以用作与MODBUS/TCP设备直接通信。
处理MODBUS证实
在TCPconnect中，当收到一个Response帧时，位于MBAPmessage头中的事务处理标识符用来将Response与先前发往TCPconnect的原始Request联系起来：
- 如果事务处理标识符没有提及任何未解决的事务处理，那么必须废弃Response；
- 如果事务处理标识符提及了未解决的事务处理，那么必须分解Response，以便向用户应用sendMODBUS证实（肯定的或否定的证实）；
分解Response就是检验MBAPmessage头和MODBUS PDU的Response：
- MBAPmessage头
在检验Protocol Identifier必为0x0000以后，Length给出了MODBUSResponse的大小。
如果Response来自直接connect到TCP/IP网络的MODBUS服务器设备，TCPconnect识别码足以清晰地识别出远端服务器。因此，MBAP Head中携带的Unit identifier是Invalid的，必须废弃这个Unit identifier。
如果将远端服务器connect在一个串行链路子网上，并且Response来自一个网桥、路由或网关，那么Unit identifier（值≠0xFF）识别send初始Response的远端MODBUS服务器。
- MODBUSResponsePDU
必须检验function code，根据MODBUS协议，分析MODBUS的Responseformat：
- 如果function code与Request中所用的function code相同，并且如果Response的format是正确的，那么，向用户应用发出MODBUSResponse作为肯定的证实。
- 如果function code是一个MODBUSException Code（function code+80H），向用户应用发出一个Exception Response作为肯定的证实。
- 如果function code与Request中所用的function code不同（= 非预期的function code），或如果Response的format是Error的，那么，向用户应用发出一个Error信号作为否定的证实。
注：肯定证实是指服务器收到Request命令并做出Response的证实。并不意味着服务器能够成功地CompleteRequest命令中要求的Operation（MODBUSException Response指明执行Operation失败）。
下图比图17更深入地描述了证实处理的过程。
图13：MODBUS证实处理Operation示意图
超时管理
对MODBUS/TCP上事务处理所需Responsetime有意不作规定。
这是因为：从毫秒级的I/O扫描到延时几秒钟的远距离无线链路，预期MODBUS/TCP会用于可能最宽泛的通信场合。
从客户机的角度，超时必须考虑网络上预期的传输延迟，以便确定一个合理的Responsetime。这种传输延迟可能是交换式以太网中的几个毫秒，或广域网connect中的几百毫秒。
反过来讲，任何客户机启动应用重试使用的超时time应该大于预期的最大的合理Responsetime。如果不遵循这一点，目标设备或网络就existence过度拥挤的潜在危险，而反过来会导致More的Error。这是一个应该始终避免的特性。
因此，在实际中，在高性能应用中所使用的客户机超时似乎总是与网络拓扑和期望的客户机性能有关。
time因素不很重要的system经常采用TCP缺省值作为超时值，在多数平台上，几秒钟之后将报告通信故障。
MODBUS服务器端
图14：MODBUS服务器端
MODBUS服务器的作用是为应用对象提供访问以及为远端客户机提供服务。
根据用户应用，提供不同Type的访问：
- 简单访问：获得或设定应用对象的属性；
- 高级访问：启动一个特定的应用服务
MODBUS服务器必须：
- 将一个应用对象映射成可读或可写的MODBUS对象，以便获得或设定应用对象的属性；
- 提供一种对应用对象启动服务的方法；
在运行过程中，MODBUS服务器必须分析receive到的MODBUSRequest，处理所需的Operation，返回MODBUSResponse。
MODBUS服务器设计
MODBUS服务器设计取决于如下两个方面：
- 对应用对象访问的Type（对属性的简单访问或对服务的高级访问）；
- MODBUS服务器与用户应用之间交互作用的Type（同步或异步）。
下图描述了服务器进行的主要处理过程，以便获得来自TCP管理的MODBUSRequest，然后，分析Request，处理所需的Operation，返回MODBUSResponse。
图15：处理MODBUS指令Operation示意图
象前面的Operation示意图示出的那样：
- MODBUS服务器本身可以立即处理一些服务，没有与用户应用之间的交互作用；
- 一些服务还可能需要与被处理的用户应用进行明显的交互作用；
- 有些高级服务需要调用特定的接口，即：MODBUS后台服务。例如：可能根据用户application layer protocol，使用若干个MODBUSRequest/Response事务处理的时序来启动用户应用服务。后台服务负责所有单个MODBUS事务处理的正确进行，以便于执行全局用户应用服务。
在下列各章中给出更完整的描述。
MODBUS服务器可以receive并同时为多个MODBUSRequest提供服务。服务器可以同时receiveMODBUSRequest的maximum quantity是MODBUS服务器的主要特性之一。这个quantity取决于服务器的设计以及它的处理和存储能力。将这个实现参数称为“NumberMaxOfServerTransaction”，必须作为MODBUS服务器的一个特性描述这个实现参数。根据设备的能力，它的取值范围为：1～16，。
“NumberMaxOfServerTransaction”参数对MODBUS服务器的Operation和性能有非常显著的影响。尤其重要的是，所管理的并发MODBUS事务处理的quantity可能影响服务器对MODBUSRequest的Responsetime。
MODBUS PDU检验
下图描述了MODBUS PDU检验Operation。
图16：MODBUS PDU检验Operation流程图
MODBUS PDU检验Function首先是分解MBAPmessage头。必须检验Protocol Identifier域：
- 如果与MODBUS协议Type不同，那么废除这个指示。
- 如果是正确的（= MODBUS协议Type；值为0x00），立即举例说明一个MODBUS事务处理。
一个服务器可以距离说明的MODBUS事务处理的maximum quantity由参数“NumberMaxOfTransaction”（system或配置参数）来定义。
在Invalid的事务处理的情况下，服务器生成一个MODBUSException Response（Exception Code6：服务器繁忙）。
如果事务处理是effective的，它将被启动，以便存储下列信息：
- 用于send指示的TCPconnect标识符（由TCP管理给出）
- MODBUS事务处理ID（MBAPmessage头中给出）
- Unit identifier（MBAPmessage头中给出）
然后，分解MODBUS PDU。首先分析function code：
- 当Invalid时，生成MODBUSException Response（Exception Code1：InvalidFunction）
- 如果receivefunction code，服务器启动一个“MODBUS服务处理”Operation。
MODBUS服务处理
图17：MODBUS 服务处理Operation流程图
根据后面实例中equipment软件和硬件结构，可以用不同的方式进行要求的MODBUS服务处理：
- 在一个小型设备或单线程体系结构内，MODBUS服务器可以直接访问用户应用data，服务器自身可以本地处理要求的服务，而无需调用后台服务。
根据“MODBUS协议规范”，进行这种处理。在出现Error的情况下，生成MODBUSException Response。
- 在一个模块化的多处理器equipment或多线程体系结构中，“通信层”和“用户应用层”是两个独立的实体，通信实体可以完全地处理一些不重要的服务，而其他的服务需要应用后台服务与用户应用实体协调Complete。
为了实现与用户应用的交互作用，MODBUS后台服务必须执行所有适当的机制，以便处理用户应用的事务处理，并且正确管理用户应用调用和相应的Response。
用户应用接口（后台接口）
在MODBUS后台服务中，可以执行几种策略来Complete工作，虽然从用户网络吞吐量、接口带宽使用、Responsetime、甚至设计工作量的角度，这几种策略是不均衡的。
MODBUS后台服务将对用户应用采用适当接口：
- 或基于串行链路的物理接口，或双口RAM方案，或一条简单的I/O电缆，或由Operationsystem提供的基于message传输服务的逻辑接口。
- 到用户应用的接口可以是同步的或异步的。
MODBUS后台服务还将使用适当的设计模式来得到/设定目标属性或触发服务。在某些情况下，一个简单的“网关模式”将是足够的。在其他情况下，从简单的交换表历史到更复杂的重复机制中，设计者将必须执行带有高速缓存策略的“代理服务器模式”，。
MODBUS后台服务有责任实现协议的转换，以便与用户应用进行交互作用。因此，它必须具有机制来实现message的分拆和重组、data一致性保证以及所有需要的同步等Function。
MODBUSResponse的生成
一旦处理Request，MODBUS服务器必须使用适当的MODBUS服务器事务处理生成一个Response，并且必须将Responsesend到TCP管理组件。
根据处理结果，可以生成两类Response：
- 肯定的MODBUSResponse：
- Responsefunction code = Requestfunction code
- MODBUSException Response：
- 目的是为客户机提供与处理过程检测到的ErrorRelated的信息
- Responsefunction code = Requestfunction code+0x80
- 提供Exception Code来表明出错的原因。
| Exception Code | MODBUS名称 | 备注 |
| 01 | 非法的function code | 服务器不Understand the functions码 |
| 02 | 非法的dataaddress | 与Request有关 |
| 03 | 非法的data值 | 与Request有关 |
| 04 | 服务器故障 | 在执行过程中，服务器故障 |
| 05 | Confirm | 服务器接受服务调用，但是需要相对长的timeComplete服务。因此，服务器仅返回一个服务调用receive的Confirm。 |
| 06 | 服务器繁忙 | 服务器不能接受MODBUSRequestPDU。客户应用由责任决定是否和何时重发Request。 |
| 0A | 网关故障 | 网关路经是Invalid的。 |
| 0B | 网关故障 | 目标设备没有Response。网关生成这个异常信息。 |
MODBUSResponsePDU必须以MBAPmessage头做前缀，使用事务处理正文中的data生成MBAPmessage头。
- Unit identifier
当在所收到的MODBUSRequest中给出Unit identifier时，拷贝这个Unit identifier，并将其存储在事务处理的正文中。
- Length
服务器计算MODBUS PDU和Unit identifier字的大小。在“Length”域中设置这个值。
- Protocol Identifier
设置Protocol Identifier域为0x0000（MODBUS协议），在所收到的MODBUSRequest中给出Protocol Identifier。
- 事务处理标识符
设置这个域为“事务处理标识符”值，它与初始Request有关，并将其存储在。
利用事务处理正文中存储的TCPconnect对正确的MODBUS客户机返回MODBUSResponse。当sendResponse时，事务处理正文必须释空闲的。
实现指南
本章的目的是提出一个实现message传输服务的实例。下面所描述的模型可用作客户机或服务器实现MODBUSmessage传输服务过程的指南。
对象模型示意图
图18：MODBUSmessage传输服务对象模型示意图
四种主要程序包构成对象模型示意图：
- 配置层，它配置和管理其它程序包组件的Operation模式
- TCP管理，它使TCP/IP栈和管理TCPconnect的通信应用层connect。这指的是套接字接口的管理。
- 通信应用层，它由在一侧的MODBUS客户机和在另一侧的MODBUS服务器组成。该程序包和用户应用链接。
- 用户应用，它和设备应用相对应，它完全与设备有关，因此在本文件中不予讨论。
本模型与实现的选择无关，例如：OSType、存储管理等。为保证这种无Related性，在TCP管理层和通信层之间以及在通信层和用户应用层之间使用普通界面层（generic Interface layers）。
有不同的实现方法实现该界面：两项任务之间的传输、共享存储器、串行链接界面、过程呼叫等。
为定义下面的实现模型，作了一些假定：
- 静态存储器管理
- 服务器的同步处理
- 处理有关所有套接字receive的任务。
TCP管理程序包
图19：MODBUS TCP管理程序包
TCP管理程序包包括下列类：
ClnterfaceConnexion：该类的作用是管理用于connect的存储库。
CltemConnexion：该类含有描述connect所需要的所有信息。
CTCPConnexion：该类提供自动管理TCPconnect的方法（CStackTCP_IP提供接口套接字）。
CconnexionMngt：该类管理所有connect，并通过CinterfaceindicationMsg和CinterfaceRoseponseMsg向MODBUS服务器/MODBUS客户机sendRequest/Response。该类还处理connect建立的访问控制。
CMBAP：该类提供读/写/分析MODBUS MBAP的方法。
CStackTCP_IP：该类执行套接字服务并提供栈的参数配置。
配置层程序包
图20：MODBUS配置层程序包
配置层程序包包括下列类：
TConfigreObject：该类将各组件相互配置所需的data分组。用CoperatingMode类中的m_Confire方法填充这个结构。每个需要配置的类从这个对象中取得自己的data。配置data与实现本身有关。因此，提供该类的属性表作为一个实例。
CoperatingMode：该类的作用是填充TConfigueObject（根据用户的配置）和管理下述类的Operation模式。
- CMODBUSServer
- CMODBUSClient
- CconnexionMngt
通信层程序包
图21：MODBUS通信应用层程序包
通信应用层程序包包括以下各类：
CMODBUSServer：从CinterfaceIndicationMsg中receiveMODBUS询问（通过m_ServerRecievingMessage方法）。该类的作用是根据询问建立MODBUSResponse或MODBUS异常（从网络进入）。该类实现MODBUS服务器的Graph State。只有类CoperatingModesend了用户配置和正确的Operation模式，才可能Generate response。
CMODBUSClient：从类CinterfaceUserApplication中读取MODBUS询问，客户机的任务是用m_ClientReceivingMessage方法receive询问。该类实现MODBUS客户机的State Graph，并且管理链接带有Response的询问的事务处理（来自网络的）。只有类CoperatingModesend了用户配置和正确的Operation模式，才能通过网络send询问。
CTransaction：该类实现管理事务的方法和结构。
接口类
CInterfaceUserApplication：该类表示与用户应用的接口，它提供两种访问用户data的方法。在实际的实现中，根据硬件和软件设备的能力，用不同的方式实现这种方法（相当于一个终端驱动器、访问PCMCIA的实例、共享存储器等）。
CInterfaceIndicationMsg：该接口类用来从网络向MODBUS服务器send询问，以及从网络向客户机sendResponse。该类使TCPManagement和通信应用层程序包connect（从网络中）。该类的实现与网络有关。
CInterfaceResponseMsg：该接口类用于从服务器接受Response，以及从客户机向网络send询问。该类使通信应用层程序包和TCPManagementconnect（向网络）。该类的实现和设备有关。
通信实现的类的示意图
下列类的示意图是一个完整的实现方案的示意图。
图22：类的示意图
Sequence图
下面描述了两个Sequence图，以便说明客户机MODBUS事务处理和服务器MODBUS事务处理。
图23：MODBUS客户机Sequence图
为更好地理解客户机Sequence图，简单的注释为：
第一步：读来自用户应用的询问(通过m_Read方法)。
第二步：客户机的任务是receiveMODBUS询问（通过m_ClientReceivingMessage方法）。这是客户机的进入点。为了使询问和相应的Response相互协调，当得到询问时，客户机使用事务处理资源（类名：CTransaction）。通过呼叫类接口CInterfaceResponseMsg向TCP_ManagementsendMODBUS询问（通过m_MODBUSRequest方法）。
第三步：如过已建立connect，并且不需要对connect做什么，那么通过网络sendmessage。否则，在网络上可以sendmessage之前，必须有开放的connect。
此时，客户机等待最后讨论的Response（来自远程服务器）。
第四步：若从已经从网络得到Response，那么TCP/IP栈receivedata（隐蔽地呼叫m_EventOnStack方法）。
如果已建立connect，那么读MBAP以恢复connect对象（connect对象提供存储资源和其它信息）。
读取来自网络的data，通过类接口CinterfaceIndicationMsg向客户机send证实（通过m_MODBUSConfirmation方法）。客户机的任务是receiveMODBUS证实（通过m_ClientReceivingResponse方法）。
最后，向用户应用写入Response（通过m_Writedata方法），并且事务处理资源是空闲的。
下面是MODBUS服务器交换的实例：
图24：MODBUS服务器Sequence图
为更好地理解客户机Sequence图，简单的注释为：
第一步：某客户机已通过网络send了询问（MODBUS询问）。TCP/IP栈receivedata（隐蔽地呼叫m_EventOnSocket方法）。
第二步：Request可能是connectRequest，也可能不是connectRequest（通过m_IsConnexionRequest方法）。如果Request是connectRequest，那么分配connect对象和收发MODBUS帧的缓冲器（m_GetObjectConnexion）。之后，必须检查和接受connect访问控制。
第三步：如果询问是MODBUSRequest，那么可以读出完整的MODBUS Query（通过m_ReceiveData方法）。此时，必须分析MBAP（通过m_IsMdbHeadercorrect方法）。通过CInterfaceIndicationMessaging类向服务器任务（task）send完整的帧（通过m_MODBUSIndication方法）。服务器的任务是receiveMODBUS QUERY（通过m_ServerReceivingMessage方法）并加以分析。
如果有差错出现（未支持的function code等），生成MODBUS异常帧形（m_BuildMODBUSException），否则Generate response。
第四步：通过CInterfaceResponseMessaging（通过m_MODBUSResponse方法）在网络上sendResponse。通过m_SendData方法进行对connect对象的处理（恢复connect描述符等），在网络上senddata。
类和方法的描述
MODBUS服务器端的类
类名：CMODBUSServer
类名：CMODBUSServer
Stereotype实现类
提供用服务器模式管理MODBUSmessage传输的方法
| 域综述 | |
| protected char | GlobalStateMODBUS服务器的状态 |
| 构造器综述 | |
| CMODBUSServer(TConfigureObject * lnkConfigureObject)构造器：生成内部对象 | |
| 方法综述 | |
| protected void | m_InitServerFunctions(void )为填充Function阵列“m_ServerFunction”数列构造器呼叫的Function |
| bool | m_Reset(void )重新设置服务器的方法，如果重新设置，那么返回肯定值 |
| int | m_ServerReceivingMessage(TItemConnexion * lnkMODBUS)与CindicationMsg：：m_MODBUSIndication的接口，以从网络receive询问，如有问题，返回否定值 |
| bool | m_Start(void )启动服务器的方法，如果启动，返回肯定值 |
| bool | m_Stop(void )停止服务器的方法，如果停止，返回肯定值 |
| protected void | m_tServerMODBUS(void )服务器的MODBUS任务.. |
MODBUS客户机类
类名：CMODBUSClient
类名：CMODBUSClient
提供用客户机模式管理MODBUSmessage传输的方法
Stereotype实现类
| 域综述 | |
| protected char | GlobalStateMODBUS客户机的状态 |
| 构造器综述 | |
| CMODBUSClient(TConfigureObject * lnkConfigureObject)构造器：生成内部对象，启动0变量 | |
| 方法综述 | |
| Int | m_ClientReceivingMessage(TItemConnexion * lnkMODBUS)从应用层receivemessage传输的接口：呼叫读data呼叫的CinterfaceUserApplication::m_Read 为事务处理取得存储器的CInterfaceConnexion::m_GetObjectConnexion 如果有问题，那么返回否定值 |
| Bool | m_Reset(空的)重新设置组件的方法，如果重新设置，返回肯定值 |
| bool | m_Start(空的)启动组件的方法，如果启动，返回肯定值 |
| bool | m_Stop(空的)停止组件的方法，如果停止，返回肯定值 |
| protected 空的 | m_tClientMODBUS(空的)客户机的MODBUS任务…. |
接口的类
接口指示类
类名：CInterfaceIndicationMsg
直接已知的子类
类名：CInterfaceIndicationMsg
从TCP_Management向MODBUS服务器或客户机sendmessage的类
Stereotype接口
| 方法综述 | |
| int | m_MODBUSConfirmation(TItemConnexion * lnkObject)receive进入Response和呼叫客户机的方法：通过可用参考值、message排队、远程过程呼叫等, … |
| int | m_MODBUSIndication(TItemConnexion * lnkObject)读进入MODBUS询问和呼叫服务器的方法：通过可用参考值、message排队、远程过程呼叫等, … |
接口Response类
类名：CInterfaceResponseMsg
直接已知的子类：
class CInterfaceResponseMsg
从客户机或服务器向TCP_ManagementsendResponse或询问的类
Stereotype接口
| 方法综述 | |
| TitemConnexion * | m_GetMemoryConnexion(unsigned long IPDest)从存储库得到对象ItemConnexion，如果存储不充足，返回值-1 |
| int | m_MODBUSRequest(TItemConnexion * lnkCMODBUS)将进入MODBUS询问客户机写入ConnexionMngt的方法：通过可用参考值、message排队、远程过程呼叫等, … |
| int | m_MODBUSResponse(TItemConnexion * lnkObject)将MODBUS服务器的Response写入ConnexionMngt的方法：通过可用参考值、message排队、远程过程呼叫等, … |
connect管理类
类名：CConnexionMngt
类名：CConnexionMngt
管理所有TCPconnect的类
Stereotype 实现类
| 域综述 | |
| protected char | GlobalState组件ConnexionMngt的综合状态 |
| Int | NbConnectionSupportedconnect的Allquantity |
| Int | NbLocalConnection本地客户机向远程服务器开放的connectquantity |
| Int | NbRemoteConnection远程客户机向本地服务器开放的connectquantity |
| 构造器综述 | |
| CconnexionMngt(TConfigureObject * lnkConfigureObject)构造器：生成内部对象、启动0变量 | |
| 方法综述 | |
| int | m_EventOnSocket(空的)唤醒 |
| bool | m_IsConnectionAuthorized(unsigned long IPAdress)如果授权新connect，返回肯定值 |
| int | m_ReceiveData(TItemConnexion * lnkConnexion)与CTCPConnexion::write接口，从网络中读data的方法，如果有问题，返回否定值 |
| bool | m_Reset(空的)重新设置ConnectionMngt组件的方法，如果重新设置，返回肯定值 |
| int | m_SendData(TItemConnexion * lnkConnexion)为CTCPConnexion::read接口，向网络senddata的方法，如果有问题，返回否定值 |
| bool | m_Start(空的)启动ConnectionMngt组件的方法，如果启动，返回肯定值 |
| bool | m_Stop(空的)停止组件的方法，如果停止，返回肯定值 |
星耀member
发表回复