CN107819599A - 报文处理方法及装置 - Google Patents

报文处理方法及装置 Download PDF

Info

Publication number
CN107819599A
CN107819599A CN201610823177.0A CN201610823177A CN107819599A CN 107819599 A CN107819599 A CN 107819599A CN 201610823177 A CN201610823177 A CN 201610823177A CN 107819599 A CN107819599 A CN 107819599A
Authority
CN
China
Prior art keywords
request message
alive
message
server
judging
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.)
Granted
Application number
CN201610823177.0A
Other languages
English (en)
Other versions
CN107819599B (zh
Inventor
叶旭
顾春花
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
Nanjing ZTE New Software Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Nanjing ZTE New Software Co Ltd filed Critical Nanjing ZTE New Software Co Ltd
Priority to CN201610823177.0A priority Critical patent/CN107819599B/zh
Publication of CN107819599A publication Critical patent/CN107819599A/zh
Application granted granted Critical
Publication of CN107819599B publication Critical patent/CN107819599B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0246—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
    • H04L41/0266—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols using meta-data, objects or commands for formatting management information, e.g. using eXtensible markup language [XML]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays

Abstract

本发明提供了一种报文处理方法及装置，其中，该方法包括：接收客户端发送的请求报文；判断请求报文是否支持在处理过程中进行中间保活；在判断出请求报文支持在处理过程中进行中间保活的情况下，判断达到预设时间时服务器是否未处理完请求报文；在判断出达到预设时间时服务器未处理完请求报文的情况下，向客户端返回报文处理未结束的中间保活报文。通过本发明，解决了客户端为了判断服务器是否异常而设置等待响应的超时时间，造成的一些需要长时间处理的请求无法正常执行的问题。

Description

报文处理方法及装置
技术领域
本发明涉及通信领域，具体而言，涉及一种报文处理方法及装置。
背景技术
NETCONF是一种提供网络数据设备配置管理的协议，采用可扩展标记语言(XML)传递数据以及协议信息。NETCONF协议分成四层，包括：内容层(Content)、操作层(Operations)、RPC(Remote Process Call，简称为远程过程调用)层、传输协议(TransportProtocol)层。
RPC层为RPC模块的编码提供了一个简单的、与传输协议无关的机制，通过使用<rpc>和<rpc-reply>元素对NETCONF协议的客户端(网络管理者或网络配置应用程序)和服务器端(网络设备)的请求和响应数据进行封装，正常情况下<rpc-reply>元素封装客户端所需的数据或配置成功的提示信息。当客户端请求报文存在错误或服务器端处理失败时，服务器端会在<rpc-reply>元素中封装一个包含详细错误信息的<rpc-error>元素来反馈给客户端。
NETCONF协议规定每一个客户端的RPC请求，只会返回一个相应的服务器<rpc-reply>。然而，针对客户端发送的RPC请求，服务器端可能需要占用较长时间来处理。例如，配置大批量的数据，或者是查询的数据信息量很大，耗时会很长，此时，就会出现服务器在较长的一段时间内无法响应客户端，即无法回复<rpc-reply>报文。此时，客户端无法判断服务器是在处理中，还是服务器已经出现了异常，比如出现故障了。因此，有些客户端会设置等待响应的超时时间，如果在规定时间内，服务器未给客户端响应报文，那么客户端就认为处理超时了，这样就会导致一些需要长时间处理的请求无法正常执行。
如图1所示，NETCONF协议装置在处理RPC请求时的交互流程如下：
步骤S102`，NETCONF协议客户端向NETCONF协议服务器发起RPC-Request(即RPC请求报文)；
步骤S104`，NETCONF协议服务器处理上述RPC-Request后，给NETCONF协议客户端返回处理结果，即RPC-Reply(即RPC响应报文)。
可见，传统的NETCONF协议装置对于一个RPC-Request只会响应一个RPC-Reply。
发明内容
本发明提供了一种报文处理方法及装置，以至少解决相关技术中客户端为了判断服务器是否异常而设置等待响应的超时时间，造成的一些需要长时间处理的请求无法正常执行的问题。
根据本发明的一个方面，提供了一种报文处理方法，包括：接收客户端发送的请求报文；判断上述请求报文是否支持在处理过程中进行中间保活；在判断出上述请求报文支持在处理过程中进行中间保活的情况下，判断达到预设时间时服务器是否未处理完上述请求报文；在判断出达到上述预设时间时上述服务器未处理完上述请求报文的情况下，向上述客户端返回报文处理未结束的中间保活报文。
进一步地，在向上述客户端返回用于提醒处理未结束的中间保活报文之后，上述方法还包括：判断再次达到上述预设时间时上述服务器是否未处理完上述请求报文；在判断出再次达到上述预设时间时上述服务器未处理完上述请求报文的情况下，再次向上述客户端返回上述中间保活报文。
进一步地，在判断达到预设时间时服务器是否未处理完上述请求报文之后，上述方法还包括：在判断出在达到上述预设时间之前上述服务器已处理完上述请求报文的情况下，向上述客户端返回报文处理结束的响应报文。
进一步地，判断上述请求报文是否支持在处理过程中进行中间保活包括：判断上述请求报文中是否含有用于标识支持长处理的操作层参数，其中，若含有，则确定上述请求报文支持在处理过程中进行中间保活，若不含有，则确定上述请求报文不支持在处理过程中进行中间保活。
进一步地，在判断上述请求报文是否支持在处理过程中进行中间保活之后，上述方法还包括：在判断出上述请求报文不支持在处理过程中进行中间保活的情况下，在报文处理超时后向上述客户端发送报文处理超时的错误报文。
根据本发明的另一方面，提供了一种报文处理装置，包括：接收单元，用于接收客户端发送的请求报文；第一判断单元，用于判断上述请求报文是否支持在处理过程中进行中间保活；第二判断单元，用于在判断出上述请求报文支持在处理过程中进行中间保活的情况下，判断达到预设时间时服务器是否未处理完上述请求报文；第一发送单元，用于在判断出达到上述预设时间时上述服务器未处理完上述请求报文的情况下，向上述客户端返回报文处理未结束的中间保活报文。
进一步地，上述装置还包括：第三判断单元，用于在向上述客户端返回用于提醒处理未结束的中间保活报文之后，判断再次达到上述预设时间时上述服务器是否未处理完上述请求报文；第二发送单元，用于在判断出再次达到上述预设时间时上述服务器未处理完上述请求报文的情况下，再次向上述客户端返回上述中间保活报文。
进一步地，上述装置还包括：第三发送单元，用于在判断达到预设时间时服务器是否未处理完上述请求报文之后，在判断出在达到上述预设时间之前上述服务器已处理完上述请求报文的情况下，向上述客户端返回报文处理结束的响应报文。
进一步地，上述第一判断单元包括：判断模块，用于判断上述请求报文中是否含有用于标识支持长处理的操作层参数，其中，第一确定模块，用于在含有的情况下，则确定上述请求报文支持在处理过程中进行中间保活，第二确定模块，用于在不含有的情况下，则确定上述请求报文不支持在处理过程中进行中间保活。
进一步地，上述装置还包括：第四发送单元，用于在判断上述请求报文是否支持在处理过程中进行中间保活之后，在判断出上述请求报文不支持在处理过程中进行中间保活的情况下，在报文处理超时后向上述客户端发送报文处理超时的错误报文。
通过本发明，采用在处理过程中发送中间保活报文以保活需要长处理的请求报文的方式，通过接收客户端发送的请求报文；判断请求报文是否支持在处理过程中进行中间保活；在判断出请求报文支持在处理过程中进行中间保活的情况下，判断达到预设时间时服务器是否未处理完请求报文；在判断出达到预设时间时服务器未处理完请求报文的情况下，向客户端返回报文处理未结束的中间保活报文，解决了客户端为了判断服务器是否异常而设置等待响应的超时时间，造成的一些需要长时间处理的请求无法正常执行的问题，进而达到了既能了解服务器的工作状态，又能避免需要长时间处理的请求无法正常执行的效果。
附图说明
此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
图1是根据相关技术的传统NETCONF协议装置在处理RPC请求时的交互流程图；
图2是根据本发明可选实施例的报文处理方法的流程图；
图3是根据本发明实施例的NETCONF协议装置在建链时的能力交互流程图；
图4是根据本发明可选实施例的报文处理的交互流程图；
图5是根据本发明可选实施例报文处理方法的流程图；
图6是根据本发明可选实施例的报文处理装置的示意图。
具体实施方式
下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。
需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
在本实施例中提供了一种报文处理方法，图2是根据本发明可选实施例的报文处理方法的流程图，如图2所示，该流程包括如下步骤：
步骤S202，接收客户端发送的请求报文；
步骤S204，判断请求报文是否支持在处理过程中进行中间保活；
步骤S206，在判断出请求报文支持在处理过程中进行中间保活的情况下，判断达到预设时间时服务器是否未处理完请求报文；
步骤S208，在判断出达到预设时间时服务器未处理完请求报文的情况下，向客户端返回报文处理未结束的中间保活报文。
此处，客户端和服务器可以是NETCONF协议客户端和服务器；客户端发送的请求报文可以是RPC请求报文。例如，实施时，在客户端向服务器发送的RPC请求报文后，服务器接收RPC请求报文，并判断该RPC请求报文是否支持在处理过程中进行中间保活，尤其是判断该RPC请求报文是否支持在长时间处理过程中进行中间保活，若支持，则进一步判断达到预设时间时服务器是否还未处理完上述RPC请求报文，若是，则向客户端返回报文处理未结束的中间保活报文。
为了计量服务器处理请求报文的时间是否达到预设时间，服务器在接收到请求报文后，可以启动计时器，其中，计时器的计时时间就等于上述预设时间。
通过本发明实施例，采用在处理过程中发送中间保活报文以保活需要长处理的请求报文的方式，通过接收客户端发送的请求报文；判断请求报文是否支持在处理过程中进行中间保活；在判断出请求报文支持在处理过程中进行中间保活的情况下，判断达到预设时间时服务器是否未处理完请求报文；在判断出达到预设时间时服务器未处理完请求报文的情况下，向客户端返回报文处理未结束的中间保活报文，解决了客户端为了判断服务器是否异常而设置等待响应的超时时间，造成的一些需要长时间处理的请求无法正常执行的问题，进而达到了既能了解服务器的工作状态，又能避免需要长时间处理的请求无法正常执行的效果。
可选地，在向客户端返回用于提醒处理未结束的中间保活报文之后，上述方法还包括：判断再次达到预设时间时服务器是否未处理完请求报文；在判断出再次达到预设时间时服务器未处理完请求报文的情况下，再次向客户端返回中间保活报文。
也即，对于需要长时间处理的请求报文而言，为了充分保证请求能够正常执行，在处理过程中，可以返回多次中间保活报文。
可选地，在判断达到预设时间时服务器是否未处理完请求报文之后，上述方法还包括：在判断出在达到预设时间之前服务器已处理完请求报文的情况下，向客户端返回报文处理结束的响应报文。
另外，在向客户端返回中间保活报文之后，在达到预设时间之前若服务器已处理完请求报文，也需要向客户端返回报文处理结束的响应报文。
通过本发明实施例，可以使服务器针对请求报文给出正常的响应报文。
可选地，判断请求报文是否支持在处理过程中进行中间保活包括：判断请求报文中是否含有用于标识支持长处理的操作层参数，其中，若含有，则确定请求报文支持在处理过程中进行中间保活，若不含有，则确定请求报文不支持在处理过程中进行中间保活。
其中，客户端在发送请求报文时，若在请求报文中携带支持长处理的操作层参数，则表明客户端针对该报文支持长时间处理的中间保活；若在请求报文中未携带支持长处理的操作层参数，则表明客户端针对该报文不支持长时间处理的中间保活。
需要说明的是，在本发明实施例中，客户端和服务器都需要具有一种私有能力，即客户端具有解析中间保活报文的能力，服务器具有生成并发送中间保活报文的能力。这种私有能力需要客户端和服务器预先协商。具体地，如图3所示，NETCONF协议客户端和NETCONF协议服务器在建立链接时，会互相向对方发送HELLO报文。如果客户端和服务都是支持对需要长时间处理的请求报文的中间保活，那么它们在发送HELLO报文时，会在报文中携带能够标识上述支持功能的私有能力。例如私有能力的标识为：
http://www.zte.com.cn/zxr10/netconf/capabilities/longrunning-command1.0。
服务器向客户端发送的支持私有能力的HELLO报文举例如下：
<hello xmlns＝"urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:base:1.1</capability>
<capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
<capability>http://www.zte.com.cn/zxr10/netconf/capabilities/longrunning-command1.0</capability>
<capability>http://www.zte.com.cn/zxr10/netconf/schema/rosng/xxx1？module＝xxx-modulexxx1&revision＝2013-11-12</capability>
</capabilities>
<session-id>1</session-id>
</hello>
该HELLO报文携带了支持需要长时间处理的请求报文的中间保活的私有能力的标识，即上述报文中http://www.zte.com.cn/zxr10/netconf/capabilities/longrunning-command1.0所标识的能力。
所述装置客户端向服务端发送的支持所述私有能力的HELLO报文举例如下：
该HELLO报文是携带所述标识支持长处理请求的私有能力的，即上述报文中http://www.zte.com.cn/zxr10/netconf/capabilities/longrunning-command1.0？KeepAliveInterval＝30所标识的能力。其中该能力中携带了可选参数KeepAliveInterval，表示是客户端所要求的保活间隔为30秒，即每30秒服务端给保活一次。如果客户端的HELLO报文中不携带此参数，表示按服务端设定的默认间隔进行保活。
此保活间隔支持由客户端在每个链接建立时在HELLO报文中指定，能更加灵活的适应各客户端的需求，做到不同链接保活时间不同。
可选地，在判断请求报文是否支持在处理过程中进行中间保活之后，上述方法还包括：在判断出请求报文不支持在处理过程中进行中间保活的情况下，在报文处理超时后向客户端发送报文处理超时的错误报文。
通过本发明实施例，在当前的请求报文不支持在处理过程中进行中间保活时，若服务器的处理时间超时，会向客户端发送报文处理超时的错误报文，通知客户端报文处理出错了。
通过以上描述可见，本发明的目的在于解决当服务器处理客户端的请求报文，尤其是需要耗时很长的请求报文时，采用一种机制，如NETCONF协议针对需要长时间处理的请求报文返回中间处理结果的方法，能够在处理过程中给客户端返回中间的处理结果，比如处理正在进行请等待，或者返回处理进度。通过本发明实施例，可以让客户端及时掌握服务器当前的状态，对客户端有很大的操作指导意义。
实施时，本发明采用扩展一种私有能力，用于标识支持长时间处理请求报文并在处理过程中返回中间保活报文的能力，这种能力客户端和服务器是需要协商的，即只有客户端和服务器都支持这种能力才行。在支持这种能力的情况下，服务器接收到客户端发送的需要长时间处理的请求报文时，在处理过程中，如果处理时长已经达到预先设定的等待时间(此等待时间可以由客户端指定，不同的客户端可以根据自身需要设定不同的等待时间，如果客户端不指定，则按服务端默认的等待时间处理)，服务器就会给客户端定时返回中间保活报文，直至处理结束。该方案要求客户端能够支持对中间保活报文的解析以及有相应的处理行为。
下面结合图4、图5和图6对本发明进行详细阐述：
图4是根据本发明可选实施例的报文处理的交互流程图，该流程包括以下步骤：
步骤S402，NETCONF协议客户端(以下简称为客户端)向NETCONF协议服务器(以下简称为服务器)发起RPC-Request，其中，客户端在支持中间保活的情况下，发送给服务器的RPC-Request如果需要占用较长处理时间，那么就会在请求报文中携带上长处理(longrunning-command)的操作层参数；服务器在解析客户端发送的RPC-Request时，如果发现RPC-Request中携带了longrunning-command参数，则认为该请求是支持中间保活的。支持中间保活的RPC-Request报文举例如下(以get操作举例)：
上述报文中携带的longrunning-command参数代表的就是该请求支持在长处理过程中返回中间保活报文，服务器在具有支持长处理请求报文的能力下才能支持对该参数的解析以及相应的处理。
步骤S404，服务器在预设时间内未处理完该RPC-Request，会给客户端发送保活回应报文(即中间保活报文)。如果处理时间很长，那么可能会多次返回保活回应报文。服务器返回保活回应报文的预设时间，可以由客户端在HELLO报文中指定或者按服务端默认值设定。
步骤S406，服务器在处理完该RPC-Request后，给客户端发送报文处理结束的RPC-Reply报文。
通过本实施方式，对于需要长时间处理的RPC请求，NETCONF服务器依据一定的判断原则，即NETCONF客户端支持中间保活以及本次请求是支持长时间处理的，那么NETCONF服务器在处理过程中会定时给NETCONF客户端发送中间保活报文，直至处理结束，返回最终的处理结果。
图5是根据本发明可选实施例报文处理方法的流程图，该流程包括以下步骤：
步骤S502，NETCONF协议客户端(以下简称为客户端)向NETCONF协议服务器(以下简称为服务器)发起RPC-Request；
步骤S504，服务器启动待处理的定时器，定时器的时长即步骤S404中所提到的发送保活报文的预设时间；
步骤S506，服务器在等待步骤S504中启动的定时器定时到预设时间的过程中，如果请求处理结束了，那么进入步骤S514，否则进入步骤S508；
步骤S508，服务器遇到S504中启动的定时器定时到了，会进入S510；
步骤S510，服务器判断本次处理的客户端请求是否是长处理请求；如果是进入步骤S512，否则进入S516；
步骤S512，服务器给客户端返回处理未结束的中间保活报文，中间保活报文格式如下：
<rpc-reply message-id＝"101"sid＝"1"xmlns＝"urn:ietf:params:xml:ns:netconf:base:1.0">
<notfinish/>
</rpc-reply>
客户端需要支持上述保活报文的解析，解析报文中是否携带notfinish这个参数，如果携带，则表示请求报文未处理完成，需要再等待；RPC层上的sid表示中间保活交互包的序列号，该序列号在一个请求报文的多次应答中从1开始编号，依次递增。即如果一个请求报文有多次中间保活报文，那么sid就是1，2，3…这样编号。notfinish是中间保活报文，即回应报文的一个参数，表示请求正在处理，未完成。客户端收到此报文可以对自身的保活定时器进行重置，以及进行界面上的显示处理等。
步骤S514，服务器向客户端返回处理结束的回应报文(即处理结束的响应报文)；
步骤S516，服务器在处理不支持长时间处理的请求时，处理时间又已经超时，此时就给装置的NETCONF客户端返回操作处理超时的错误报文，超时错误报文格式举例如下：
通过本实施方式，判断请求是否是长处理请求，如果是，定时组织保活报文返回客户端，否则按非长处理请求处理。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例的方法。
在本实施例中还提供了一种报文处理装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。
图6是根据本发明可选实施例的报文处理装置的示意图，如图6所示，该装置包括：接收单元602，用于接收客户端发送的请求报文；第一判断单元604，用于判断请求报文是否支持在处理过程中进行中间保活；第二判断单元606，用于在判断出请求报文支持在处理过程中进行中间保活的情况下，判断达到预设时间时服务器是否未处理完请求报文；第一发送单元608，用于在判断出达到预设时间时服务器未处理完请求报文的情况下，向客户端返回报文处理未结束的中间保活报文。
此处，客户端和服务器可以是NETCONF协议客户端和服务器；客户端发送的请求报文可以是RPC请求报文。例如，实施时，在客户端向服务器发送的RPC请求报文后，服务器接收RPC请求报文，并判断该RPC请求报文是否支持在处理过程中进行中间保活，尤其是判断该RPC请求报文是否支持在长时间处理过程中进行中间保活，若支持，则进一步判断达到预设时间时服务器是否还未处理完上述RPC请求报文，若是，则向客户端返回报文处理未结束的中间保活报文。
为了计量服务器处理请求报文的时间是否达到预设时间，服务器在接收到请求报文后，可以启动计时器，其中，计时器的计时时间就等于上述预设时间。
通过本发明实施例，采用在处理过程中发送中间保活报文以保活需要长处理的请求报文的方式，解决了客户端为了判断服务器是否异常而设置等待响应的超时时间，造成的一些需要长时间处理的请求无法正常执行的问题，进而达到了既能了解服务器的工作状态，又能避免需要长时间处理的请求无法正常执行的效果。
可选地，上述装置还包括：第三判断单元，用于在向客户端返回用于提醒处理未结束的中间保活报文之后，判断再次达到预设时间时服务器是否未处理完请求报文；第二发送单元，用于在判断出再次达到预设时间时服务器未处理完请求报文的情况下，再次向客户端返回中间保活报文。
可选地，上述装置还包括：第三发送单元，用于在判断达到预设时间时服务器是否未处理完请求报文之后，在判断出在达到预设时间之前服务器已处理完请求报文的情况下，向客户端返回报文处理结束的响应报文。
可选地，上述第一判断单元包括：判断模块，用于判断请求报文中是否含有用于标识支持长处理的操作层参数，其中，第一确定模块，用于在含有的情况下，则确定请求报文支持在处理过程中进行中间保活，第二确定模块，用于在不含有的情况下，则确定请求报文不支持在处理过程中进行中间保活。
可选地，上述装置还包括：第四发送单元，用于在判断请求报文是否支持在处理过程中进行中间保活之后，在判断出请求报文不支持在处理过程中进行中间保活的情况下，在报文处理超时后向客户端发送报文处理超时的错误报文。
可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。
需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述模块分别位于多个处理器中。
本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的程序代码：接收客户端发送的请求报文；判断请求报文是否支持在处理过程中进行中间保活；在判断出请求报文支持在处理过程中进行中间保活的情况下，判断达到预设时间时服务器是否未处理完请求报文；在判断出达到预设时间时服务器未处理完请求报文的情况下，向客户端返回报文处理未结束的中间保活报文。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：在向客户端返回用于提醒处理未结束的中间保活报文之后，判断再次达到预设时间时服务器是否未处理完请求报文；在判断出再次达到预设时间时服务器未处理完请求报文的情况下，再次向客户端返回中间保活报文。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：在判断达到预设时间时服务器是否未处理完请求报文之后，在判断出在达到预设时间之前服务器已处理完请求报文的情况下，向客户端返回报文处理结束的响应报文。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：判断请求报文中是否含有用于标识支持长处理的操作层参数，其中，若含有，则确定请求报文支持在处理过程中进行中间保活，若不含有，则确定请求报文不支持在处理过程中进行中间保活。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：在判断请求报文是否支持在处理过程中进行中间保活之后，在判断出请求报文不支持在处理过程中进行中间保活的情况下，在报文处理超时后向客户端发送报文处理超时的错误报文。
可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行：接收客户端发送的请求报文；判断请求报文是否支持在处理过程中进行中间保活；在判断出请求报文支持在处理过程中进行中间保活的情况下，判断达到预设时间时服务器是否未处理完请求报文；在判断出达到预设时间时服务器未处理完请求报文的情况下，向客户端返回报文处理未结束的中间保活报文。
可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行：在向客户端返回用于提醒处理未结束的中间保活报文之后，判断再次达到预设时间时服务器是否未处理完请求报文；在判断出再次达到预设时间时服务器未处理完请求报文的情况下，再次向客户端返回中间保活报文。
可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行：在判断达到预设时间时服务器是否未处理完请求报文之后，在判断出在达到预设时间之前服务器已处理完请求报文的情况下，向客户端返回报文处理结束的响应报文。
可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行：判断请求报文中是否含有用于标识支持长处理的操作层参数，其中，若含有，则确定请求报文支持在处理过程中进行中间保活，若不含有，则确定请求报文不支持在处理过程中进行中间保活。
可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行：在判断请求报文是否支持在处理过程中进行中间保活之后，在判断出请求报文不支持在处理过程中进行中间保活的情况下，在报文处理超时后向客户端发送报文处理超时的错误报文。
可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。
显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。
以上仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种报文处理方法，其特征在于，包括：
接收客户端发送的请求报文；
判断所述请求报文是否支持在处理过程中进行中间保活；
在判断出所述请求报文支持在处理过程中进行中间保活的情况下，判断达到预设时间时服务器是否未处理完所述请求报文；
在判断出达到所述预设时间时所述服务器未处理完所述请求报文的情况下，向所述客户端返回报文处理未结束的中间保活报文。
2.根据权利要求1所述的方法，其特征在于，在向所述客户端返回用于提醒处理未结束的中间保活报文之后，所述方法还包括：
判断再次达到所述预设时间时所述服务器是否未处理完所述请求报文；
在判断出再次达到所述预设时间时所述服务器未处理完所述请求报文的情况下，再次向所述客户端返回所述中间保活报文。
3.根据权利要求1所述的方法，其特征在于，在判断达到预设时间时服务器是否未处理完所述请求报文之后，所述方法还包括：
在判断出在达到所述预设时间之前所述服务器已处理完所述请求报文的情况下，向所述客户端返回报文处理结束的响应报文。
4.根据权利要求1所述的方法，其特征在于，判断所述请求报文是否支持在处理过程中进行中间保活包括：
判断所述请求报文中是否含有用于标识支持长处理的操作层参数，其中，
若含有，则确定所述请求报文支持在处理过程中进行中间保活，
若不含有，则确定所述请求报文不支持在处理过程中进行中间保活。
5.根据权利要求1所述的方法，其特征在于，在判断所述请求报文是否支持在处理过程中进行中间保活之后，所述方法还包括：
在判断出所述请求报文不支持在处理过程中进行中间保活的情况下，在报文处理超时后向所述客户端发送报文处理超时的错误报文。
6.一种报文处理装置，其特征在于，包括：
接收单元，用于接收客户端发送的请求报文；
第一判断单元，用于判断所述请求报文是否支持在处理过程中进行中间保活；
第二判断单元，用于在判断出所述请求报文支持在处理过程中进行中间保活的情况下，判断达到预设时间时服务器是否未处理完所述请求报文；
第一发送单元，用于在判断出达到所述预设时间时所述服务器未处理完所述请求报文的情况下，向所述客户端返回报文处理未结束的中间保活报文。
7.根据权利要求6所述的装置，其特征在于，所述装置还包括：
第三判断单元，用于在向所述客户端返回用于提醒处理未结束的中间保活报文之后，判断再次达到所述预设时间时所述服务器是否未处理完所述请求报文；
第二发送单元，用于在判断出再次达到所述预设时间时所述服务器未处理完所述请求报文的情况下，再次向所述客户端返回所述中间保活报文。
8.根据权利要求6所述的装置，其特征在于，所述装置还包括：
第三发送单元，用于在判断达到预设时间时服务器是否未处理完所述请求报文之后，在判断出在达到所述预设时间之前所述服务器已处理完所述请求报文的情况下，向所述客户端返回报文处理结束的响应报文。
9.根据权利要求6所述的装置，其特征在于，所述第一判断单元包括：
判断模块，用于判断所述请求报文中是否含有用于标识支持长处理的操作层参数，其中，
第一确定模块，用于在含有的情况下，则确定所述请求报文支持在处理过程中进行中间保活，
第二确定模块，用于在不含有的情况下，则确定所述请求报文不支持在处理过程中进行中间保活。
10.根据权利要求6所述的装置，其特征在于，所述装置还包括：
第四发送单元，用于在判断所述请求报文是否支持在处理过程中进行中间保活之后，在判断出所述请求报文不支持在处理过程中进行中间保活的情况下，在报文处理超时后向所述客户端发送报文处理超时的错误报文。
CN201610823177.0A 2016-09-13 2016-09-13 报文处理方法及装置 Active CN107819599B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610823177.0A CN107819599B (zh) 2016-09-13 2016-09-13 报文处理方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610823177.0A CN107819599B (zh) 2016-09-13 2016-09-13 报文处理方法及装置

Publications (2)

Publication Number Publication Date
CN107819599A true CN107819599A (zh) 2018-03-20
CN107819599B CN107819599B (zh) 2022-09-30

Family

ID=61601466

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610823177.0A Active CN107819599B (zh) 2016-09-13 2016-09-13 报文处理方法及装置

Country Status (1)

Country Link
CN (1) CN107819599B (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109151160A (zh) * 2018-06-26 2019-01-04 Oppo广东移动通信有限公司 通信方法、装置、移动终端及存储介质
CN110018839A (zh) * 2019-03-27 2019-07-16 联想(北京)有限公司 硬件加速器复用方法和硬件加速装置
CN113965482A (zh) * 2021-10-19 2022-01-21 北京天融信网络安全技术有限公司 基于gRPC的数据传输方法、装置及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100281118A1 (en) * 2009-04-29 2010-11-04 Brett Donahue Maintaining Connections Between Mobile Devices and Servers
US20150382397A1 (en) * 2013-02-19 2015-12-31 Zte Corporation 802.1x access session keepalive method, device, and system
CN105450466A (zh) * 2015-11-10 2016-03-30 浪潮(北京)电子信息产业有限公司 一种icmp请求报文保活控制方法及系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100281118A1 (en) * 2009-04-29 2010-11-04 Brett Donahue Maintaining Connections Between Mobile Devices and Servers
US20150382397A1 (en) * 2013-02-19 2015-12-31 Zte Corporation 802.1x access session keepalive method, device, and system
CN105450466A (zh) * 2015-11-10 2016-03-30 浪潮(北京)电子信息产业有限公司 一种icmp请求报文保活控制方法及系统

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109151160A (zh) * 2018-06-26 2019-01-04 Oppo广东移动通信有限公司 通信方法、装置、移动终端及存储介质
CN110018839A (zh) * 2019-03-27 2019-07-16 联想(北京)有限公司 硬件加速器复用方法和硬件加速装置
CN113965482A (zh) * 2021-10-19 2022-01-21 北京天融信网络安全技术有限公司 基于gRPC的数据传输方法、装置及存储介质
CN113965482B (zh) * 2021-10-19 2023-03-24 北京天融信网络安全技术有限公司 基于gRPC的数据传输方法、装置及存储介质

Also Published As

Publication number Publication date
CN107819599B (zh) 2022-09-30

Similar Documents

Publication Publication Date Title
US10021098B2 (en) Account login method, device, and system
US9491682B2 (en) Wireless routing device, mobile terminal, and management system and method
CN108712485B (zh) 一种物联网设备的资源订阅方法和装置
US8848893B2 (en) Method and apparatus for callback processing in telecommunication capability opening
CN102685203A (zh) 数据资源传输的方法和设备
CN104852919B (zh) 实现门户Portal认证的方法及装置
EP3028437B1 (en) Messaging api over http protocol to establish context for data exchange
CN107426233A (zh) 基于B/S架构的数据通信系统、方法、Web服务器及监控系统
JP2008015593A (ja) 中継装置、プログラム、中継方法及び通信システム
CN104660409B (zh) 集群环境下系统登录的方法和认证服务器集群
CN107819599A (zh) 报文处理方法及装置
CN102594912A (zh) 服务器架构下的数据处理方法、服务器及服务器架构
CN105635124B (zh) 流量控制方法和装置
CN107295003B (zh) 一种数据传输方法、装置及系统
CN108886533B (zh) 加速与主机服务器的连接
US20040040022A1 (en) Method and apparatus for just-in-time provisioning application-related information at a communication device
CN107547289A (zh) 消息传输系统、消息发送方法和装置、接收方法和装置
CN109286665B (zh) 实时移动游戏长链接处理方法及装置
US20230007057A1 (en) Systems and methods to establish service request interactions
CN107113281A (zh) 内容共享的方法、终端、服务器和系统
CN104270364B (zh) 一种超文本传输协议报文处理方法和装置
CN110086893A (zh) 域名解析方法、装置及计算机可读存储介质
CN105119981B (zh) 一种处理报文的方法
CN113452693B (zh) 页面后端的登录方法和装置、存储介质及电子装置
CN113411250B (zh) 一种实时消息处理方法、系统、设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
TA01 Transfer of patent application right

Effective date of registration: 20180417

Address after: 518057 Nanshan District science and technology, Guangdong Province, South Road, No. 55, No.

Applicant after: ZTE Corp.

Address before: Yuhuatai District of Nanjing City, Jiangsu province 210012 Bauhinia Road No. 68

Applicant before: Nanjing Zhongxing New Software Co.,Ltd.

TA01 Transfer of patent application right
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant