一种数据处理方法及系统.pdf

一种数据处理方法及系统
技术领域
本申请涉及计算机技术领域，尤其涉及一种数据处理方法及系统。
背景技术
随着互联网技术的不断发展，越来越多的用户习惯于通过网络获取各种网络资源，比如在线观看娱乐视频、获取教育资料，多用户进行聊天等。
要实现多用户的交互和信息共享，现有的技术就是使用通用的标准协议来实现。而现在通用的协议比较大的问题是使冗余数据多，无论什么类型的消息，格式只有固定的几种。比如通用的超文本传输协议(Hyper Text Transfer Protocol，HTTP)，只有请求和响应两种协议定义，这两类消息中都有通用头，请求头/响应头，实体头，数据体。实际上，不同类型的消息需要携带的信息一般不同。但因为http是通用的协议，消息要遵循其固有的格式，即使不需要的信息也会携带，导致冗余数据多，封包需要较多的计算消耗，所以会影响传输有效信息的效率。
发明内容
本申请实施例提供一种数据处理方法及系统，用以提高对数据处理的灵活性，从而提高数据传输效率。
本申请实施例提供的一种数据处理方法，包括：
发送方向接收方发送请求消息；并
接收所述接收方根据所述请求消息返回的响应消息；
其中，所述请求消息和响应消息均是基于自定义协议的消息，所述请求消息和响应消息中均携带所述自定义协议的协议头，所述协议头中包括有消息长 度字段和操作类型字段，所述自定义协议用于点到点数据交互场景，基于自定义协议的消息中不包含冗余数据。
本申请实施例提供的一种数据处理系统，包括：
发送方，用于发送请求消息；
接收方，用于接收请求消息并根据所述请求消息返回响应消息；
其中，所述请求消息和响应消息均是基于自定义协议的消息，所述请求消息和响应消息中均携带所述自定义协议的协议头，所述协议头中包括有消息长度字段和操作类型字段，所述自定义协议用于点到点数据交互场景，基于自定义协议的消息中不包含冗余数据。
本申请实施例提供的一种数据处理方法及系统，该方法通过发送方向接收方发送请求消息；并接收所述接收方根据所述请求消息返回的响应消息；其中，所述请求消息和响应消息均是基于自定义协议的消息，所述请求消息和响应消息中均携带所述自定义协议的协议头，所述协议头中包括有消息长度字段和操作类型字段，基于自定义协议的消息中不包含冗余数据。这样，发送方和接收方之间传输的每一个消息(请求消息或响应消息)都是基于自定义协议的消息，该自定义协议的消息中不包含冗余数据，从而可有效提高数据传输效率。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1为本申请实施例提供的一种数据处理方法流程示意图；
图2为本申请实施例提供的一种数据交互方法流程示意图；
图3为本申请实施例提供的另一种数据交互方法流程示意图；
图4为本申请实施例提供的另一种数据交互方法流程示意图；
图5为本申请实施例提供的一种数据处理系统示意图；
图6为本申请实施例提供的一种数据处理系统示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，以下将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
参见图1，为本申请实施例提供的一种数据处理方法，包括以下步骤：
S101：发送方向接收方发送请求消息。
在申请实施例中，所述的发送方和接收方可以是：客户端、调度代理服务器、调度服务器、中心机、和服务均衡器等中的任意两个。比如，发送方为客户端，接收方为调度代理服务器。
在本申请实施例中，所述发送方发送的请求消息根据业务场景的不同而不同。比如，在点到点数据交互场景中，发送方需要下载资源时，往往会涉及到与接收方进行注册、登录、种子下载、资源下载等过程，则所述的请求消息可以是注册类请求消息、登录类请求消息、下载类请求消息等；相应的，接收方返回给发送方的响应消息可以是注册类响应消息、登录类响应消息、下载类响应消息等。
在实际应用场景中，无论是请求消息还是响应消息，在传输这些消息的过程中，发送方或接收方均需要按照这些消息中携带的协议头和/或协议体传输消息。
考虑到实际应用场景中，某些类型的请求消息或响应消息的协议中可能不需要协议体而只需要协议头。因此，在本申请实施例中，针对不需要协议体的请求消息和响应消息，该请求消息和响应消息中仅携带自定义协议的协议头，其中，该协议头中包括消息长度字段(Length字段)和操作类型字段(OpType 字段)。
考虑到在实际应用场景中，由于不同类型的请求消息或响应消息对应的协议头或协议体中需要承载的数据不完全相同，因此，往往会存在协议头或协议体中的有些字段是不需要承载数据的，即该字段相对于当前待发送数据是冗余字段。但是，在现有技术中，针对不同类型的请求消息或响应消息，采用固定格式(统一格式)的协议，即所有类型的请求消息或响应消息的协议头和协议体的格式完全相同，这就使得发送方在传输消息时，可能将冗余格式也传输给接收方，从而降低数据传输效率。
因此，本申请实施例请求消息和响应消息为基于自定义协议的消息，基于自定义协议的消息中不包含冗余数据；其中，不包含冗余数据的消息为：该消息不包含冗余协议格式，或者，协议格式中不包含冗余数据。如，协议头或协议体中不包含与当前消息无关的字段(简称，冗余字段)，或者字段中不包含冗余内容，显然，相比较现有技术，基于固定格式的消息(即不同消息的协议格式相同)，可有效提高数据传输效率。
其中，该Length字段用于说明该请求消息或响应消息的长度。
例如，假设请求消息或响应消息的自定义协议的协议头为P2P协议头(简称P2P_HEAD)，则P2P_HEAD的格式如表1所示。
P2P_HEAD:

