CN113765976A - 一种通信方法和系统 - Google Patents

Abstract

本发明公开了一种通信方法和系统，涉及计算机技术领域。该方法的一具体实施方式包括：基于TCP/IP信息流接口与搭档系统建立连接；在成功建立该连接后，与搭档系统以预设的报文结构传输报文，其中，当收到搭档系统发送的确认报文后，确定搭档系统发送的确认报文的序列号是预期的序列号且当前能够处理搭档系统发送的确认报文，然后向搭档系统发送肯定应答。该实施方式能够保证数据完整性和快速一致性处理，容错性后，可快速自恢复，简化报文编码，可快速检测异常设备，有效释放网络资源，通讯稳定可靠，保证指令顺序性、可靠性，报文交互安全性高，支持多线程，降低开发复杂度，避免拆包粘包。

Description

一种通信方法和系统

技术领域

本发明涉及通信技术领域，尤其涉及一种通信方法和系统。

背景技术

目前设备/系统间通信方案，以物流管理系统为例，主要有三种：业务系统(作为服务端)对接厂商WCS系统(物流管理系统，作为客户端)，厂商WCS系统根据HTTP通讯协议(超文本传输协议)进行适配转发；业务系统采用OPC(OLE for Process Control,用于过程控制的OLE)协议直接与厂商WCS系统进行通讯；业务系统采用UDP协议(用户数据报协议)直接与厂商WCS系统进行通讯。其中，业务系统采用HTTP与厂商WCS系统进行通讯，由于HTTP无状态，业务系统与厂商WCS系统在一个业务流程需要进行多次交互，频繁进行三次握手，消耗网络性能，且HTTP协议使用“whitespace-delimited”方式进行编码，存在大量的空格、回车字符，这种编码方式存在大量的冗余内容，同时HTTP的报文头也使得通讯数据中存在大量的特定业务中不需要的内容，严重影响网络性能；采用OPC通讯不支持多线程，且开发复杂；采用UDP通讯存在不可靠、不稳定的缺陷，网络不好容易发生丢包，不能保证任务的准确性。

在实现本发明过程中，发明人发现现有技术中至少存在如下问题：

无法保证数据完整性和一致性，容错性差且无法快速自恢复，报文编码冗余内容多，无法快速检测异常设备，网络资源占用高，反复连接使得消耗网络性能，存在通讯不稳定、不可靠的缺陷，不支持多线程，开发复杂。

发明内容

有鉴于此，本发明实施例提供一种通信方法和系统，能够保证数据完整性和快速一致性处理，有较好的容错性，具备快速自恢复功能，简化报文编码，提高单位字节下有效信息的密度，可快速检测异常设备，有效释放网络资源，避免反复连接消耗网络性能，通讯稳定可靠，保证指令的顺序性、可靠性，报文交互安全性高，支持多线程，降低开发复杂度，并避免拆包粘包。

为实现上述目的，根据本发明实施例的一个方面，提供了一种通信方法。

一种通信方法，包括：基于TCP/IP信息流接口与搭档系统建立连接；在成功建立所述连接后，与所述搭档系统以预设的报文结构传输报文，其中，当收到所述搭档系统发送的确认报文后，确定所述搭档系统发送的确认报文的序列号是预期的序列号且当前能够处理所述搭档系统发送的确认报文，然后向所述搭档系统发送肯定应答。

可选地，所述预设的报文结构中报文以消息开始符开始、以消息结束符结束，且当所述消息开始符和所述消息结束符被作为报文内容传输时，预先按照转换规则对作为报文内容中的所述消息开始符和所述消息结束符进行字符转换。

可选地，所述报文以数据包的形式传输，且所述数据包的大小等于可处理字节流的数量。

可选地，所述报文传输时被转换为给定长度的ASCII字符序列，所述报文的内容包括：消息开始符、确认请求标志、序列号、目的地、来源、报文数据应用、消息结束符。

可选地，还包括预先设置空闲时间和连接丢失时间；当在所述空闲时间内未接收到所述搭档系统的任何报文，则向所述搭档系统发送虚拟要求报文并重置空闲时间，当在重置的空闲时间仍未收到所述搭档系统的任何报文，则重复所述向所述搭档系统发送虚拟要求报文并重置空闲时间的操作，当超过设置的连接丢失时间后，仍未收到所述搭档系统的任何报文，则断开与所述搭档系统的连接。

可选地，如果当前无法处理所述搭档系统发送的确认报文或所述搭档系统发送的确认报文的序列号不是预期的序列号，则向所述搭档系统发送否定应答。

可选地，向所述搭档系统发送的否定应答包括第一类型否定应答和第二类型否定应答；如果接收的所述搭档系统的确认报文的序列号是错误序列号，则向所述搭档系统发送所述第一类型否定应答；如果接收的所述搭档系统的确认报文的序列号是预期的序列号，但当前无法处理所述搭档系统的确认报文，则向所述搭档系统发送所述第二类型否定应答。

可选地，还包括：向所述搭档系统发送确认报文，并等待所述搭档系统发送肯定应答或否定应答；如果在指定时间内未收到所述搭档系统的肯定应答或否定应答，则向所述搭档系统重发确认报文，且当重发确认报文的次数达到预设上限后，仍未收到所述搭档系统发送的肯定应答或否定应答，则断开与所述搭档系统的连接；所述搭档系统发送的否定应答包括所述第一类型否定应答和所述第二类型否定应答；如果连续多次收到所述搭档系统发送的第二类型否定应答，则在每次收到所述搭档系统的第二类型否定应答后，等待预设时间并再次向所述搭档系统发送确认报文。

可选地，由服务端或客户端执行所述方法；所述方法还包括：当向所述搭档系统发送第一类型否定应答或收到所述搭档系统的第一类型否定应答后，与所述搭档系统进入不同步模式，在所述不同步模式下，与所述搭档系统不再传输除序列号同步报文之外的报文，并且，在由服务端执行所述方法的情况下，由所述服务端执行如下的再同步动作：所述服务端将所述服务端的下一预期的传入报文序列号和下一要发送的报文序列号置为预设值，并向所述搭档系统发送所述序列号同步报文，以使所述搭档系统将所述搭档系统的下一预期的传入报文序列号和下一要发送的报文序列号也置为所述预设值；在由客户端执行所述方法的情况下，接收所述搭档系统发送的所述序列号同步报文，以根据所述搭档系统发送的所述序列号同步报文，将下一预期的传入报文序列号和下一要发送的报文序列号置为所述预设值。

可选地，如果接收的所述搭档系统的确认报文的序列号与之前所接收确认报文的序列号重复，且当前能够处理所述搭档系统的确认报文，则向所述搭档系统发送所述肯定应答。

