CN101753586A - 发送数据的方法、接收数据的处理方法和装置 - Google Patents
发送数据的方法、接收数据的处理方法和装置 Download PDFInfo
- Publication number
- CN101753586A CN101753586A CN201010034290A CN201010034290A CN101753586A CN 101753586 A CN101753586 A CN 101753586A CN 201010034290 A CN201010034290 A CN 201010034290A CN 201010034290 A CN201010034290 A CN 201010034290A CN 101753586 A CN101753586 A CN 101753586A
- Authority
- CN
- China
- Prior art keywords
- data
- packet
- length
- subpackage
- buffering area
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明提供了一种发送数据的方法和装置,以及接收数据的处理方法和装置,属于通信领域。所述发送数据的方法包括:确定需要发送的数据对应的数据结构,确定命令类型和数据长度,首次发送所述数据结构中的数据时,按照指定的数据包格式存储当前数据,并以TCP方式发送所述当前数据;其中,所述指定的数据包格式包括命令包头和当前数据,命令包头携带命令类型和数据长度。本发明采用了指定的数据包格式传输数据,使接收方可以基于该长度对接收到的数据包进行正确的分包,能够可靠地传输有顺序、有结构信息的数据。
Description
技术领域
本发明涉及通信领域,更具体地,涉及发送数据的方法和装置,以及接收数据的处理方法和装置。
背景技术
在应用开发过程中,经常需要把数据可靠地从一个应用程序发送到另一个应用程序,并且传输的数据一般为有顺序、带结构(定长或者不定长)的数据,接收方通常需要对这些数据进行分包处理。
相关数据传输技术中有以下几种方式:
1)采用UDP(User Datagram Protocol,用户数据报协议)进行数据的网络传输
UDP协议是数据报模式,数据是通过数据包一个一个地发送的,采用UDP来进行数据网络传输,其数据包很可能会丢失,或者数据包的顺序会变化,因此UDP协议不适用于对顺序和传输可靠性要求高的数据传输。
2)采用TCP(Transport Control Protocol,传输控制协议)进行数据的网络传输
TCP协议是流模式,是一个面向连接的传输层协议,TCP的目标是为用户提供可靠的端到端连接,保证信息有序无误的传输;它除了提供基本的数据传输功能外,为保证可靠性还采用了数据编号、校验和计算、数据确认等一系列措施。TCP协议对传送的每个数据字节都进行编号,并请求接收方回传确认信息(Ack),TCP协议是一种可靠的数据传输服务。由于TCP是流模式,且TCP数据不封包,没有边界,接收方可能一次接收到某一个数据包或者一个数据包和下一个数据包的一部分或者几个包等等,这时接收方接收的数据不是发送时的一个一个数据包,而是数据包粘到了一起,即“粘包”。如果此时TCP传输的是有结构(定长的数据结构、不定长数据结构)的数据信息,则会造成接收方无法对这些数据进行分包处理。
3)采用RPC(Remote Procedure Call Protocol,远程过程调用)进行数据的网络传输
RPC进行数据传输时,需要将待发送的数据打包,然后将打好的数据包一个一个地发送到接收方;接收方将根据不同的数据结构进行接收处理。而RPC某种程度上依赖于操作***,依赖于应用程序的开发工具,不能跨平台通讯;另外,RPC是被动式的通讯不能主动通知通讯,这种方式对于不同厂家采用不同的开发工具或平台或者需要双向通讯的情况不能顺利进行。
发明人在实现本发明的过程中发现,上述方法均不能可靠地传输有顺序、有结构信息的数据,且目前对于该问题仍没有可行的解决方案。
发明内容
本发明旨在提供一种发送数据的方法和装置,以及接收数据的处理方法和装置,能够可靠地传输有顺序、有结构信息的数据和普通数据。
根据本发明的一个方面,提供了一种发送数据的方法,所述方法包括:
确定需要发送的数据对应的数据结构;
根据所述数据结构确定命令类型和数据长度;
首次发送所述数据结构中的数据时,按照指定的数据包格式存储当前数据,并以TCP方式发送所述当前数据;
其中,所述指定的数据包格式包括命令包头和所述当前数据,所述命令包头携带所述命令类型和所述数据长度。
根据本发明的另一方面,还提供了一种接收数据的处理方法,所述方法包括:
将接收的数据包中的数据缓存到缓冲区,所述数据包包括命令包头,所述命令包头携带所述命令类型和所述数据长度;
根据所述数据长度对所述缓冲区中的数据进行分包;
根据所述命令类型对分包后的数据包进行处理。
根据本发明的另一方面,还提供了一种发送数据的装置,所述装置包括:
数据结构确定模块,用于确定需要发送的数据对应的数据结构;
类型和长度确定模块,用于根据所述数据结构确定模块确定的数据结构确定命令类型和数据长度;
发送模块,用于首次发送所述数据结构中的数据时,按照指定的数据包格式存储当前数据,并以TCP方式发送所述当前数据;
其中,所述指定的数据包格式包括命令包头和所述当前数据,所述命令包头携带所述类型和长度确定模块确定的命令类型和数据长度。
根据本发明的另一方面,还提供了一种接收数据的处理装置,所述装置包括:
缓存模块,用于将接收的数据包中的数据缓存到缓冲区,所述数据包包括命令包头,所述命令包头携带所述命令类型和所述数据长度;
分包模块,用于根据所述数据长度对所述缓冲区中的数据进行分包;
处理模块,用于根据所述命令包头中的命令类型,对所述分包模块分包后的数据包进行处理。
因为采用了指定的数据包格式传输数据,这种格式可以携带数据长度,进而使接收方可以基于该长度对接收到的数据包进行正确的分包,所以克服了相关技术中的“粘包”问题,进而达到了可靠地传输有顺序、有结构信息的数据和普通数据的效果。
附图说明
附图用来提供对本发明的进一步理解,构成本申请的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1示出了本发明实施例1提供的发送数据的方法流程图;
图2示出了本发明实施例2提供的接收数据的处理方法流程图;
图3示出了本发明实施例4提供的发送数据的装置的结构框图;
图4示出了本发明实施例5提供的接收数据的处理装置的结构框图。
具体实施方式
下面将参考附图并结合实施例,来详细说明本发明。
实施例1
本实施例提供了一种发送数据的方法,参见图1,为本实施例提供的发送数据的方法流程图,该方法包括:
步骤S102:确定需要发送的数据对应的数据结构;
本实施例预先根据需要发送的数据的类型定义对应的数据结构,不同的数据结构中的数据长度可能不同;当要发送数据时,根据定义确定当前要发送的数据对应的数据结构;
步骤S104:根据上述数据结构确定命令类型和数据长度;
步骤S106:首次发送上述数据结构中的数据时,按照指定的数据包格式存储当前数据,并以TCP方式发送当前数据;
其中,该指定的数据包格式如表1所示,包括命令包头和数据,这里的数据指上述当前数据,即此次欲发送的数据,该命令包头携带命令类型和数据长度。
表1
命令包头 | 数据(m个字节,m>=0) |
本实施例中的命令类型是用以提供给接收方的指示信息,指示接收方对当前数据进行如何处理;数据长度指上述数据结构中的数据的长度,该长度可能与当前发送的数据的长度相等,也可能不相等。
例如,一个数据结构中的数据长度为1000字节,而以TCP方式发送数据时,每次发送的数据为500字节,则首次发送该数据结构中的数据时,命令包头中的数据长度为1000字节,非首次发送该数据结构中的数据时,则可以按照相关技术中的TCP方式发送,即使出现“粘包”现象,由于接收方根据命令包头中的数据长度能够确定该数据结构中数据的个数,即可以确定出该数据结构的边界,则可以从“粘包”中提取出该数据结构中的数据,进而解决了“粘包”所带来的问题。
本实施例的发送方按照上面的数据包格式,并用TCP方式首次发送数据结构中的数据,对于该数据结构中后续数据的发送不作具体限制,后续数据的发送可以采用上述数据包的格式,也可以采用相关技术中的TCP的方式,且后续数据包可以不携带数据长度。采用上述方法发送数据结构中的数据,使流式的数据像UDP数据报的数据那样处理,为接收方进行分包处理作基础,使接收方能够确定出该数据结构中的数据的边界,克服了“粘包”引起的问题。
实施例2
本实施例还提供了一种接收数据的处理方法,该方法是基于实施例1提供的发送数据的方法进行的,参见图2,为本实施例提供的接收数据的处理方法流程图,该方法包括:
步骤202:将接收的数据包中的数据缓存到缓冲区;该数据包包括命令包头,其中,命令包头携带命令类型和数据长度;
对于接收的数据包中没有包括命令包头的,直接将其缓存入缓冲区;
步骤204:根据上述数据长度对缓冲区中的数据进行分包;
由于应用程序没有为TCP设置TCP_NODELAY属性,以TCP方式传输数据时,为提高传输效率,发送方往往要收集到足够多的数据后才发送一包数据,若连续几次发送的数据都很少,通常TCP会根据优化算法把这些数据合成一包后一次发送出去,这样接收方就收到“粘包”;或者,接收方的进程不及时,也会造成接收的数据出现“粘包”;本实施例的接收方接收到数据后,将其缓存到一个缓冲区里,在接收方通过一个线程对缓冲区里的数据进行分包分析处理,使接收方能够接收不同数据结构的数据并正确处理。
本实施例的分包实现如下:判断该数据长度是否小于所述缓冲区中的数据的长度,如果是,从缓冲区中取出该数据长度的数据作为一个数据包,如果否,等待接收下一个数据包。
具体实施时,可以将缓冲区里的数据长度设为A,命令包头携带的数据长度为B;
1)如果A<B
则表明待处理缓冲区里的数据尚不够构成一个完整结构数据,需等待与下一包数据合并后再进行分包处理;
2)如果A>=B
则表明待处理缓冲区里的数据构成最少有一个完整结构数据,提取出长度为B的数据,对这个数据包进行分析处理,处理这个包后缓冲区减去这个包的长度(即B)。然后再进行递归处理,直到处理完(即A=0)或需等待与下一包数据合并后再行处理(A<B);
步骤206:根据上述命令类型对分包后的数据包进行处理。
本实施例通过对采用指定的数据包格式传输的数据进行分包处理,实现任意有顺序、有结构信息(定长的数据结构、不定长数据结构)可靠的通用的网络传输,保证数据从发送方到接收方正确可靠的接收处理。
上述实施例1和实施例2提供的方法,既结合了UDP方式的封包方法,使数据包有边界,具有能进行分析的数据报模式的优点,也结合了TCP方式,具有安全、可靠的数据传输优点。
实施例3
本实施例提供了一种发送数据的方法,该方法与实施例1中图1所示方法不同之处在于,本实施例中在发送数据时,其命令包头中还携带有命令头标志,用以指示接收方是否对当前发送的数据进行缓存。
当需要发送的数据为普通的数据,例如,需要发送的是不带结构的连续流数据(如:文件)时,接收方对这些数据不需要进行分包处理,因此,也不需要对这些数据进行缓存,接到这些数据后可以按照通常的处理方法进行处理,为此,本实施例在命令包头中携带命令头标志,用以指示接收方是否对当前数据进行缓存,例如,该预先约定命令头标志为1,为需要对当前数据进行缓存,预先约定命令头标志为0,为不需要对当前数据进行缓存。
本实施例还提供了一种接收数据的处理方法,该方法是基于本实施例上述发送数据的方法进行的,本实施例的处理方法与实施例2中图2所示方法不同之处在于,接收的数据包的命令包头还携带命令头标志,因此,接收到数据包后,首先需要根据命令头标志判断是否需要对当前接收的数据进行缓存;如果是,将当前接收的数据进行缓存;如果否,直接处理当前发送的数据。
本实施例通过采用指定的数据包格式传输数据,实现任意有顺序、有结构信息(定长的数据结构、不定长数据结构)可靠的通用的网络传输,保证数据从发送方到接收方正确可靠的接收处理;同时,对于不带结构的数据,可以按照常规的处理方式进行,通过这种方式,达到进一步优化操作的目的。本实施例提供的方法,既结合了UDP方式的封包方法,使数据包有边界,具有能进行分析的数据报模式的优点,也结合了TCP方式,具有安全、可靠的数据传输优点。
实施例4
本实施例提供了一种发送数据的装置,参见图3,为本实施例提供的发送数据的装置的结构框图,该装置包括:
数据结构确定模块302,用于确定需要发送的数据对应的数据结构;
类型和长度确定模块304,用于根据数据结构确定模块302确定的数据结构确定命令类型和数据长度;
发送模块306,用于首次发送上述数据结构中的数据时,按照指定的数据包格式存储当前数据,并以TCP方式发送该当前数据;其中,指定的数据包格式包括命令包头和当前数据,命令包头携带类型和长度确定模块304确定的命令类型和数据长度。
优选地,上述命令包头还携带命令头标志,用以指示接收方是否对当前发送的数据进行缓存。
其中,该指定的数据包格式包括命令包头和数据,这里的数据指上述当前数据,即此次欲发送的数据,该命令包头携带命令类型和数据长度。
本实施例中的命令类型是用以提供给接收方的指示信息,指示接收方对当前数据进行如何处理;数据长度指上述数据结构中的数据的长度,该长度可能与当前发送的数据的长度相等,也可能不相等。
本实施例的发送数据的装置按照上面的数据包格式,并用TCP方式首次发送数据结构中的数据,对于该数据结构中后续数据的发送不作具体限制,后续数据的发送可以采用上述数据包的格式,也可以采用相关技术中的TCP的方式,且后续数据包可以不携带数据长度。采用上述方法发送数据结构中的数据,使流式的数据能像UDP数据报的数据那样处理,为接收方进行分包处理作基础,使接收方能够确定出该数据结构中的数据的边界,克服了“粘包”引起的问题。
实施例5
本实施例提供了一种接收数据的处理装置,参见图4,为本实施例提供的接收数据的处理装置的结构示意图,该装置包括:
缓存模块402,用于将接收的数据包中的数据缓存到缓冲区,该数据包包括命令包头,命令包头携带命令类型和数据长度;
分包模块404,用于根据上述数据长度对缓冲区中的数据进行分包;
处理模块406,用于根据命令包头中的命令类型,对分包模块404分包后的数据包进行处理。
优选地,分包模块404包括:
判断单元4041,用于判断上述数据长度是否小于缓冲区中的数据的长度;
分包处理单元4042,用于判断单元4041的判断结果是上述数据长度小于缓冲区中的数据的长度时,从缓冲区中取出上述数据长度的数据作为一个数据包;如果上述数据长度不小于缓冲区中的数据的长度时,等待接收到下一个数据包后,再进行分包。
优选地,上述命令包头中还携带命令头标志;
相应地,该装置还包括:
命令头标志判断模块,用于根据命令头标志判断是否需要对当前接收的数据进行缓存;如果是,触发缓存模块402将接收到的数据包中的数据进行缓存,如果否,触发处理模块406直接处理接收到的数据包中的数据。
发送方以TCP方式传输数据时,为提高传输效率,发送方往往要收集到足够多的数据后才发送一包数据,若连续几次发送的数据都很少,通常TCP会根据优化算法把这些数据合成一包后一次发送出去,这样接收方就收到“粘包”;或者,接收方的进程不及时,也会造成接收的数据出现“粘包”;本实施例的接收数据的处理装置接收到数据后,通过缓存模块402将其缓存到一个缓冲区里,通过分包模块404对缓冲区里的数据进行分包分析处理,使接收数据的处理装置能够接收不同数据结构的数据并正确处理。
本实施例的分包模块404实现如下:可以将缓冲区里的数据长度设为A,命令包头携带的数据长度为B;
1)如果A<B
则表明待处理缓冲区里的数据尚不够构成一个完整结构数据,需等待与下一包数据合并后再进行分包处理;
2)如果A>=B
则表明待处理缓冲区里的数据构成最少有一个完整结构数据,提取出长度为B的数据,对这个数据包进行分析处理,处理这个包后缓冲区减去这个包的长度(即B)。然后再进行递归处理,直到处理完(即A=0)或需等待与下一包数据合并后再行处理(A<B)。
本实施例通过对采用指定的数据包格式传输的数据进行分包处理,实现任意有顺序、有结构信息(定长的数据结构、不定长数据结构)可靠的通用的网络传输,保证数据从发送方到接收方正确可靠的接收处理,同时,也能够对不带数据结构的数据进行处理。
上述实施例提供的方法或装置可以在高速全景监控平台上应用,该高速全景监控平台是高速公路视频监控平台性软件,其不仅能集成不同厂家的设备,也能支持级联不同厂家的子视频监控***以及与其他业务***的融合。
在与不同厂家的子视频监控***进行通讯时要实现有顺序、有结构可靠的网络传输,比如需要同步传输树状站点信息数据、编码器信息数据、解码器信息数据等等。在高速全景监控平台上应用中,接收站点信息后,才能进行接收编码器信息或解码器信息的处理,也就是说数据接收是有顺序的,同时,站点信息、编码器信息、解码器信息是有结构的并且是不定长的。当然,不是所有的接收方对流模式数据都需要处理,若传输的数据为不带结构的连续流数据(如文件传输),则不必把粘连的包分开(简称分包)。但在实际应用中,传输的数据一般为带结构的数据,这时就需要做分包处理。
具体应用时,首先将高速全景监控平台需要传输的数据比如站点信息、编码器信息、解码器信息等预定义成不同的数据结构;并将传输数据的过程中对应的请求和应答定义成不同命令,比如CMD_GetStationInfo定义请求获取站点信息的命令;CMD_RetStationInfo定义为应答返回站点信息的命令。
然后定义一个数据包,该数据包包括命令包头和数据,其中命令包头包括命令头标志(可选项)、命令类型、以及数据长度;其中,命令头标志用以指示接收方是否对接收的数据进行处理,本实施例中指是否需要对接收的数据进行缓存处理;命令类型用以指示接收方对接收的数据进行如何处理;数据长度为当前发送的数据对应的数据结构中所有数据的长度,用以告知接收方该数据结构的边界,为接收方进行分包提供基础。
在高速全景监控平台中与其他厂家***可靠传输有顺序、有结构的信息数据是***同步信息的关键,这些数据需要接收方进行分包处理,为了能够进行正确的分包处理,要求:1)可靠传输,不能出现丢包;2)传输的数据是有顺序的,不能出现乱序,前面的的数据对后面的数据有影响;3)传输的数据是带结构的数据,该数据结构可能定长或者不定长。
为了满足上述要求,采用首次发送该数据结构中的数据时,按照上述数据包格式存储当前数据,并以TCP方式发送当前数据;对于数据结构中的后续数据仍采用相关技术中的TCP方式发送。
考虑到数据传输过程中很可能会出现“粘包”现象,接收方接收到上述数据包后不直接就处理,而是把数据包中的数据缓存到一个缓冲区里,再通过一个线程对缓冲区里的数据进行分包,并分析处理,其中,分包的具体实现与实施例2和实施例3中的方法相同,这里不再详述。
上述方法或者装置在“高速全景监控平台”项目中应用,并通过测试,可以长期使用。
从以上的描述中,可以看出,本发明上述的实施例实现了任意有顺序、有结构信息(定长的数据结构、不定长数据结构)可靠的通用的网络传输,保证数据从发送方到接收方正确可靠的接收处理。同时,上述技术具有通用性,可以在不同开发工具、不同平台下应用。
显然,本领域的技术人员应该明白,上述的本发明的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,可选地,它们可以用计算装置可执行的程序代码来实现,从而可以将它们存储在存储装置中由计算装置来执行,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本发明不限制于任何特定的硬件和软件结合。
以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (10)
1.一种发送数据的方法,其特征在于,所述方法包括:
确定需要发送的数据对应的数据结构;
根据所述数据结构确定命令类型和数据长度;
首次发送所述数据结构中的数据时,按照指定的数据包格式存储当前数据,并以TCP方式发送所述当前数据;
其中,所述指定的数据包格式包括命令包头和所述当前数据,所述命令包头携带所述命令类型和所述数据长度。
2.根据权利要求1所述的方法,其特征在于,所述命令包头还携带命令头标志,用以指示接收方是否对所述当前数据进行缓存。
3.一种接收数据的处理方法,其特征在于,所述方法包括:
将接收的数据包中的数据缓存到缓冲区,所述数据包包括命令包头,所述命令包头携带所述命令类型和所述数据长度;
根据所述数据长度对所述缓冲区中的数据进行分包;
根据所述命令类型对分包后的数据包进行处理。
4.根据权利要求3所述的方法,其特征在于,根据所述数据长度对所述缓冲区中的数据进行分包包括:
判断所述数据长度是否小于所述缓冲区中的数据的长度,如果是,从所述缓冲区中取出所述数据长度的数据作为一个数据包,如果否,等待接收到下一个数据包后,再进行分包。
5.根据权利要求3所述的方法,其特征在于,所述命令包头还携带命令头标志;
相应地,所述方法还包括:
根据所述命令头标志判断是否需要对当前接收的数据进行缓存;
如果是,将所述当前接收的数据进行缓存;
如果否,直接处理所述当前接收的数据。
6.一种发送数据的装置,其特征在于,所述装置包括:
数据结构确定模块,用于确定需要发送的数据对应的数据结构;
类型和长度确定模块,用于根据所述数据结构确定模块确定的数据结构确定命令类型和数据长度;
发送模块,用于首次发送所述数据结构中的数据时,按照指定的数据包格式存储当前数据,并以TCP方式发送所述当前数据;
其中,所述指定的数据包格式包括命令包头和所述当前数据,所述命令包头携带所述类型和长度确定模块确定的命令类型和数据长度。
7.根据权利要求6所述的装置,其特征在于,所述命令包头还携带命令头标志,用以指示接收方是否对当前发送的数据进行缓存。
8.一种接收数据的处理装置,其特征在于,所述装置包括:
缓存模块,用于将接收的数据包中的数据缓存到缓冲区,所述数据包包括命令包头,所述命令包头携带所述命令类型和所述数据长度;
分包模块,用于根据所述数据长度对所述缓冲区中的数据进行分包;
处理模块,用于根据所述命令包头中的命令类型,对所述分包模块分包后的数据包进行处理。
9.根据权利要求8所述的装置,其特征在于,所述分包模块包括:
判断单元,用于判断所述数据长度是否小于所述缓冲区中的数据的长度;
分包处理单元,用于所述判断单元的判断结果是所述数据长度小于所述缓冲区中的数据的长度时,从所述缓冲区中取出所述数据长度的数据作为一个数据包;如果所述数据长度不小于所述缓冲区中的数据的长度时,等待接收到下一个数据包后,再进行分包。
10.根据权利要求8所述的装置,其特征在于,所述命令包头中还携带命令头标志;
相应地,所述装置还包括:
命令头标志判断模块,用于根据所述命令头标志判断是否需要对当前接收的数据进行缓存;如果是,触发所述缓存模块将接收到的数据包中的数据进行缓存,如果否,触发所述处理模块直接处理接收到的数据包中的数据。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201010034290A CN101753586A (zh) | 2010-01-20 | 2010-01-20 | 发送数据的方法、接收数据的处理方法和装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201010034290A CN101753586A (zh) | 2010-01-20 | 2010-01-20 | 发送数据的方法、接收数据的处理方法和装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101753586A true CN101753586A (zh) | 2010-06-23 |
Family
ID=42479984
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201010034290A Pending CN101753586A (zh) | 2010-01-20 | 2010-01-20 | 发送数据的方法、接收数据的处理方法和装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101753586A (zh) |
Cited By (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102325010A (zh) * | 2011-09-13 | 2012-01-18 | 浪潮(北京)电子信息产业有限公司 | 一种避免数据粘包的处理装置及方法 |
CN102984253A (zh) * | 2012-11-27 | 2013-03-20 | 山东中创软件工程股份有限公司 | 一种传输控制协议粘包处理方法及装置 |
CN103023602A (zh) * | 2011-09-20 | 2013-04-03 | 镇江雅迅软件有限责任公司 | 一种基于Socket协议的数据传输容错*** |
CN103532668A (zh) * | 2013-10-12 | 2014-01-22 | 成都阜特科技股份有限公司 | 一种确保tcp通信数据完整及正确的方法 |
CN104410613A (zh) * | 2014-11-20 | 2015-03-11 | 广西大学 | 一种处理传输控制协议粘包方法及装置 |
CN104917732A (zh) * | 2014-03-13 | 2015-09-16 | 深圳市赛格导航科技股份有限公司 | 一种多客户端绑定编码器及解码器的方法及*** |
CN105262970A (zh) * | 2015-10-14 | 2016-01-20 | 深圳先进技术研究院 | 一种基于图像数据的封装方法及*** |
CN105681322A (zh) * | 2016-02-24 | 2016-06-15 | 清德智体(北京)科技有限公司 | 一种网络流媒体的帧数据获取方法 |
CN105991223A (zh) * | 2015-02-13 | 2016-10-05 | Tcl集团股份有限公司 | 一种tcp网络传输数据中防粘包的方法及*** |
CN107040549A (zh) * | 2017-06-08 | 2017-08-11 | 山大鲁能信息科技有限公司 | 一种tcp粘包处理方法、服务器及*** |
CN107135167A (zh) * | 2017-04-19 | 2017-09-05 | 畅捷通信息技术股份有限公司 | 数据传输方法、数据传输装置和服务器 |
CN107241436A (zh) * | 2017-07-18 | 2017-10-10 | 山东亚华电子股份有限公司 | 一种tcp网络高速粘包传输及存储的方法 |
CN109257355A (zh) * | 2018-09-26 | 2019-01-22 | 郑州云海信息技术有限公司 | 一种基于tcp协议数据传输方法、***及相关组件 |
CN111724262A (zh) * | 2020-06-24 | 2020-09-29 | 上海金仕达软件科技有限公司 | 一种应用服务器后续包查询***及其工作方法 |
CN112702322A (zh) * | 2020-12-17 | 2021-04-23 | 中国电子科技集团公司第四十一研究所 | 一种用于产线智能管理的通信数据包异常处理方法 |
CN114125081A (zh) * | 2021-10-27 | 2022-03-01 | 桂林长海发展有限责任公司 | 一种接收数据的处理方法、装置及存储介质 |
CN114546922A (zh) * | 2020-11-27 | 2022-05-27 | 新疆金风科技股份有限公司 | 用于风电场的串口通信方法及装置 |
-
2010
- 2010-01-20 CN CN201010034290A patent/CN101753586A/zh active Pending
Cited By (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102325010A (zh) * | 2011-09-13 | 2012-01-18 | 浪潮(北京)电子信息产业有限公司 | 一种避免数据粘包的处理装置及方法 |
CN103023602A (zh) * | 2011-09-20 | 2013-04-03 | 镇江雅迅软件有限责任公司 | 一种基于Socket协议的数据传输容错*** |
CN102984253B (zh) * | 2012-11-27 | 2015-10-14 | 山东中创软件工程股份有限公司 | 一种传输控制协议粘包处理方法及装置 |
CN102984253A (zh) * | 2012-11-27 | 2013-03-20 | 山东中创软件工程股份有限公司 | 一种传输控制协议粘包处理方法及装置 |
CN103532668A (zh) * | 2013-10-12 | 2014-01-22 | 成都阜特科技股份有限公司 | 一种确保tcp通信数据完整及正确的方法 |
CN103532668B (zh) * | 2013-10-12 | 2016-11-23 | 成都阜特科技股份有限公司 | 一种确保tcp通信数据完整及正确的方法 |
CN104917732A (zh) * | 2014-03-13 | 2015-09-16 | 深圳市赛格导航科技股份有限公司 | 一种多客户端绑定编码器及解码器的方法及*** |
CN104917732B (zh) * | 2014-03-13 | 2018-07-20 | 深圳市赛格导航科技股份有限公司 | 一种多客户端绑定编码器及解码器的方法及*** |
CN104410613A (zh) * | 2014-11-20 | 2015-03-11 | 广西大学 | 一种处理传输控制协议粘包方法及装置 |
CN105991223A (zh) * | 2015-02-13 | 2016-10-05 | Tcl集团股份有限公司 | 一种tcp网络传输数据中防粘包的方法及*** |
CN105262970A (zh) * | 2015-10-14 | 2016-01-20 | 深圳先进技术研究院 | 一种基于图像数据的封装方法及*** |
CN105262970B (zh) * | 2015-10-14 | 2018-12-04 | 深圳先进技术研究院 | 一种基于图像数据的封装方法及*** |
CN105681322A (zh) * | 2016-02-24 | 2016-06-15 | 清德智体(北京)科技有限公司 | 一种网络流媒体的帧数据获取方法 |
CN105681322B (zh) * | 2016-02-24 | 2019-08-23 | 清德智体(北京)科技有限公司 | 一种网络流媒体的帧数据获取方法 |
CN107135167A (zh) * | 2017-04-19 | 2017-09-05 | 畅捷通信息技术股份有限公司 | 数据传输方法、数据传输装置和服务器 |
CN107040549A (zh) * | 2017-06-08 | 2017-08-11 | 山大鲁能信息科技有限公司 | 一种tcp粘包处理方法、服务器及*** |
CN107040549B (zh) * | 2017-06-08 | 2021-03-19 | 山大鲁能信息科技有限公司 | 一种tcp粘包处理方法、服务器及*** |
CN107241436A (zh) * | 2017-07-18 | 2017-10-10 | 山东亚华电子股份有限公司 | 一种tcp网络高速粘包传输及存储的方法 |
CN109257355A (zh) * | 2018-09-26 | 2019-01-22 | 郑州云海信息技术有限公司 | 一种基于tcp协议数据传输方法、***及相关组件 |
CN111724262A (zh) * | 2020-06-24 | 2020-09-29 | 上海金仕达软件科技有限公司 | 一种应用服务器后续包查询***及其工作方法 |
CN111724262B (zh) * | 2020-06-24 | 2024-03-22 | 上海金仕达软件科技股份有限公司 | 一种应用服务器后续包查询***及其工作方法 |
CN114546922A (zh) * | 2020-11-27 | 2022-05-27 | 新疆金风科技股份有限公司 | 用于风电场的串口通信方法及装置 |
CN114546922B (zh) * | 2020-11-27 | 2024-05-31 | 金风科技股份有限公司 | 用于风电场的串口通信方法及装置 |
CN112702322A (zh) * | 2020-12-17 | 2021-04-23 | 中国电子科技集团公司第四十一研究所 | 一种用于产线智能管理的通信数据包异常处理方法 |
CN114125081A (zh) * | 2021-10-27 | 2022-03-01 | 桂林长海发展有限责任公司 | 一种接收数据的处理方法、装置及存储介质 |
CN114125081B (zh) * | 2021-10-27 | 2023-09-22 | 桂林长海发展有限责任公司 | 一种接收数据的处理方法、装置及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101753586A (zh) | 发送数据的方法、接收数据的处理方法和装置 | |
CN108965484B (zh) | 一种物联网数据的传输方法、***及终端 | |
CN104539739B (zh) | 一种文件上传的***、方法及装置 | |
CN109905205B (zh) | 数据发送、接收的方法及设备、数据传输方法及*** | |
CN102480462B (zh) | 通用协议适配方法及装置 | |
US7355992B2 (en) | Relay for extended range point-to-point wireless packetized data communication system | |
CN111083161A (zh) | 数据传输的处理方法及装置、物联网设备 | |
CN101217429B (zh) | 基于tcp时间戳选项确定tcp报文之间的引发关系的方法 | |
CN106452688A (zh) | 一种北斗数据缺报重传方法及*** | |
CN110418376A (zh) | 数据传输方法及装置 | |
CN104025550B (zh) | 从数据项获得信息的方法及装置 | |
WO2009021417A1 (fr) | Procédé, système et dispositif de transmission et de réception de données de réseau | |
WO2018018627A1 (zh) | 一种数据传输方法、***及接收装置 | |
CN110213756A (zh) | 一种数据传输方法、装置及其相关设备 | |
CN105791154A (zh) | 一种基于udp的数据传输方法及装置 | |
CN103795518A (zh) | 一种设备间端口模式同步方法、设备及*** | |
CN112787902B (zh) | 报文封装方法及装置、报文解封装方法及装置 | |
CN105635802A (zh) | 一种数字媒体数据的传输方法及装置 | |
EP3672189B1 (en) | Data transmission method, device and system | |
CN107508828A (zh) | 一种超远程数据交互***及方法 | |
CN110248379A (zh) | 无线局域网中基站的性能测试方法及装置 | |
CN105763375A (zh) | 一种数据包发送方法、接收方法及微波站 | |
CN105915930A (zh) | 一种视频文件发送方法及装置 | |
CN104868973A (zh) | 数据完整性校验方法和*** | |
US9762353B2 (en) | Data packet for bidirectional transmission of data packets during data transmission between a first and a second communication appliance, and method for transmitting such a data packet |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20100623 |