字段 Length OpType 类型 整型(Int) Int 字节长度 2/4 2
表1
由表1可知，P2P_HEAD中包括Length字段和OpType字段，这两个字段的类型均为整型，Length字段的字节长度可以为2字节或4字节，一般情况下，Length字段的字节长度为2字节，但是对于长度较长的消息，Length字段可以为4字节。
当然，该协议头中还可包括每一个字段的描述内容，如，Length字段的描述内容为“整个协议的长度，包括协议头长度”。
S102：发送方接收所述接收方根据所述请求消息返回的响应消息。
在本申请实施例中，当接收方接收到发送方的请求消息后，会向发送方返回基于该请求消息的响应消息，则发送方可接收该接收方根据请求消息返回的响应消息。
其中，为了提高数据传输效率，该响应消息同样是基于自定义协议的消息，该响应消息中携带自定义协议的协议头，该协议头中同样包括有Length字段和OpType字段。其中，响应消息中的协议头(如Length字段和OpType字段)在上述步骤S101中已经说明，这里不再赘述。
上述图1所示的方法，通过发送方向接收方发送请求消息；并接收所述接收方根据所述请求消息返回的响应消息；其中，所述请求消息和响应消息均是基于自定义协议的消息，所述请求消息和响应消息中均携带所述自定义协议的协议头，所述协议头中包括有Length字段和OpType字段。可见，本申请实施例中的请求消息和响应消息中仅携带协议头，且该协议头中仅包括Length字段和OpType字段。而在现有技术中，请求消息和响应消息中的协议头中至少包括通用头、请求头/响应头、实体头等，且无论是否需要协议体，请求消息和响应消息中均携带有协议体(即数据体)。显然，本申请实施例发送方和接收方之间传输的请求消息或响应消息的协议头中没有通用头，请求头/响应头，实体头等这些冗余数据，相应的，请求消息或响应消息中就没有所述的冗余数据，从而可有效提高数据传输效率。
考虑到实际应用场景中，比如，点到点数据交互场景中，可能存在发送方发送的请求数据和接收方接收到的请求数据不一致，或者，接收方返回的响应数据和发送方接收到的响应数据不一致的情况，这样，就会导致发送方或接收方接收到的数据的可靠性较低的问题。
因此，在本申请实施例中，所述请求消息或响应消息中的协议头还可包括 校验字段(如，Mark字段)。
所述的校验字段用于指示发送方(或接收方)接收到消息后，根据该校验字段对该消息进行校验，当校验结果正确时，确定消息正确，可执行后续数据处理过程，否则，确定消息错误，停止执行后续数据处理过程，进一步的，还可以请求接收方(或发送方)再次发送消息。
与上述Length字段和OpType字段相类似，Mark字段也可定义字段名、类型和字节长度等，还可以定义字段的描述内容等。
进一步的，在本申请实施例中，所述请求消息或响应消息中的协议头还可包括保留字段(Reserved字段)，用于扩展使用。
例如，表2所示的P2P_HEAD协议头既包括Length字段和OpType字段，也包括Mark字段和Reserved字段。
P2P_HEAD：
字段 Length Mark OpType Reserved 类型 Int Int Int Int 字节长度 2 4 4 4
表2
由表2可知，各字段的类型为整型Int，Length字段的长度为2字节，其余字段的长度均为4字节。
考虑到实际应用场景中，有些类型的请求消息或响应消息不仅需要携带协议头，还需要携带协议体，比如，针对请求消息或响应消息的内容较多且需要在协议体中携带部分或全部消息时，这就需要在请求消息或响应消息中携带协议体。
因此，在本申请实施例中，针对指定类型的消息(如，登录类请求消息或响应消息、种子资源获取类请求消息或响应消息等)需要同时携带协议头和协议体，该协议体中可包括通用字段和其他字段中的至少一种。
其中，该通用字段可以是复合结构字段(如Buffer字段)，该通用字段一 般用于携带变长数据，所述其他字段至少可包括整型类型字段、字符串类型字段等。
当所述请求消息和/或响应消息中有变长数据时，采用协议体中的通用字段携带该变长数据。
比如，若客户端(发送方)需要向调度代理服务器(接收方)发送添加文件信息请求消息时，这就需要在协议体中携带待添加文件的文件名，以便调度代理服务器根据协议体中的文件名添加文件。那么，该添加文件信息请求消息中除了需要携带上述的协议头，还需要携带协议体，且该协议体中包括通用字段，该通用字段用于携带文件名信息。
例如，若通用字段为Buffer字段时，通用字段Buffer的格式如表3所示。
Buffer：
字段 Buffer长度 Data 类型 Int 字符型(char) 字节长度 2/4 变长
表3
由表3可知，通用字段Buffer为复合结构字段，该复合结构字段包括Buffer长度字段和数据字段(Data字段)；Buffer长度字段的类型为Int，Data字段的类型为字符型(char)，Data字段的字节长度为变长，Buffer长度字段的字节长度可以是2字节或4字节。Buffer长度字段的字节长度可由Data的长度确定。比如，当Data长度在65535字节以内时，Buffer长度所占字节数为2字节，当Data长度超过65535字节时，Buffer长度所占字节数为4字节。
以上从整体上说明了某些类型的请求消息或响应消息仅需要携带协议头，另一些类型的请求消息或相响应消息还需要携带协议体。下面将以具体的场景为例说明。
在本申请实施例中，所述的数据处理方法可应用于资源下载场景，具体的，可应用于网络数据的点到点(P2P)数据交互场景，即，发送方和接收方之间交互 的请求消息或响应消息中的自定义协议，可以用于P2P数据交互场景。
在P2P数据交互场景中，一般的，可包括如图2所示的数据交互过程，该数据交互过程包括如下步骤：
S201：客户端(发送方)向调度代理服务器(接收方)发送登录调度代理服务器请求消息。
S202：客户端成功登录调度代理服务器后，调度代理服务器(发送方)向调度服务器(接收方)发送添加用户信息请求消息，该客户端信息可以是客户端名称、客户端身份标识、客户端版本号等信息。
S203：调度服务器通过调度代理服务器(接收方)向客户端(发送方)返回登录调度代理服务器响应消息。
S204：客户端(发送方)向调度代理服务器(接收方)发送获取种子资源请求消息，将该获取种子资源请求消息作为第一获取种子资源请求消息。
S205：调度代理服务器(发送方)向调度服务器(接收方)转发所述第一获取种子资源请求消息，将该待转发的第一获取种子资源请求消息作为第二获取种子资源请求消息。
需要说明的是，第一获取种子资源请求消息和第二获取种子资源请求消息的区别在于，二者的协议头和/或协议体不完全相同。
S206：调度服务器(接收方)向调度代理服务器(发送方)返回获取种子资源响应消息，将该种子资源响应消息作为第二获取种子资源响应消息。
S207：调度代理服务器(接收方)向客户端(发送方)转发第二获取种子资源响应消息，将该第二获取种子资源响应消息作为第一获取种子资源响应消息。
需要说明的是，第一获取种子资源响应消息和第二获取种子资源响应消息的区别在于，二者的协议头和/或协议体不完全相同。
S208：客户端(发送方)向服务均衡器(接收方)发送获取注册信息请求消息(请求消息)。
S209：客户端接收服务均衡器根据获取注册信息请求消息返回的获取注册信息响应消息。
S210：客户端(发送方)向服务均衡器(接收方)发送测速请求消息。
S211：服务均衡器(接收方)向客户端(发送方)返回测速响应消息。
上述图2中，步骤S201和步骤S203中的登录调度代理服务器请求消息和登录调度代理服务器响应消息，均是基于自定义协议的消息，且均携带自定义协议的协议头和协议体；各协议头中包括有消息长度字段和操作类型字段和/或校验字段。
登录调度代理服务器请求消息中的协议体包括：两个通用字段和四个整型字段；其中，两个通用字段分别表示客户端注册实时媒体流协议服务器生成的字符串和所要获取的文件名，四个整型字段分别表示协议版本号、网络地址转换NAT类型、公网互联网协议(Internet Protocol，IP)地址、内网IP地址；登录调度代理服务器响应消息中的协议体包括：一个用于表示用户标识的整型字段。
例如，上述的登录调度代理服务器请求消息中的协议头和协议体的格式如表4所示。P2P_PROXY_AND_CLIENT_LOGIN：
字段 P2P_HEAD PeerID Name Version NAT OutIP InIP 类型 P2P_HEAD Buffer Buffer Int Int Int Int 字节长度 复合 复合 复合 4 2 4 4
表4
由表4可知，P2P_HEAD字段为协议头，其余字段为协议体；其中，P2P_HEAD字段的类型为表1或表2中所示的P2P_HEAD协议头，PeerID字段的类型为表3所示的Buffer字段(即通用字段)，该PeerID字段表示客户端注册实时媒体流协议服务器生成的字符串；Name字段的类型为表3所示的Buffer字段，该Name字段表示所看的直播名或者所点播的文件名；Version字段表示协议版本号；NAT字段表示网络地址转换NAT类型；OutIP字段表示公网IP地址；InIP字段表示内网IP地址；其中，Version字段、NAT字段、 OutIP字段和InIP字段的类型为整型Int，且Version字段、OutIP字段和InIP字段的字节长度为4字节，NAT字段的字节长度为2字节。表4中，前三个字段的字节长度为复合长度(Complex)，复合长度是指对应复合结构字段中各字段的字节长度之和，例如，针对P2P_HEAD字段，该复合长度为表1或表2所示的P2P_HEAD中各字段的字节长度之和；又例如，针对PeerID字段或Name字段，复合长度为表3所示的Buffer中各字段的字节长度之和。
例如，上述的登录调度代理服务器响应消息中的协议头和协议体的格式，如表5所示。
P2P_PROXY_AND_CLIENT_LOGIN_BACK：
字段 P2P_HEAD P2PID 类型 P2P_HEAD Int 字节长度 Complex 4
表5
在表5中，P2P_HEAD字段为协议头，类型为P2P_HEAD协议头，其字节长度为Complex；P2PID字段为协议体，类型为Int，字节长度为4字节，该P2PID字段表示客户端在P2P系统中的用户标识。
上述图2中，步骤S202中的添加用户信息请求消息是基于自定义协议的消息，且携带自定义协议的协议头和协议体；协议头中包括有消息长度字段、操作类型字段和/或校验字段。
添加用户信息请求消息中的协议体包括：九个整型字段和一个通用字段；其中，九个整型字段分别表示所述添加用户的终端类型、用户标识、所登录的调度代理服务器的IP地址、用户内网IP地址、用户外网IP地址、运营商标识、区域标识、网络地址转换Nat类型、协议版本号；所述添加用户信息请求消息中的通用字段表示注册实时流媒体协议服务器生成的字符串。
例如，添加用户信息请求消息中的协议头和协议体的格式如表6所示。
P2P_PROXY_AND_TRACK_ADDUSER：
字段 类型 字节长度
P2P_HEAD P2P_HEAD Complex EndType Int 4 P2PID Int 4 调度代理IP Int 4 InIP Int 4 OutIP Int 4 SP Int 2 Region Int 2 NAT Int 2 PeerID Buffer Complex Version Int 4
表6
在表6中，P2P_HEAD字段为协议头，其余字段为协议体。EndType字段表示所添加用户的终端类型，P2PID表示用户标识；调度代理IP表示所登录的调度代理服务器的IP地址；InIP表示用户内网IP地址；OutIP表示用户外网IP地址；SP表示运营商标识；Region表示区域标识；NAT表示网络地址转换NAT类型；Version表示协议版本号；PeerID表示注册实时流媒体协议服务器生成的字符串。
上述图2中，步骤S204中的第一获取种子资源请求消息，以及步骤S207中的第一获取种子资源响应消息均是基于自定义协议的消息，且均携带自定义协议的协议头和协议体；各协议头中包括有消息长度字段、操作类型字段和/或校验字段。
所述的第一获取种子资源请求消息中的协议体包括：一个用于表示文件名信息的通用字段。所述的第一获取种子资源响应消息中的协议体包括：一个表示文件名信息的通用字段，一个表示客户端种子个数的整型字段和一个种子字段。
例如，第一获取种子资源请求消息中的协议头和协议体的格式如表7所示。
P2P_PROXY_AND_CLIENT_LIVE_PEERS：
字段 P2P_HEAD FILENAME 类型 P2P_HEAD Buffer 字节长度 Complex Complex
表7
在表7中，P2P_HEAD字段为协议头，FILENAME字段为协议体，FILENAME字段表示要操作的文件名，P2P_HEAD字段和FILENAME字段的类型分别为P2P_HEAD和Buffer，字节长度分别为Complex。
又例如，第一获取种子资源响应消息中的协议头和协议体的格式如表8所示。
P2P_PROXY_AND_CLIENT_LIVE_PEERS_BACK：
字段 P2P_HEAD FILENAME PeerCount Peer 类型 P2P_HEAD Buffer Int Peer 字节长度 Complex Complex 4 Complex
表8
在表8中，P2P_HEAD字段为协议头，其余字段为协议体。FILENAME字段表示要操作的文件名，PeerCount字段表示客户端种子个数，Peer字段表示种子字段，用于携带种子信息，该Peer字段是一个如表9所示的复合结构字段。
Peer：
字段 PeerID P2PID 调度代理IP 类型 Buffer Int Int 字节长度 Complex 4 4
表9
在表9中，Peer字段包括：一个通用字段(PeerID字段)和两个整型字段(P2PID和调度代理IP)；其中，PeerID字段表示种子注册实时媒体流协议服 务器生成的字符串，P2PID字段和调度代理IP字段分别表示种子的用户标识和种子所登录的调度代理服务器的IP地址。
在上述图2中，步骤S205中的第一获取种子资源请求消息和步骤S206中的第一获取种子资源响应消息，均是基于自定义协议的消息，且均携带自定义协议的协议头和协议体；各协议头中包括有消息长度字段、操作类型字段和/或校验字段；
所述的第二获取种子资源请求消息中的协议体包括：一个用于表示用户标识的整型字段，一个表示需操作的文件名的通用字段。
所述的第二获取种子资源响应消息中的协议体包括：一个表示文件名信息的通用字段，一个携带种子信息的种子字段，两个整型字段。
针对第二获取种子资源请求消息中的协议体和第二获取种子资源响应消息中的协议体，包括的两个整型字段分别表示用户标识和客户端种子个数，所述种子字段是复合结构字段，所述种子字段包括：一个通用字段和两个整型字段；其中，所述种子字段中的通用字段表示种子注册实时媒体流协议服务器生成的字符串，所述种子字段中的两个整型字段分别表示种子的用户标识和种子所登录的调度代理服务器的IP地址。
例如，所述的第二获取种子资源请求消息中的协议头和协议体的格式如表10所示。
P2P_PROXY_AND_TRACK_LIVE_PEERS：
字段 P2P_HEAD P2PID FILENAME 类型 P2P_HEAD Int Buffer 字节长度 Complex 4 Complex
表10
在表10中，P2P_HEAD字段为协议头，其余字段为协议体。P2PID字段表示用户标识，FILENAME字段表示需操作的文件名。
又例如，第二获取种子资源响应消息中的协议头和协议体的格式，如表11 所示。
P2P_PROXY_AND_TRACK_PEERS_BACK：
字段 P2P_HEAD P2PID FILENAME PeerCount Peer 类型 P2P_HEAD Int Buffer Int Peer 字节长度 Complex 4 Complex 4 Complex
表11
在表11中，P2P_HEAD字段为协议头，其余字段为协议体，在其余字段中，P2PID字段表示用户标识，FILENAME字段表示需操作的文件名；PeerCount字段表示获取的种子资源个数，Peer字段表示种子信息：包括种子注册生成的字符串，种子的用户标识和种子所登录的调度代理服务器的IP地址。
在步骤S208所述的获取注册信息请求消息中不包括协议体，只包括协议头；步骤S209所述的获取注册信息响应消息包括：协议头和协议体。所述的协议体可包括：两个通用字段，这两个通用字段分别表示调度代理服务器登录信息和实时媒体流协议服务器的地址。
需要说明的是，调度代理服务器登录信息用于告知客户端后续在登陆调度代理服务器时所需的调度代理登录信息。实时媒体流协议服务器的地址用于告知客户端后续在注册时所需要的实时媒体流协议服务器的地址。
例如，获取注册信息请求消息中的协议头的格式，如表12所示。
P2P_GETWAY_AND_CLIENT_REGISTER：
字段 P2P_HEAD 类型 P2P_HEAD 字节长度 Complex
表12
又例如，获取注册信息响应消息中的协议头和协议体的格式，如表13所示。
P2P_GETWAY_AND_CLIENT_REGISTER_BACK：
字段 P2P_HEAD Proxy Rtmfp 类型 P2P_HEAD Buffer Buffer 字节长度 Complex Complex Complex
表13
在表13中，P2P_HEAD字段为协议头，Proxy字段和Rtmfp字段为协议体。Proxy字段表示调度代理服务器登录信息；Rtmfp字段表示实时媒体流协议服务器的地址，P2P_HEAD字段的类型为P2P_HEAD，Proxy字段和Rtmfp字段的类型均为Buffer，各字段的字节长度均为复合长度Complex。
在步骤S210所述的测速请求消息和步骤S211所述的测速响应消息均是基于自定义协议的消息，且携带自定义协议的协议头和协议体；各协议头中包括有消息长度字段、操作类型字段和/或校验字段；测速请求消息中的协议体包括：一个表示随机测速数据的通用字段；测速响应消息中的协议体包括：一个表示测速结果的整型字段。
例如，测速请求消息中的协议头和协议体的格式，如表14所示。
P2P_GETWAY_AND_CLIENT_TEST_SPEED：
字段 P2P_HEAD test_data 类型 P2P_HEAD Buffer 字节长度 Complex Complex
表14
在表14中，P2P_HEAD字段为协议头，test_data字段为协议体。test_data字段表示随机测速数据。P2P_HEAD和test_data字段的类型分别为P2P_HEAD和Buffer，字节长度均为Complex。
例如，所述测速响应消息中的协议头和协议体的格式，如表15所示。
P2P_GETWAY_AND_CLIENT_TEST_SPEED_BACK：
字段 P2P_HEAD Speed 类型 P2P_HEAD Int
字节长度 Complex 4
表15
在表15中，P2P_HEAD字段为协议头，Speed字段为协议体，该Speed字段表示测速结果。
在本申请实施例中，若客户端成功获取资源(如文件)之后，可以成为种子客户端供其他客户端下载文件，在成为种子客户端之后，通过请求调度服务器删除文件而退出种子客户端，该过程具体流程如图3所示，图3所示的数据交互可包括如下步骤：
S301：客户端向调度服务器发送添加用户信息之后，客户端(发送方)向调度代理服务器(接收方)发送心跳检测请求消息。调度代理服务器可以不给客户端基于该心跳检测请求消息的响应消息。
S302：若调度代理服务器在设定时间段内未接收到客户端发送的心跳检测请求消息时，调度代理服务器(发送方)可向调度服务器(接收方)发送删除用户信息请求消息，以使得调度服务器删除通过步骤S202添加的用户信息。调度服务器删除用户信息后，可以不返回基于该删除用户信息请求消息的响应消息。
S303：客户端在获取下载的文件之后，客户端(发送方)可向调度代理服务器发送第一添加文件信息请求消息。
S304：调度代理服务器(发送方)可将第一添加文件信息请求消息作为第二添加文件信息请求消息发送给调度服务器(接收方)。
S305：客户端在调度服务器中添加文件后成为种子客户端，客户端(发送方)还可以向调度代理服务器(接收方)发送第一删除文件请求消息。
S306：调度代理服务器(发送方)可将第一删除文件请求消息作为第二删除文件请求消息发送给调度服务器，以使得调度服务器删除添加的文件。
上述图3所示的步骤S301中，心跳检测请求消息是基于自定义协议的消息，且携带自定义协议的协议头和协议体；各协议头中包括有消息长度字段、 操作类型字段和/或校验字段；心跳检测请求消息中的协议体包括：一个整型字段和一个通用字段；其中，所述心跳检测请求消息中的整型字段表示所述心跳检测请求消息中是否有扩展数据，所述心跳检测请求消息中的通用字段表示扩展数据。
例如，心跳检测请求消息中的协议头和协议体，如表16所示。
P2P_HEART：
字段 P2P_HEAD Extend ExData 类型 P2P_HEAD Int Buffer 字节长度 Complex 1 Complex
表16
在表16中，P2P_HEAD字段为协议头，其余字段为协议体。Extend用于表示是否有扩展数据，ExData用于承载扩展数据。
上述图3所示的步骤S302中，删除用户信息请求消息是基于自定义协议的消息，且携带自定义协议的协议头和协议体；各协议头中包括有消息长度字段、操作类型字段和/或校验字段；删除用户信息请求消息中的协议体包括：一个表示用户标识的整型字段。
例如，删除用户信息请求消息中的协议头和协议体的格式，如表17所示。
P2P_PROXY_AND_TRACK_REMOVEUSER：
字段 P2P_HEAD P2PID 类型 P2P_HEAD Int 字节长度 Complex 4
表17
在表17中，P2P_HEAD字段为协议头，P2PID字段为协议体。所述P2PID表示要删除用户的用户标识。
上述图3所示的步骤S303中，第一添加文件信息请求消息是基于自定义协议的消息，且携带自定义协议的协议头和协议体；各协议头中包括有消息长度字段、操作类型字段和/或校验字段；第一添加文件信息请求消息中的协议体包括：一个表示文件名的通用字段和两个整型字段；其中，两个整型字段分别 表示从内容分发网络CDN下载的字节数、从种子客户端下载的字节数。
例如，第一添加文件信息请求消息中的协议头和协议体的格式，如表18所示。
P2P_PROXY_AND_CLIENT_ADDFILE：
字段 P2P_HEAD FILENAME CdnSize PeerSize 类型 P2P_HEAD Buffer Int Int 字节长度 Complex Complex 4 4
表18
在表18中，P2P_HEAD字段为协议头，其余字段为协议体。FILENAME表示要操作的文件名，CdnSize表示从内容分发网络CDN下载的字节数，PeerSize表示从种子客户端下载的字节数。
上述图3所示的步骤S304中，第二添加文件信息请求消息是基于自定义协议的消息，且携带自定义协议的协议头和协议体；各协议头中包括有消息长度字段、操作类型字段和/或校验字段；第二添加文件信息请求消息中的协议体包括：一个表示用户标识的整型字段，一个表示需操作的文件名的通用字段。
例如，第二添加文件信息请求消息中的协议头和协议体的格式，如表19所示。
P2P_PROXY_AND_TRACK_ADDFILE：
字段 P2P_HEAD P2PID FILENAME 类型 P2P_HEAD Int Buffer 字节长度 Complex 4 Complex
表19
在表19中，P2P_HEAD字段为协议头，其余字段为协议体。P2PID表示用户标识，FILENAME表示要操作的文件名。
上述图3所示的步骤S305中，第一删除文件请求消息为基于自定义协议的消息，第一删除文件请求消息携带自定义协议的协议头，协议头中包括有消息长度字段和操作类型字段；该第一删除文件信息请求消息中的协议体包括：一个表示文件名信息的通用字段。
例如，第一删除文件信息请求消息中的协议头和协议体的格式，如表20所示。
P2P_PROXY_AND_CLIENT_REMOVEFILE：
字段 P2P_HEAD FILENAME 类型 P2P_HEAD Buffer 字节长度 Complex Complex
表20
在表20中，P2P_HEAD字段为协议头，FILENAME为协议体。FILENAME表示要删除的文件名。
上述图3所示的步骤S306中，第二删除文件请求消息是基于自定义协议的消息，且携带自定义协议的协议头和协议体；协议头中包括有消息长度字段、操作类型字段和/或校验字段；第二删除文件信息请求消息中的协议体包括：一个表示用户标识的整型字段，一个表示需操作的文件名的通用字段。
例如，所述第二删除文件信息请求消息中的协议头和协议体的格式，如表21所示。
P2P_PROXY_AND_TRACK_REMOVEFILE：
字段 P2P_HEAD P2PID FILENAME 类型 P2P_HEAD Int Buffer 字节长度 Complex 4 Complex
表21
在表21中，P2P_HEAD字段为协议头，其余字段为协议体。P2PID表示用户标识，FILENAME表示要操作的文件名。
在本申请实施例中，为实现服务一致性，中心机会定期检查调度服务器是否正常，若不正常，则会删除不正常调度服务器列表，并更新其他调度服务器的调度服务器列表，该监测和更新过程如图4所示。
图4所示的数据交互过程，具体包括如下步骤：
S401：中心机(发送方)向调度服务器(接收方)发送检查服务是否正常的检查请求消息(请求消息)，以检查调度服务器是否正常。
S402：客户端接收调度服务器根据检查请求消息返回的检查响应消息。
S403：若检查结果为调度服务器故障，则中心机(发送方)向调度代理服务器(接收方)发送更新调度服务器列表的更新请求消息(请求消息)。
S404：中心机接收调度代理服务器根据更新请求消息返回的更新响应消息。
S405：若通过步骤S401检查结果为调度服务器恢复正常，则中心机(发送方)也会向调度代理服务器(接收方)发送更新调度服务器列表的更新请求消息(请求消息)。
S406：调度服务器恢复正常后，中心机(发送方)向调度服务器(接收方)发送操作资源的操作请求消息(请求消息)，以使得调度服务器恢复工作。
S407：中心机接收调度服务器根据操作请求消息返回的操作响应消息。
上述图4所示的步骤S401和S402中，检查请求消息和检查响应消息均是基于自定义协议的消息，且携带自定义协议的协议头和协议体；各协议头中包括有消息长度字段、操作类型字段和/或校验字段；所述检查请求消息中的协议体包括：一个表示所述检查请求消息的发送时间的整型字段；所述检查响应消息中的协议体包括：两个整型字段；分别表示所述调度服务器接收到的检查请求消息中携带的发送时间和启动标识；所述启动标识用于表示所述调度服务器是否为启动后第一次发送检查响应消息。
例如，检查请求消息中的协议头和协议体的格式，如表22所示。
P2P_CONTROL_AND_SERVER_ALIVE：
字段 P2P_HEAD check_sum 类型 P2P_HEAD Int 字节长度 Complex 8
表22
在表22中，P2P_HEAD字段为协议头，check_sum为协议体。该check_sum字段表示检查请求消息的发送时间，可以用毫秒表示。
例如，检查响应消息的协议头和协议体的格式，如表23所示。
P2P_CONTROL_AND_SERVER_ALIVE_Back：
字段名 P2P_HEAD check_sum new_one 类型 P2P_HEAD Int Int 字节长度 Complex 8 1
表23
在表23中，P2P_HEAD字段为协议头，其余字段为协议体。check_sum字段表示调度服务器接收到的检查请求消息中携带的发送时间，new_one字段为启动标识，表示所述服务器是否为启动后第一次发送检查响应消息。
在上述图4中，步骤S403～S405中的更新请求消息和更新响应消息均是基于自定义协议的消息，且携带自定义协议的协议头和协议体；各协议头中包括有消息长度字段、操作类型字段和/或校验字段；所述更新请求消息中的协议体包括：一个表示所述更新请求消息的发送时间的整型字段，一个表示更新后的调度服务器列表的通用字段；所述更新响应消息中的协议体包括：一个表示所述调度代理服务器接收到的更新请求消息中携带的发送时间的整型字段。
例如，更新请求消息中的协议头和协议体的格式，如表24所示。
P2P_CONTROL_AND_PROXY_UPDATE_TRACK：
字段 P2P_HEAD check_sum 调度服务器_key 类型 P2P_HEAD Int Buffer 字节长度 Complex 8 Complex
表24
表24中，P2P_HEAD字段为协议头，其余字段为协议体。其中，check_sum字段表示更新请求消息的发送时间，可以用毫秒表示；调度服务器_key字段表示更新后的调度服务器列表。
例如，更新响应消息中的协议头和协议体的格式如表25所示。
P2P_CONTROL_AND_PROXY_UPDATE_TRACK_Back：