可选地，当收到所述搭档系统发送的未确认报文后，如果无法处理所述未确认报文，则在不通知所述搭档系统的情况下丢弃所述未确认报文。

根据本发明实施例的另一方面，提供了一种通信系统。

一种通信系统，其特征在于，包括：互为搭档系统的客户端、服务端，其中：所述客户端基于TCP/IP信息流接口与所述服务端建立连接；在所述客户端成功建立与所述服务端的连接后，所述客户端与所述服务端之间以预设的报文结构传输报文，其中，对于所述客户端和所述服务端中的任一端，在收到该端的搭档系统发送的确认报文后，确定所述确认报文的序列号是预期的序列号且当前能够处理报文，然后向该端的搭档系统发送肯定应答。

根据本发明实施例的又一方面，提供了一种电子设备。

一种电子设备，包括：一个或多个处理器；存储器，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现本发明实施例所提供的通信方法。

根据本发明实施例的又一方面，提供了一种计算机可读介质。

一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现本发明实施例所提供的通信方法。

上述发明中的一个实施例具有如下优点或有益效果：基于TCP/IP信息流接口与搭档系统建立连接；在成功建立该连接后，与搭档系统以预设的报文结构传输报文，其中，当收到搭档系统发送的确认报文后，确定搭档系统发送的确认报文的序列号是预期的序列号且当前能够处理搭档系统发送的确认报文，然后向搭档系统发送肯定应答。能够保证数据完整性和快速一致性处理，有较好的容错性，具备快速自恢复功能，简化报文编码，提高单位字节下有效信息的密度，可快速检测异常设备，有效释放网络资源，避免反复连接消耗网络性能，通讯稳定可靠，保证指令的顺序性、可靠性，报文交互安全性高，支持多线程，降低开发复杂度，并避免拆包粘包。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是根据本发明一个实施例的通信方法的主要步骤示意图；

图2是根据本发明一个实施例的同步出错恢复流程示意图；

图3是根据本发明一个实施例的通信流程示意图；

图4是根据本发明一个实施例的通信系统的主要构成示意图；

图5是本发明实施例可以应用于其中的示例性系统架构图；

图6是适于用来实现本发明实施例的终端设备或服务器的计算机系统的结构示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

图1是根据本发明一个实施例的通信方法的主要步骤示意图。

如图1所示，本发明一个实施例的通信方法主要包括如下的步骤S101至步骤S102。

步骤S101：基于TCP/IP信息流接口与搭档系统建立连接；

步骤S102：在成功建立连接后，与搭档系统以预设的报文结构传输报文，其中，当收到搭档系统发送的确认报文后，确定搭档系统发送的确认报文的序列号是预期的序列号且当前能够处理搭档系统发送的确认报文，然后向搭档系统发送肯定应答。

在一个实施例中，预设的报文结构中报文以消息开始符开始、以消息结束符结束，且当消息开始符和消息结束符被作为报文内容传输时，预先按照转换规则对作为报文内容中的消息开始符和消息结束符进行字符转换。

报文可以以数据包的形式传输，且数据包的大小等于可处理字节流的数量。

在一个实施例中，报文传输时被转换为给定长度的ASCII字符序列，报文的内容包括：消息开始符、确认请求标志、序列号、目的地、来源、报文数据应用、消息结束符。

在一个实施例中，还可以预先设置空闲时间和连接丢失时间。当在空闲时间内未接收到搭档系统的任何报文，则向搭档系统发送虚拟要求报文并重置空闲时间，当在重置的空闲时间仍未收到搭档系统的任何报文，则重复向搭档系统发送虚拟要求报文并重置空闲时间的操作，当超过设置的连接丢失时间后，仍未收到搭档系统的任何报文，则断开与搭档系统的连接。

如果当前无法处理搭档系统发送的确认报文或搭档系统发送的确认报文的序列号不是预期的序列号，则向搭档系统发送否定应答。

在一个实施例中，向搭档系统发送的否定应答包括第一类型否定应答和第二类型否定应答，即向搭档系统发送的某一否定应答可以是第一类型否定应答，也可以是第二类型否定应答。

如果接收的搭档系统的确认报文的序列号是错误序列号，则向搭档系统发送第一类型否定应答；如果接收的搭档系统的确认报文的序列号是预期的序列号，但当前无法处理搭档系统的确认报文，则向搭档系统发送第二类型否定应答。

本发明一个实施例的通信方法还可以包括：向搭档系统发送确认报文，并等待搭档系统发送肯定应答或否定应答；如果在指定时间内未收到搭档系统的肯定应答或否定应答，则向搭档系统重发确认报文，且当重发确认报文的次数达到预设上限后，仍未收到搭档系统发送的肯定应答或否定应答，则断开与搭档系统的连接；搭档系统发送的否定应答包括第一类型否定应答和第二类型否定应答；如果连续多次收到搭档系统发送的第二类型否定应答，则在每次收到搭档系统的第二类型否定应答后，等待预设时间并再次向搭档系统发送确认报文。

本发明实施例的通信方法可以由服务端或客户端执行。

当向搭档系统发送第一类型否定应答或收到搭档系统的第一类型否定应答后，与搭档系统进入不同步模式，在不同步模式下，与搭档系统不再传输除序列号同步报文之外的报文。

在由服务端执行本发明实施例的通信方法的情况下，由服务端执行如下的再同步动作：服务端将服务端的下一预期的传入报文序列号和下一要发送的报文序列号置为预设值，并向搭档系统发送序列号同步报文，以使搭档系统将搭档系统的下一预期的传入报文序列号和下一要发送的报文序列号也置为预设值。

在由客户端执行本发明实施例的通信方法的情况下，接收搭档系统发送的序列号同步报文，以根据搭档系统发送的序列号同步报文，将下一预期的传入报文序列号和下一要发送的报文序列号置为预设值。

如果接收的搭档系统的确认报文的序列号与之前所接收确认报文的序列号重复，且当前能够处理搭档系统的确认报文，则向搭档系统发送肯定应答。

当收到搭档系统发送的未确认报文后，如果无法处理未确认报文，则在不通知搭档系统的情况下丢弃未确认报文。

上文已经介绍了本发明实施例的通信方法可以由服务端或客户端执行。在由服务端执行本发明实施例的通信方法的情况下，搭档系统是指客户端。在由客户端执行本发明实施例的通信方法的情况下，搭档系统是指服务端。即：本发明实施例中客户端与服务端互为搭档系统。客户端基于TCP/IP信息流接口与服务端建立连接。在成功建立连接后，客户端与服务端之间以预设的报文结构传输报文，其中，当客户端和服务端中的第一端向第二端发送确认报文后，第二端确定确认报文的序列号是预期的序列号且第二端当前能够处理报文，然后向第一端发送肯定应答，第一端在收到肯定应答后，继续向第二端发送后续的确认报文。由于客户端与服务端之间以预设的报文结构传输报文是相互的，当客户端向服务端传输报文，则客户端为第一端、服务端为第二端；当服务端向客户端传输报文，则服务端为第一端、客户端为第二端。