表25
在表25中，P2P_HEAD字段为协议头，check_sum字段为协议体，该check_sum字段表示调度代理服务器接收到的更新请求消息中携带的发送时间。
在上述图4中，步骤S406和S407中的操作请求消息和操作响应消息均是基于自定义协议的消息，且携带自定义协议的协议头和协议体；各协议头中包括有消息长度字段、操作类型字段和/或校验字段；操作请求消息中的协议体包括：两个整型字段；分别表示所述操作请求消息的发送时间和操作类型标识；操作响应消息中的协议体包括：一个整型字段，用以表示所述调度服务器接收到的操作请求消息中携带的发送时间。
例如，操作请求消息中的协议头和协议体的格式，如表26所示。
P2P_CONTROL_AND_TRACK_DOIT：
字段 P2P_HEAD check_sum Op 类型 P2P_HEAD Int Int 字节长度 Complex 8 1
表26
在表26中，P2P_HEAD字段为协议头，其余字段为协议体。check_sum字段表示操作请求消息的发送时间，可以用毫秒表示；Op为操作类型标识，表示是清除资源还是开始接收服务代理的数据。
例如，操作响应消息中的协议头和协议体的格式，如表27所示。
P2P_CONTROL_AND_TRACK_DOIT_Back：
字段名 P2P_HEAD check_sum 类型 P2P_HEAD Int 字节长度 Complex 8
表27
在表27中，P2P_HEAD字段为协议头，check_sum字段为协议体。check_sum字段表示调度服务器接收到的操作请求消息中携带的发送时间。
以上为本申请实施例提供的数据处理方法，基于同样的思路，本申请实施例还提供了一种数据处理系统，如图5所示。
本申请实施例提供的一种数据处理系统，包括：
发送方51，用于发送请求消息；
接收方52，用于接收请求消息并根据所述请求消息返回响应消息；
其中，所述请求消息和响应消息均是基于自定义协议的消息，所述请求消息和响应消息中均携带所述自定义协议的协议头，所述协议头中包括有消息长度字段和操作类型字段，基于自定义协议的消息中不包含冗余数据。
可选的，所述协议头还包括校验字段。
可选的，所述请求消息和/或响应消息还包括协议体，所述协议体中包括通用字段和其他字段中的至少一种。
可选的，当所述请求消息和/或响应消息中有变长数据时，采用所述协议体中的通用字段携带所述变长数据，其中，所述通用字段为复合结构字段。
可选的，所述自定义协议用于点到点数据交互场景。
在本申请实施例中，图5所示的数据处理系统可包括如图6所示的多个设备，具体包括：客户端61、调度代理服务器62、调度服务器63、中心机64、和服务均衡器65，任意一个设备只要接收消息就为接收方，只要发送消息就为发送方，即，任意一个设备可能既是图5所示的发送方51，又是图5所示的接收方52。
综上所述，本申请实施例提供一种数据处理方法和系统，具体的，发送方向接收方发送请求消息；并接收所述接收方根据所述请求消息返回的响应消息；其中，所述请求消息和响应消息均是基于自定义协议的消息，所述请求消息和响应消息中均携带所述自定义协议的协议头，所述协议头中包括有消息长度字段和操作类型字段。这样，发送方和接收方之间传输的每一个消息(请求消息或响应消息)都是自定义协议的消息，该自定义的协议格式灵活，且协议中没有冗余数据，相应的，该包括该协议的消息中就没有与该协议相关的冗余 数据，从而可有效提高数据传输效率。同时也保留有扩展字段，具有良好的扩展性。
综上所述，本申请实施例提供的一种数据处理方法及系统，该方法通过发送方向接收方发送请求消息；并接收所述接收方根据所述请求消息返回的响应消息；其中，所述请求消息和响应消息均是基于自定义协议的消息，所述请求消息和响应消息中均携带所述自定义协议的协议头，所述协议头中包括有Length字段和OpType字段。可见，本申请实施例中的请求消息和响应消息中仅携带协议头，且该协议头中仅包括Length字段和OpType字段。而在现有技术中，请求消息和响应消息中的协议头中至少包括通用头，请求头/响应头，实体头等，且无论是否需要协议体，请求消息和响应消息中均携带有数据体。显然，本申请实施例发送方和接收方之间传输的请求消息或响应消息的协议头中没有通用头，请求头/响应头，实体头等这些冗余数据，相应的，请求消息或响应消息中就没有所述的冗余数据，从而可有效提高数据传输效率。
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包括有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设 备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包括”或者其任何其他变体意在涵盖非排他性的包括，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括 一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包括有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包括在本申请的权利要求范围之内。