本发明实施例的报文可以是确认报文、未确认报文。

对于确认报文，如果报文被正确认可并会被接收端(即第二端)处理，接收端会答复已收到该报文。如果接收端由于内部堵塞等情况而无法处理接收到的确认报文，则会传回一个否定答复(否定应答)给发送端(即第一端)。因此，确认报文不会在没有告知发送端的情况下丢失。

对于未确认报文，当客户端和服务端中的第一端向第二端发送未确认报文后，如果第二端无法处理未确认报文，则在不通知第一端的情况下丢弃未确认报文。例如，接收端由于内部堵塞而无法处理接收到的未确认报文，该报文会在不知会发送端的情况下直接被丢弃，因此，未确认报文很可能会丢失。发送端发送未确认报文后，只能继续发送下一报文，而无法确定会有接收端的应答。

报文以数据包的形式传输时，第一端所发送的数据包的大小等于第二端可处理字节流的数量。

在一个实施例中，客户端和服务端分别设置有各自的空闲时间和连接丢失时间，当其中一方在空闲时间内未接收到另一方的任何报文，则向另一方发送虚拟要求报文并重置空闲时间，当在重置的空闲时间仍未收到另一方的任何报文，则重复向另一方发送虚拟要求报文并重置空闲时间的操作，当超过设置的连接丢失时间后，仍未收到另一方的任何报文，则断开与另一方的连接。

如果第二端当前无法处理确认报文或确认报文的序列号不是预期的序列号，则向第一端发送否定应答。

如果第一端在指定时间内未收到第二端发送的肯定应答或否定应答，则重发确认报文；当重发确认报文的次数达到预设上限后，仍未收到第二端发送的肯定应答或否定应答，则第一端断开连接。

在一个实施例中，如果第二端所接收的确认报文的序列号是错误序列号，则向第一端发送第一类型否定应答；如果第二端所接收的确认报文的序列号是预期的序列号，但第二端当前无法处理报文，则向第一端发送第二类型否定应答。当第一端连续多次收到第二端的第二类型否定应答后，则在每次收到第二类型否定应答后，等待预设时间并再次发送确认报文。

在一个实施例中，当第二端收到第一类型否定应答后，第一端与第二端进入不同步模式，在不同步模式下，第一端和第二端之间不再传输除序列号同步报文之外的报文，并由第一端和第二端之中的服务端执行如下的再同步动作：服务端将服务端的下一预期的传入报文序列号和下一要发送的报文序列号置为预设值，并向客户端发送序列号同步报文，以使客户端将客户端的下一预期的传入报文序列号和下一要发送的报文序列号也置为预设值。

在一个实施例中，如果第二端所接收的确认报文的序列号与之前所接收确认报文的序列号重复，且第二端当前能够处理报文，则向第一端发送肯定应答。

本发明实施例的通信方法基于事件导向的、全双工通信制、双边的、可靠的报文通信协议，具体如下：系统间的数据被转化为报文，即被定义成固定说明的短小数据包(20至120个字节)，系统之间有一个必须相互通信的点对点连接，两个系统之间的连接是用于进行双向的数据传输，即：每一对想要互相通信的系统中有且只有一个直接连接，且这个连接可用于从A系统到B系统的数据，也可用于从B系统到A系统的数据。

本发明实施例支持一个特定的系统与其他几个系统进行通信，特定的系统与每个搭档系统的链路都有一个单独的连接，支持多线程通信。

进行报文通信(或称报文传输)的两个系统一个被定义为服务端，另一个作为客户端。以物流管理系统为例，可以定义厂商WCS是客户端，业务方WCS是服务端，厂商WCS即厂商的仓库设备管理系统，业务方WCS即业务方的物流管理系统-基层设备物流控制自动化系统。客户端也可以是厂商的PLC(可编程逻辑控制器)设备。

进行报文传输的两个系统中其中一个系统可以称为另一个系统的搭档系统。如果发生了一个必须汇报给搭档系统的事件，每个系统都可以随时发送数据。只有在本发明实施例的报文通信协议中有流控制和握手机制才允许系统之间进行安全地数据(即报文)传输。

本发明实施例的通信是基于TCP/IP信息流接口连接的，客户端启动时，会立即尝试与服务端建立连接。服务端(例如业务方WCS)会用一个固定的端口号创建一个监听接口，然后等待被客户端(例如厂商WCS)调用。当一个呼入被确认，它会被服务端接受，连接被确定后进行数据交换。客户端通过固定的主机和端口号调用服务端，尝试建立连接。如果尝试失败，客户端会等待片刻后重试；如果连接被服务端接受，则在连接被确定OK后进行数据交换。

服务端不会判定任何特定的客户端IP地址或客户端的端口号，即任何来源的调用都会被接受。如果业务需要可以增加包括但不限于IP校验、端口校验、MAC地址校验或者TOKEN值校验等安全策略，以保证客户端来源的可靠稳定。

连接建立成功后会一直保持活跃状态，通常连接只会在如下其中一种情况下断开：系统检测到连接存在通信问题(例如读取或发送连接失败)；系统遇到搭档系统反应超时或者失败；在系统维护时人为请求断开。

所有使用本发明实施例通信协议的数据传输都适用于ASCII字符流。当发送数据时，数据被转化成一个给定长度的ASCII字符，即：报文在传输时被转换为转换为给定长度的ASCII字符序列。有两种可使用的基础数据类型：一是ALPHA n，为一个恰好是n的ASCII字符的序列。所有从“！”到

之间，除了“<”、“>”，都是允许的字符。在长度不够的情况下允许在字符串的后面用空格补位。二是NUM n，为一个在“0”到“9”之间的恰好是n的ASCII字符的序列，描述的是数字。

报文的内容可以包括：消息开始符、确认请求标志、序列号、目的地、来源、报文数据应用、校验位、消息结束符等。由于本发明实施例的报文通信基于TCP，而TCP是流协议，没有直接的方式来自动检测报文的范围。因此，本发明实施例的报文结构定义报文以消息开始符“<”开始、以消息结束符“>”结束。客户端和服务端中的发送端(即第一端)必须把每个报文放在正确的结构里，尤其是要分别用“<”和“>”开始和结束报文。接收端(即第二端)需扫描出有效的报文，即从一个“<”到下一个“>”作为一个有效的报文，每个“>”和下个“<”之间的内容会被认为是连接中的杂质，接收端会忽略此部分。如果报文结构中出现了另一个“<”，接收端会认为是一个新结构的开始，并将之前的“<”和该“<”之间的内容视为结构错误而忽略。接收端在检测到杂质或者结构错误后可以发出本地警告消息。

在一些实施例中，报文结构还可以采用扩展数据结构(或称扩展报文结构)，例如，程序要求在程序数据中实现发送“<”和“>”字符的功能，即：“<”和“>”是报文内容的一部分，那么，可以预先按照转换规则对该消息开始符和消息结束符进行字符转换，例如：当发送数据到TCP/IP接口，可以用“％)”来代表“>”，用“％(”来代表“<”，用“％％”来代表“％”，其他字符按原样发送。在报文接收时，再将“％)”转换成“>”，“％(”转换成“<”，C是除了“)”或“(”之外的任意字符时，“％C”可以被转换成“C”，其他字符组合按原样接收。对于不使用扩展数据结构的示例，程序中的所有字符按原样发送和接收，即报文内容的字符不包括“<”和“>”，“<”和“>”只作为消息开始符和消息结束符。本发明实施例可以预先配置是否使用扩展数据结构。

本发明实施例可以配置报文以数据包的形式传输，即本发明实施例可以提供发送端应在固定大小的数据包中发送数据的选项。由于一些系统，例如PLC系统，不能合理处理未指定的字节流，因此，本发明实施例当要发送的报文结构短于预设的固定大小，则数据(报文)会被填充字符填充至该大小。当要发送的报文结构正好是该固定大小，则无需任何操作。当要发送的报文结构大于该固定大小，则数据(报文)会被填充字符填充至该大小的整数倍。上述填充在报文结构外面进行。本发明实施例中，即使配置的数据包大小足够长，发送端也不能在一个数据包中放置一个以上的报文。当数据包大小为1时，则每个字节会被单独处理，字节流将真正地被当作一个个字节的流。如果配置为处理一个字节流(即数据包大小为1)的接收端能处理配置更大的数据包，由于填充字符是在报文结构外面进行，那么填充的字符将会被当作杂质直接忽略。

对于每一个连接，依赖于TCP/IP网络设置的参数如表1所示，客户端主机名/IP地址和端口号可不配置。

表1

本发明实施例中，如果一系统自行断开连接，或者检测到连接被搭档系统或外部因素断开，该系统会进入通信设置状态，具体地，若该系统为服务端则等待再次被调用，若该系统为客户端则反复尝试重新建立连接。

在某些情况下，可能会出现一个系统认为建立了连接，但其搭档系统认为没有建立连接，从而可能导致连接不能自动恢复。为此，本发明实施例使用接收超时和报文保持心跳功能。具体地，互相通信的系统(客户端或服务端)设置有各自的空闲时间和连接丢失时间，当其中一方(例如系统A)在空闲时间内未接收到另一方(例如系统B)的任何报文，则向另一方(系统B)发送虚拟要求报文，即DUM报文，在发送DUM报文之后，该方(系统A)将重置自身的空闲时间。另一方(系统B)收到DUM报文后，会向发送DUM报文方(系统A)发送DUA应答，系统A收到DUA应答后，会再次重置自身的空闲时间。这一过程如表2所示。

表2

对于通信连接中的任何一方(服务端或客户端)，在空闲时间到期时都会向搭档系统发送DUM报文。

当一方未向搭档系统发送DUM报文，却意外收到搭档系统的DUA应答后，DUA应答会被忽略，但仍会重置空闲时间。

接收到任何报文(无论是否正确或有效)都会重置空闲时间，因此，如果一个站点(或称系统)持续发送程序报文，且两个程序报文之间间隔短于空闲时间，那么收到这些报文的站点(系统)将永远不会发送DUM。

发送一份DUM报文后，空闲时间也会被重置，在发送一份DUM报文后，在空闲时间内依旧没有收到搭档系统的报文时，则会再次发送DUM。如果发送DUM报文后，收到一份其他报文而不是DUA应答，也会重置空闲时间。DUA不含任何信息，收到DUM的一方也可以除DUA应答之外的其他报文作为应答。

如果站点(系统)在其连接丢失时间内没有收到搭档系统的任何报文(即“连接丢失超时”)，那么会认为搭档系统已死机，则断开连接。之后，根据此站点在TCP/IP平台上被配置为客户端还是服务端，站点会尝试重新连接或者等待搭档系统重新连接。该过程如表3所示。

表3

任何接收到的报文都会重置连接丢失时间。连接丢失超时(即连接丢失时间，或称链路丢失超时)必须比空闲超时(即空闲时间)时间长，否则连接在发送DUM报文检测之前就会被断开。连接丢失时间从任何一个报文被接收开始计算，而不是从发送DUM开始计算。例如表4所示。

表4

本发明实施例的报文可以是确认报文或未确认报文。未确认报文由发送端(即第一端)发送，如果接收端(即第二端)由于内部堵塞无法处理接收到的未确认报文，该报文会在不知会发送端的情况下直接被丢弃，这意味着未确认报文很可能会丢失。发送端发送未确认报文后，只能继续发送下一封，无法确定会有应答。

确认报文由发送端发送，如果报文被正确认可并会被接收端处理，接收端答复已收到该报文。如果接收端由于内部堵塞无法处理接收到的确认报文，则会传回一个否定应答给发送端。确认报文不会在没有告知发送端的情况下丢失。确认报文的发送端收到了肯定应答后，可以继续发送下一封报文。

如果发送端收到了否定应答“缓冲区已满”的指示，则等待预设时间(即预先设定的缓冲区已满超时时间)后重新发送一次该报文。如果发送端在指定时间(即预先设定的确认超时时间)内没有收到接收端的任何(肯定或否定)应答，则重新发送一次该报文。可以预设重发确认报文的次数的上限，发送端在没有接收到任何应答的情况下，当重复发送同一报文的次数达到预设上限，如果最后一次尝试仍然没有收到应答，发送端将断开连接。

流控制是双向分开的，例如A发送报文给B，但是尚未被确认，B仍可以发送报文给A。未确认报文的传输过程如表5所示，其中XXX(1)、XXX(2)中“(1)”、“(2)”表示报文序列号；确认报文的传输过程如表6所示，其中以“ACK应答(1)”为例，表示序号为1的应答报文；接收端缓存区(或称缓冲区)已满情况下的报文传输如表7所示，其中，“NCK(已满)”表示缓冲区已满的否定应答(为第二类型否定应答的一个示例)，如果确实存在问题，接收端会不止一次的拒绝该报文，发送端将无止境地尝试发送；接收端无应答情况下的报文传输如表8所示。以下各表中A、B表示通信的两个系统，若一个是服务端，则另一个为客户端，表中“A到B”，表示报文传输方向是由系统A到系统B，下文类似情况将不再说明。

表5

编号	报文	通信	描述
				0			连接正常
1	XXX(1)	A到B	未确认报文被发送
				2	XXX(2)	A到B	下一封未确认报文被发送
			……以此类推

表6

编号	报文	通信	描述
				0			连接正常
1	XXX(1)	A到B	一封确认的报文被发送
				2	ACK应答(1)	B到A	接收端确认接收
3	XXX(2)	A到B	下一封确认的报文被发送
				4	ACK应答(2)	B到A	接收端确认接收
			……等等

表7

表8

如上文表5至8中所示，每一个确认报文包含一个序列号，用来让接收端判断该报文是已经收到过的重复报文还是新的报文，以及判断接收到的报文是否与预期一致。

未确认报文没有序列号，即结构中的序列号总是设置为0000，因此，以下主要针对确认报文进行详细说明，下文关于序列号的说明部分中报文即指确认报文。

确认报文的序列号范围从0001到9999。每一个新的确认报文序列号比其前一个确认报文序列号增加1。序列号循环出现，如果前一个确认报文的序列号是9999，则下一个被发送的确认报文的序列号是0001，当再同步期间使用同步报文时，序列号将被重新设置成某一特定起始值(0001)，0000从不作为确认报文的序列号。报文传输的两个方向序列号单独管理，例如，从A到B方向和从B到A方向的序列号是分开的。序列号不分报文类型，即它是通过某一连接被发送的所有类型报文的计数。

如果系统中的程序由处理不同报文的不同部件组成，序列号须由要管理与搭档系统连接的通信组件负责。本发明实施例的确认报文序列号被安全地保存在磁盘等以永久存储。

对于由发送端处理的序列号：当一个新的确认报文需发送，“要被发送的下一个序列号”被递增1，并分配给报文；发送后等待接收端的应答；在收到应答之前不能发送其他确认报文；如果接收到肯定应答，则可发送下一封报文；如果接收到的是否定的“序列错误”应答(即第一类型否定应答的示例)，则会进入“不同步”模式，不再发送任何报文；如果接收到否定的“缓冲区已满”应答(即第二类型否定应答的示例)或正常时间内无应答，则等待一段时间重新发送该序列号的报文。

对于由接收端处理的序列号：如果接收的报文是正确的，即含有预期的序列号，则应答发送端该报文被接收端处理；如果接收的报文是重复的，即序列号与以前报文一样，也会像正确的报文一样应答发送端(很可能之前的ACK报文丢失了)，但不对报文做任何处理；如果接收的报文是错误的序列号(既不是预期的也不是与之前重复的)，则给出“序列错误”的否定应答，接收端进入“不同步”模式，来电不予处理。

重复报文情况下的确认报文传输如表9所示；序列号错误情况下的确认报文传输如表10所示。

表9

表10

不管发送端由于不正确的内部数据发送一个错误报文，或接收端因为不正确的内部数据误解了报文序列号，结果是相同的，即：双方都不再发送报文了。接收端如果在不同步模式下，不再接收应用报文(包括有正确序列号的报文)，对于低级报文(DUM，DUA，SYN)仍然接受和处理。接收端如果在不同步模式下，接收到一个确认的应用程序报文(确认报文)，则在没有任何进一步的检查情况下直接回复NCK“序列错误”指示，且报文被忽略。发送端如果在不同步模式下，不再发送应用报文(包括有正确序列号的报文)，对于低级报文(DUM，DUA，NCK，SYN)仍然发送。因此，不同步的情况会阻止双向的流量，例如，如果A到B方向出了问题，并且各站点(系统)进入不同步模式，这也意味着B到A方向没有确认报文被发送或接受。

本发明实施例通过再同步来解决不同步问题。可以手动启动服务端系统，进行人工干预设置，也可以自动触发再同步(auto SYN)。本发明一个实施例的同步出错恢复流程如图2所示，图2中同步错误模式即不同步模式，当接收端收到序列号错误(或序列错误)的否定应答后，通信双方进入不同步模式，服务端将服务端的下一预期的传入报文序列号和下一要发送的报文序列号置为0001，并向客户端发送SYN报文，以使客户端将客户端的下一预期的传入报文序列号和下一要发送的报文序列号也置为0001。同步出错恢复过程也可如表11所示。

表11

上述过程中，需确保两个系统之间的连接已经启动和运行，否则可能发生只有一个系统恢复到正常模式，而另一个系统则停留在不同步模式。一个不在不同步模式的系统(客户端)也接收SYN报文，并且处理方式相同，即“下一个预期的传入序列号”和“下一个要发送的序列号”都被设置为0001。如果有一个未解决的报文尚未应答，则会用0001的序列号重新发送。再同步影响的是双向的，例如，即使只有A到B方向的序列号不同步了，接下来再同步设置将A到B和B到A方向的序列号均重置为0001。

当系统与其搭档系统的连接建立之后，执行以下内容：1.复位计时器(接收计时，链路(连接)丢失计时)；2.如果有一封确认报文已发送但没有收到应答，则重新发送该报文；3.如果没有尚未解决的应答，则发送下一封报文。相关参数如表12所示。

表12

本发明实施例的报文结构，每个报文都由如表13所示的内容构成：

表13

未确认报文(确认请求标志为0)没有直接的低级应答，发送端可以立即发送下一封报文。对应发送的确认报文(确认请求标志为1)，接收端将给一个低级的ACK应答(肯定应答)或NCK应答(否定应答)。发送端只有在这个报文被应答之后才可以发送下一个确认报文。报文结构错误不会汇报给发送端，接收端只产生一个本地错误，并且不接受这个报文。本发明实施例的报文通信协议不包含任何路由和转发程序，接收端只接受目的地与自己相匹配的报文，而其他报文会被忽略。

如果使用扩展数据结构，字符<、>和％必须以特殊的方式来处理。例如：

程序报文中含有以下数据：

XTC0001<XML-Data>99％0102

则会被转换为：

<00000ddddddssssssXTC0001％(XML-Data％)99％％010200>

下面详细介绍本发明实施例的连接检查/保持心跳报文。报文传输双方之中的一方在空闲时间内未接收到另一方的任何报文，则向另一方发送虚拟要求报文，即DUM报文。报文布局如表14所示。

表14

数据描述	字段类型	值	备注
				报文类型	ALPHA 3	DUM
错误指示符	NUM 1	0	预留
				应答序列号	NUM 4	0000	预留

每个站点(系统)都可以在任何时候发送DUM报文，DUM报文是作为未确认报文发送的(即在结构中，“确认请求标志”＝＝0，“序列号”＝＝0000)。

DUM报文的接收端必须应答一个DUA报文，即虚拟应答报文，DUA报文布局如表15所示。

表15

DUM和DUA报文用于连接上没有其他通信的时候及时检测链路(连接)故障。如果没有收到预期的DUA报文，等待的站点(系统)需要适当的运行修复程序。DUA报文也是作为未确认报文发送的(即在结构中，“确认请求标志”＝＝0，“序列号”＝＝0000)。

下面分别介绍本发明实施例的应答报文和序列号同步报文。

肯定应答报文，即ACK报文，为成功接收报文的指示，可由通信双方的任何一方发送，以确认报文被成功接收。肯定应答报文的报文布局如表16所示。

表16

数据描述	字段类型	值	备注
				报文类型	ALPHA 3	ACK
错误指示符	NUM 1	0	预留
				应答序列号	NUM 4	0001-9999	确认报文的序列号

当站点(系统)收到一个报文结构中确认请求标示为1的正确程序报文，即该报文为确认报文，那么会将带有该确认报文序列号的ACK发送给该确认报文的发送端。当站点(系统)收到一个重复的确认程序报文(即确认报文)，即序列号比预期的小，那么会将带有该重复序列号的ACK会发送给该重复报文的发送端。

传入的(正确的)的ACK报文允许原始报文的发送端将它从发送队列中移除，并发送下一确认报文。ACK报文是作为未确认报文发送的(即在结构中，“确认请求标志”＝＝0，“序列号”＝＝0000)。

否定应答报文，即NCK报文，为未成功接收报文的指示，可由通信的两系统的任何一方发送，以确认报文被接收并被拒绝。否定应答报文的报文布局如表17所示。

表17

当站点(系统)收到一个确认程序报文(即确认报文，报文结构中确认请求标示为1)，但序列号既不是预期的序列号，也不是上一个报文的正确序列号，则会发送包含错误指示符＝＝1及下一个预期序列号的NCK报文给该确认程序报文的发送端，接收该序列号错误的NCK报文的一方收到序列号错误的NCK报文后进入序列号错误模式，此时双方都进入不同步模式。

当站点(系统)收到一个确认程序报文(即确认报文，报文结构中确认请求标示为1)，但由于当前接收缓存空间不足无法存储，则会发送包含错误指示符＝＝2及下一个预期序列号的NCK报文给该确认报文的发送端，收到该缓冲区已满的NCK报文的一方等待预设时间(即预先设定的缓冲区已满超时时间)，然后重新发送该之前的确认报文，在这之前不能发送其他确认报文。

传入的(正确的)的ACK报文允许原始报文的发送端将它从发送队列中移除，并发送下一个确认报文。NCK报文是作为未确认报文发送的(即在报文结构中，“确认请求标志”＝＝0，“序列号”＝＝0000)。

序列号同步报文，即SYN报文，用于请求重新同步序列号，可以由服务端发送SYN用来从同步错误模式恢复。序列号同步报文的报文布局如表18所示。

表18

数据描述	字段类型	值	备注
				报文类型	ALPHA 3	SYN
错误指示符	NUM 1	0	预留
				应答序列号	NUM 4	0000	预留

SYN报文只能由通信双方之中的服务端发送，SYN分为auto SYN和手动SYN。其中，auto SYN，即服务端收到客户端的序列号错误的NCK报文后，或者服务端发送序列号错误的NCK报文后，自动发送SYN报文给客户端。手动SYN：服务端收到客户端的序列号错误的NCK后，需要人工检查报文序列号错误原因，是否丢失报文，并检查完成后，手动发送SYN给客户端。

SYN报文会重新同步所有序列号(包括从服务端到客户端的报文序列号，以及从客户端到服务端的报文序列号)。SYN报文的发送端将“下一个预期序列号”设置为0001，这意味着该SYN报文接收端下一封发送的报文序列号需为0001。SYN报文的接收端也将“下一个预期序列号”设置为0001，这意味着该SYN报文的发送端下一封发送的报文序列号需为0001。如果SYN的接收端当前不在“同步错误模式”，它仍然会接收和处理SYN报文。

SYN没有报文确认，即进行再同步时，需确保与子系统(即作为客户端的系统)的该链接(连接)没问题并且子系统已准备好接受一个SYN报文。SYN报文是作为未确认报文发送的(即在报文结构中，“确认请求标志”＝＝0，“序列号”＝＝0000)。

下面介绍本发明实施例的数据安全、数据缓冲机制。本发明实施例每个系统负责被发送的报文数据，直到接收端应答该报文，应答后则由接收端负责，特殊情况(如网络故障、系统崩溃等)也如此。

如果通信组件(通信组件的含义取决于系统上的通用软件结构)和数据处理组件的只是松散耦合，通信组件中必须有数据缓冲区。如果一个数据处理组件生成了给其他系统的报文，但由于某些原因(如链接(连接)未建立，以前的报文尚未确认)暂时无法发送，该报文必须在发送端安全地保存。如果报文到达并且该报文目前无法通过通信组件到相应的数据处理组件，通信组件需将该报文存储在缓冲区。这个缓冲区也必须是安全的。只有当报文被存储后，应答方可发回发送端。

基于上述数据安全、数据缓冲机制，本发明一个实施例的通信流程示意图如图3所示。

在发送端，数据交互组件向通讯组件提交数据发送(1)，发送端将数据存储在发送缓存区(2)后，只返回OK信号给数据处理组件，数据处理组件收到握手OK信号(3)，通讯组件将数据发送给搭档系统(即接收端)(4)。需要说明的是，如果数据不能存储在发送缓存区中(例如缓冲区已满)，则返回NOT OK信号给数据处理组件，并不发送数据。返回OK信号给数据处理组件与将数据发送给搭档系统这两个步骤顺序不分先后。

在接收端，通讯组件将数据存储在接收缓存区(5)，并向发送端通讯组件返回肯定应答，即ACK报文(6)。由于向发送端通讯组件返回肯定应答可能需要相当长的时间，可以先执行返回OK信号给数据处理组件(3)的步骤。如果数据不能存储在接收缓冲区中(例如缓冲区已满)，则必须返回NCK报文给发送端。

在发送端，作为对接收到的ACK的反应，通讯组件从发送缓存区中自动执行数据删除(7)。

另外，在接收端，通讯组件将数据发送到数据交互组件(8)，数据交互组件提交返回的数据(9)，然后通讯组件从接收缓存区汇总删除缓存的数据(10)。

上述组件也可以称为模块，例如，发送端的数据交互组件可以称为数据交互模块，用于向通讯组件(或称通讯模块)提交数据发送。其他组件同理，不逐一说明。

在收到ACK报文之前，发送端在任何情况下(包括通讯故障，程序故障，系统崩溃等)都要能再次发送数据报文。在收到ACK报文之后，发送端将不会被要求再次发送报文。因此，该数据可被删除。

接收端在发送ACK报文之后，任何情况下(包括通讯故障，程序故障，系统崩溃等)都不能失去该报文，因为发送端可能无法重新发送该报文。

本发明实施例的通信双方的任一方系统都可在日志文件中记录所有发送和接收的数据，以及所有其他事件，以确保以后在不明确的情况下可以进行数据分析，并采取必要的行动以防止发生问题。

本发明实施例可以很好地解决电商领域的业务方物流管理系统与厂商物流管理系统之间现有通信方案所存在的缺陷，本发明实施例提出的报文应答机制、幂等性处理机制(即对于收到的重复报文照常应答)、数据重发机制，保证了业务数据的完整性、消息的快速一致性处理，序列号同步机制保证了序列号的容错性，具备快速自恢复功能，PLC设备上电后需要进行注册，并可使用多种方式进行安全性校验，包括但不限于TOKEN值检验，IP、端口、MAC地址校验，链接设备名称校验，报文长度校验等，保证了报文交互的安全性。心跳机制保证了异常设备的快速检测，网络资源的有效释放，本发明实施例还定义特殊数据结构，简化报文编码，提高单位字节下有效信息的密度，并解决报文拆分和TCP连接的拆包粘包问题。服务端可以接收多个客户端的连接，支持多线程，提高设备的处理性能，并降低开发复杂度，业务系统(可为服务端)与PLC设备(可为客户端)之间可靠存活的存在唯一通道，无需频繁进行三次握手，从而减少网络性能消耗，通讯稳定可靠，保证指令的顺序性、可靠性。

图4是根据本发明一个实施例的通信系统的主要构成示意图。

如图4所示，本发明一个实施例的通信系统400包括客户端401、服务端402，其中客户端401可以为多个。客户端401、服务端402互为对方的搭档系统。

客户端401基于TCP/IP信息流接口与服务端402建立连接；在客户端401成功建立与服务端402的连接后，客户端401与服务端402之间以预设的报文结构传输报文，其中，对于客户端401和服务端402中的任一端，在收到该端的搭档系统发送的确认报文后，确定该确认报文的序列号是预期的序列号且当前能够处理报文，然后向该端的搭档系统发送肯定应答，即：当客户端401和服务端402中的第一端向第二端发送确认报文后，第二端确定确认报文的序列号是预期的序列号且第二端当前能够处理报文，然后向第一端发送肯定应答，第一端在收到肯定应答后，继续向第二端发送后续的确认报文。

在一个实施例中，预设的报文结构中报文可以消息开始符开始、以消息结束符结束，且当消息开始符和消息结束符被作为报文内容传输时，预先按照转换规则对作为报文内容中的消息开始符和消息结束符进行字符转换。

在一个实施例中，报文以数据包的形式传输，且第一端所发送的数据包的大小等于第二端可处理字节流的数量。报文传输时被转换为给定长度的ASCII字符序列，报文的内容包括：消息开始符、确认请求标志、序列号、目的地、来源、报文数据应用、消息结束符。

在一个实施例中，客户端401和服务端402分别设置有各自的空闲时间和连接丢失时间，当其中一方在空闲时间内未接收到另一方的任何报文，则向另一方发送虚拟要求报文并重置空闲时间，当在重置的空闲时间仍未收到另一方的任何报文，则重复向另一方发送虚拟要求报文并重置空闲时间的操作，当超过设置的连接丢失时间后，仍未收到另一方的任何报文，则断开与另一方的连接。

在一个实施例中，如果第二端当前无法处理确认报文或确认报文的序列号不是预期的序列号，则向第一端发送否定应答；如果第一端在指定时间内未收到第二端发送的肯定应答或否定应答，则重发确认报文；当重发确认报文的次数达到预设上限后，仍未收到第二端发送的肯定应答或否定应答，则第一端断开连接。

在一个实施例中，否定应答包括第一类型否定应答和第二类型否定应答；如果第二端所接收的确认报文的序列号是错误序列号，则向第一端发送第一类型否定应答；如果第二端所接收的确认报文的序列号是预期的序列号，但第二端当前无法处理报文，则向第一端发送第二类型否定应答。

当第一端连续多次收到第二端的第二类型否定应答后，则可在每次收到第二类型否定应答后，等待预设时间并再次发送确认报文。

当第二端收到第一类型否定应答后，第一端与第二端进入不同步模式，在不同步模式下，第一端和第二端之间不再传输除SYN报文之外的报文，并由第一端和第二端之中的服务端402执行如下的再同步动作：服务端402将服务端402的下一预期的传入报文序列号和下一要发送的报文序列号置为预设值，并向客户端401发送SYN报文，以使客户端401将客户端401的下一预期的传入报文序列号和下一要发送的报文序列号也置为预设值。

如果第二端所接收的确认报文的序列号与之前所接收确认报文的序列号重复，且第二端当前能够处理报文，则向第一端发送肯定应答。

当客户端401和服务端402中的第一端向第二端发送未确认报文后，如果第二端无法处理未确认报文，则在不通知第一端的情况下丢弃未确认报文。

另外，在本发明实施例中通信系统的具体实施内容，在上面所述通信方法中已经详细说明了，故在此重复内容不再说明。

图5示出了可以应用本发明实施例的通信方法或通信系统的示例性系统架构500。

如图5所示，系统架构500可以包括终端设备501、502、503，网络504和服务器505。网络504用以在终端设备501、502、503和服务器505之间提供通信链路的介质。网络504可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备501、502、503通过网络504与服务器505交互，以接收或发送消息等。终端设备501、502、503上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。

终端设备501、502、503可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器505可以是提供各种服务的服务器，例如对用户利用终端设备501、502、503所浏览的购物类网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的产品信息查询请求等数据进行分析等处理，并将处理结果(例如目标推送信息、产品信息--仅为示例)反馈给终端设备。

需要说明的是，本发明实施例所提供的通信方法由服务器505和执行终端设备501、502、503。本发明实施例所提供的通信系统中客户端位于终端设备501、502、503中，服务端位于服务器505中。

应该理解，图5中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

下面参考图6，其示出了适于用来实现本申请实施例的终端设备或服务器的计算机系统600的结构示意图。图6示出的终端设备或服务器仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图6所示，计算机系统600包括中央处理单元(CPU)601，其可以根据存储在只读存储器(ROM)602中的程序或者从存储部分608加载到随机访问存储器(RAM)603中的程序而执行各种适当的动作和处理。在RAM 603中，还存储有系统600操作所需的各种程序和数据。CPU 601、ROM 602以及RAM 603通过总线604彼此相连。输入/输出(I/O)接口605也连接至总线604。

以下部件连接至I/O接口605：包括键盘、鼠标等的输入部分606；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分607；包括硬盘等的存储部分608；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分609。通信部分609经由诸如因特网的网络执行通信处理。驱动器610也根据需要连接至I/O接口605。可拆卸介质611，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器610上，以便于从其上读出的计算机程序根据需要被安装入存储部分608。

特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分609从网络上被下载和安装，和/或从可拆卸介质611被安装。在该计算机程序被中央处理单元(CPU)601执行时，执行本申请的系统中限定的上述功能。

需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括数据交互模块、发送缓存区模块、通讯模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，数据交互模块还可以被描述为“用于向通讯组件(或称通讯模块)提交数据发送的模块”。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：基于TCP/IP信息流接口与搭档系统建立连接；在成功建立所述连接后，与所述搭档系统以预设的报文结构传输报文，其中，当收到所述搭档系统发送的确认报文后，确定所述搭档系统发送的确认报文的序列号是预期的序列号且当前能够处理所述搭档系统发送的确认报文，然后向所述搭档系统发送肯定应答。

根据本发明实施例的技术方案，基于TCP/IP信息流接口与搭档系统建立连接；在成功建立该连接后，与搭档系统以预设的报文结构传输报文，其中，当收到搭档系统发送的确认报文后，确定搭档系统发送的确认报文的序列号是预期的序列号且当前能够处理搭档系统发送的确认报文，然后向搭档系统发送肯定应答。能够保证数据完整性和快速一致性处理，有较好的容错性，具备快速自恢复功能，简化报文编码，提高单位字节下有效信息的密度，可快速检测异常设备，有效释放网络资源，避免反复连接消耗网络性能，通讯稳定可靠，保证指令的顺序性、可靠性，报文交互安全性高，支持多线程，降低开发复杂度，并避免拆包粘包。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (14)

1.一种通信方法，其特征在于，包括：

基于TCP/IP信息流接口与搭档系统建立连接；

在成功建立所述连接后，与所述搭档系统以预设的报文结构传输报文，其中，当收到所述搭档系统发送的确认报文后，确定所述搭档系统发送的确认报文的序列号是预期的序列号且当前能够处理所述搭档系统发送的确认报文，然后向所述搭档系统发送肯定应答。

2.根据权利要求1所述的方法，其特征在于，所述预设的报文结构中报文以消息开始符开始、以消息结束符结束，且当所述消息开始符和所述消息结束符被作为报文内容传输时，预先按照转换规则对作为报文内容中的所述消息开始符和所述消息结束符进行字符转换。

3.根据权利要求1或2所述的方法，其特征在于，所述报文以数据包的形式传输，且所述数据包的大小等于可处理字节流的数量。

4.根据权利要求2所述的方法，其特征在于，所述报文传输时被转换为给定长度的ASCII字符序列，所述报文的内容包括：消息开始符、确认请求标志、序列号、目的地、来源、报文数据应用、消息结束符。

5.根据权利要求1所述的方法，其特征在于，还包括预先设置空闲时间和连接丢失时间；

当在所述空闲时间内未接收到所述搭档系统的任何报文，则向所述搭档系统发送虚拟要求报文并重置空闲时间，当在重置的空闲时间仍未收到所述搭档系统的任何报文，则重复所述向所述搭档系统发送虚拟要求报文并重置空闲时间的操作，当超过设置的连接丢失时间后，仍未收到所述搭档系统的任何报文，则断开与所述搭档系统的连接。

6.根据权利要求1所述的方法，其特征在于，

如果当前无法处理所述搭档系统发送的确认报文或所述搭档系统发送的确认报文的序列号不是预期的序列号，则向所述搭档系统发送否定应答。

7.根据权利要求6所述的方法，其特征在于，向所述搭档系统发送的否定应答包括第一类型否定应答和第二类型否定应答；

如果接收的所述搭档系统的确认报文的序列号是错误序列号，则向所述搭档系统发送所述第一类型否定应答；

如果接收的所述搭档系统的确认报文的序列号是预期的序列号，但当前无法处理所述搭档系统的确认报文，则向所述搭档系统发送所述第二类型否定应答。

8.根据权利要求7所述的方法，其特征在于，还包括：

向所述搭档系统发送确认报文，并等待所述搭档系统发送肯定应答或否定应答；

如果在指定时间内未收到所述搭档系统的肯定应答或否定应答，则向所述搭档系统重发确认报文，且当重发确认报文的次数达到预设上限后，仍未收到所述搭档系统发送的肯定应答或否定应答，则断开与所述搭档系统的连接；所述搭档系统发送的否定应答包括所述第一类型否定应答和所述第二类型否定应答；

如果连续多次收到所述搭档系统发送的第二类型否定应答，则在每次收到所述搭档系统的第二类型否定应答后，等待预设时间并再次向所述搭档系统发送确认报文。

9.根据权利要求8所述的方法，其特征在于，由服务端或客户端执行所述方法；

所述方法还包括：当向所述搭档系统发送第一类型否定应答或收到所述搭档系统的第一类型否定应答后，与所述搭档系统进入不同步模式，在所述不同步模式下，与所述搭档系统不再传输除序列号同步报文之外的报文，并且，

在由服务端执行所述方法的情况下，由所述服务端执行如下的再同步动作：所述服务端将所述服务端的下一预期的传入报文序列号和下一要发送的报文序列号置为预设值，并向所述搭档系统发送所述序列号同步报文，以使所述搭档系统将所述搭档系统的下一预期的传入报文序列号和下一要发送的报文序列号也置为所述预设值；

在由客户端执行所述方法的情况下，接收所述搭档系统发送的所述序列号同步报文，以根据所述搭档系统发送的所述序列号同步报文，将下一预期的传入报文序列号和下一要发送的报文序列号置为所述预设值。

10.根据权利要求6或7所述的方法，其特征在于，

如果接收的所述搭档系统的确认报文的序列号与之前所接收确认报文的序列号重复，且当前能够处理所述搭档系统的确认报文，则向所述搭档系统发送所述肯定应答。

11.根据权利要求1所述的方法，其特征在于，当收到所述搭档系统发送的未确认报文后，如果无法处理所述未确认报文，则在不通知所述搭档系统的情况下丢弃所述未确认报文。

12.一种通信系统，其特征在于，包括：互为搭档系统的客户端、服务端，其中：

所述客户端基于TCP/IP信息流接口与所述服务端建立连接；

在所述客户端成功建立与所述服务端的连接后，所述客户端与所述服务端之间以预设的报文结构传输报文，其中，对于所述客户端和所述服务端中的任一端，在收到该端的搭档系统发送的确认报文后，确定所述确认报文的序列号是预期的序列号且当前能够处理报文，然后向该端的搭档系统发送肯定应答。

13.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储器，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1-11中任一所述的方法。

14.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1-11中任一所述的方法。

Images