WO2019071608A1

WO2019071608A1 - Request processing method and device, and computer-readable storage medium

Info

Publication number: WO2019071608A1
Application number: PCT/CN2017/106169
Authority: WO
Inventors: 裴卫斌; 谭喆; 林大镰; 姚开方
Original assignee: 深圳中兴力维技术有限公司
Priority date: 2017-10-13
Filing date: 2017-10-13
Publication date: 2019-04-18

Abstract

Disclosed in the present invention are a request processing method and device and a computer-readable storage medium, the method comprising: receiving a request sent by a requester in a first protocol format; converting the request from the first protocol format into a second protocol format which may be recognized by a subsystem, the subsystem being used for processing a request; transmitting the request in the second protocol format to the subsystem; obtaining a result for the second protocol format after the subsystem processes the request; converting the result from the second protocol format into the first protocol format; and returning the result to the requester. According to the technical solution of the present invention, the request issued by the requester does not directly reach the subsystem that processes the request, but first needs to be converted into a protocol format which may be recognized by the subsystem, and then is sent to the subsystem for processing; and after the processing result of the subsystem is subjected to protocol format conversion, the result is returned to the requester.

Description

Request processing method, device and computer readable storage medium

[0001] The present invention relates to the field of computer technologies, and in particular, to a request processing method, apparatus, and computer readable storage medium.

Background technique

[0002] With the advancement of national smart city construction, big data resources including audio and video, pictures, and text have grown geometrically. These data are being used more and more and have great application value. However, how to integrate the data in the software systems of different manufacturers for my use, how to better collect data from different data sources, this contradiction has become more and more prominent, we call it the contradiction of data sharing.

[0003] From the perspective of data sharing, the software has the following characteristics:

[0004] 1, the heterogeneity of software: software from different manufacturers, the internal coordination and calling mechanism is different, that is, the communication protocol is different, which constitutes the heterogeneity of the software. The interfaces provided by most manufacturers are either too rigid and cannot be extended, or they provide limited functions and scope. They can only provide SDK (software bursting toolkit) to make secondary bursts to the interface, while SDK mode is limited to operation. The system and the common modules that depend on it are very restrictive.

[0005] 2, security control features: Security control is reflected in rights management, data encryption, intrusion detection, anti-virus and other aspects. Due to heterogeneous problems, poor compatibility of permissions, no consideration of edge issues, etc.; and due to heterogeneous problems, core information needs to be transmitted in clear text; on the Internet side, due to remote procedure call permissions or even server permissions, resulting in various Abnormal host intrusion and illegal module injection problems.

[0006] The above characteristics constitute the biggest bottleneck for software integration and data sharing. Therefore, a new technical solution is needed, which can effectively alleviate the data interaction, the huge burst of software due to software heterogeneity, solve the problem of dependence of the operating system and dependent library version, and effectively improve the conduction of stability. And security control features.

technical problem

The main object of the present invention is to provide a request processing method, apparatus and computer readable storage medium, Designed to overcome the effects of software heterogeneity and smoothly implement data interaction between software.

Problem solution

Technical solution

[0008] In order to achieve the above object, the present invention provides a request processing method, the method comprising: receiving a request of a first protocol format sent by a requester; converting the request from the first protocol format to a child a second protocol format recognizable by the system, the subsystem is configured to process the request; the request of the second protocol format is sent to the subsystem; and the subsystem processes the request to obtain the a result of the second protocol format; converting the result from the second protocol format to the first protocol format; returning the result to the requester.

[0009] Optionally, before the converting the request from the first protocol format to a second protocol format recognizable by the subsystem, the method further includes: performing checksum on the request/ Or authentication, performing the conversion of the request from the first protocol format to a second protocol format recognizable by the subsystem after the checksum/or authentication succeeds.

[0010] Optionally, in the foregoing method, the request is used to apply for a streaming media resource, and the result is an address of the streaming media resource.

[0011] Optionally, the foregoing method, after the processing, by the subsystem, the result of the second protocol format, specifically: the subsystem acquiring the first encapsulation and/or compression format according to the request The streaming media resource, converting the streaming media resource from the first encapsulation and/or compression format to a second encapsulation and/or compression format corresponding to the requestor, and the second encapsulation and/or The address of the streaming media resource in the compressed format is used as the result, so that the requester obtains the streaming media resource according to the address.

[0012] Optionally, the foregoing method, the address of the streaming media resource in the second encapsulation and/or compression format is used as the result, where the requester obtains the content according to the address The streaming media resource specifically includes: after transmitting the streaming media resource with the requester, adding session information in each transmitted resource data.

[0013] In order to achieve the above object, the present invention further provides a request processing apparatus, the apparatus comprising: an interface management module, configured to receive a request of a first protocol format sent by a requester; a system interface module, configured to Transmitting, by the first protocol format, a second protocol format recognizable by a subsystem, the subsystem is configured to process the request, and the system management module sends the request in the second protocol format Giving the subsystem; the subsystem, configured to process the request to obtain a result of the second protocol format; the system management module converting the result from the second protocol format to the first After the protocol format, the system interface module and the interface management module return the result to the requester.

[0014] Optionally, the foregoing apparatus, before the converting the request from the first protocol format to a second protocol format recognizable by a subsystem, the interface management module further performing the request And/or authenticating, after the checksum/or authentication succeeds, the system interface module performs the converting of the request from the first protocol format to a second protocol format recognizable by the subsystem.

[0015] Optionally, in the foregoing device, the request is used to apply for a streaming media resource, and the result is an address of the streaming media resource.

[0016] Optionally, the foregoing apparatus, the subsystem acquires the streaming media resource in a first encapsulation and/or compression format according to the request, and the streaming media resource is used by the first encapsulation and/or Compressing the format into a second encapsulation and/or compression format corresponding to the requestor, using the address of the streaming media resource in the second encapsulation and/or compression format as the result, for the requester to press The address acquires the streaming media resource.

[0017] Optionally, in the foregoing apparatus, the subsystem adds session information in each transmitted resource data after transmitting the streaming media resource with the requester.

[0018] In order to achieve the above object, the present invention also provides a computer readable storage medium storing one or more programs, the one or more programs may be processed by one or more The device is executed to implement the steps of the foregoing method.

[0019] According to the above technical solution, it is known that the request processing method, apparatus, and computer readable storage medium of the present invention have at least the following advantages:

Advantageous effects of the invention

Beneficial effect

[0020] According to the technical solution of the present invention, the request sent by the requester does not directly reach the subsystem that processes the request, but first needs to be converted by the protocol format, converted into a protocol format recognizable by the subsystem, and then sent. The subsystem is processed, and the processing result of the subsystem is also converted into the protocol format and returned to the requester. It can be seen that the conversion of the protocol format overcomes the influence of software heterogeneity between the requester and the subsystem, so that the requester and the requester Request processing and data interaction can be successfully completed between subsystems Brief description of the drawing

DRAWINGS

1 is a block diagram of a request processing apparatus in accordance with an embodiment of the present invention;

2 is a schematic diagram of a request processing device in accordance with an embodiment of the present invention;

3 is a block diagram of a request processing apparatus in accordance with an embodiment of the present invention;

4A is a block diagram of a request processing apparatus in accordance with an embodiment of the present invention; [0024] FIG.

4B is a schematic diagram of a request processing device in accordance with an embodiment of the present invention; [0025] FIG.

FIG. 5 is a flowchart of a request processing method according to an embodiment of the present invention; FIG.

6 is a flow chart of a request processing method according to an embodiment of the present invention.

[0028] The implementation, functional features, and advantages of the present invention will be further described with reference to the accompanying drawings.

Embodiments of the invention

[0029] It is to be understood that the specific embodiments described herein are merely illustrative of the invention.

[0030] In the following description, the suffixes such as "module", "component" or "unit" used to denote an element are merely for the purpose of facilitating the description of the present invention, and have no specific meaning per se. Therefore, "module", "part" or "unit" can be used in combination.

[0031] As shown in FIG. 1, an embodiment of the present invention provides a request processing apparatus. The apparatus of this embodiment includes:

[0032] The interface management module 110 is configured to receive a request of the first protocol format sent by the requester.

[0033] In this embodiment, the type of the first protocol format is not limited, and specifically, HTTP may be adopted.

(Hypertext Transfer Protocol) + JSON (JavaScript Object Marker) format. In this embodiment, the interface management module 110 is located at the uppermost layer of the entire request processing device, and is responsible for the northbound output. The output interface specification can adopt the aforementioned HTTP+JSON.

[0034] The system interface module 120 is configured to convert the request from the first protocol format to a second protocol format recognizable by the subsystem, and the subsystem is configured to process the request.

[0035] In this embodiment, the type of the second protocol format is not limited, and specifically, SIP ( Session Initiation Protocol) or other proprietary format. In this embodiment, the system interface module 120 is responsible for receiving the request message sent by the interface management module 110 and returning the result message to the interface management module 110. Therefore, the system interface module 120 needs to have a protocol conversion function, for example, from HTTP+JSON. The format is converted to SI P or other proprietary format. In this embodiment, the system interface module 120 embodies a process of converting a standard protocol into an internal protocol, and implements a protocol conversion function.

[0036] The system management module 130 sends a request for the second protocol format to the subsystem.

[0037] In this embodiment, the system management module 130 selects a corresponding subsystem according to the converted request message to obtain a corresponding resource file. The system management module 130 is responsible for the management of the entire device, manages the newly added and exited subsystems, and receives the request packets converted by the system interface module 120 and analyzes and processes the request packets, for different request messages. Reasonably dispatched to the corresponding subsystem. The request packet can be classified into a resource query, an alarm query, a media request, a picture query, and the like, and is distributed to different subsystems according to the type of the request message. If the number of requests sent by the requester is multiple, the system management module 130 performs comprehensive feedback after collecting resources from multiple subsystems (for example, the alarm processing subsystem, the image query subsystem, etc.), as shown in FIG. 2 . Shown.

[0038] The subsystem 140 is configured to obtain a result of the second protocol format after processing the request.

[0039] In this embodiment, the number of subsystems is one or more, and is used to process requests for different services. In this embodiment, the subsystem 140 receives the request dispatched by the system management module 130, performs the actual processing, and returns the processing result to the system management module 130. For example, the subsystem can be an alarm management module that obtains an alarm management file and returns to the system management module 130.

[0040] In this embodiment, each subsystem processes only the corresponding item service and acquires the required resource file. After the system management module 130 converts the result from the second protocol format to the first protocol format, the system interface module 120 and the interface management module 110 return the result to the requester.

[0041] The system management module 130 returns the processing result to the system interface module 120 as it is, and the system interface module 120 converts the result message into an HTTP+JSON format and returns it to the interface management module 110. The interface management module 1 10 then returns these results to the original requester in HTTP+JSON format. It can be seen that the design of the interface management module 110 in this embodiment adopts the Restful form. Restful is a relatively mature interface design theory for Internet applications. It uses URLs to locate and point to resources, uses JSON and other formats to represent resource forms, and uses HTTP and other methods to manipulate resources. [0042] According to the technical solution of the embodiment, a complete technical solution for processing a request and allocating a result resource is implemented. Since the outermost interface management module 110 is advertised by means of HTTP+JSON, the external interface is standard and extensible, and there is no need to consider the version dependency problem of the operating system and related modules, that is, not subject to software differences. The influence of structure. Therefore, according to the technical solution of the embodiment, the burst amount and the technical threshold required for acquiring resources are greatly reduced.

[0043] An embodiment of the present invention provides a request processing apparatus, where the apparatus of this embodiment includes:

[0044] The interface management module 110 is configured to receive a request of the first protocol format sent by the requester, request the application for the streaming media resource, and perform verification and/or authentication on the request.

[0045] In this embodiment, the manner of verifying and authenticating is not limited. In this embodiment, an HTTP request for an external resource request is received, and a corresponding function is invoked for authentication and statistics, and the request is subsequently processed after the authentication succeeds. Specifically, after receiving the external HTTP+JSON request protocol, the system interface module 120 may perform source check and statistics on the request protocol, for example, verifying the validity according to the source address, and performing an authentication operation on the request protocol, that is, according to the request. The account information in the judgment determines whether the request should be rejected or allowed. After the validity check and the authentication operation are successful, a user interface admission prompt is generated, and the request is transmitted to the system interface module 120, as shown in FIG. .

[0046] The system interface module 120 is configured to convert the request from the first protocol format to a second protocol format recognizable by the subsystem after the checksum/authentication succeeds, and the subsystem is configured to process the request.

[0047] In this embodiment, the received request, such as the HTTP format, is protocol-converted, converted into a message format that each subsystem can understand, such as SIP or other special format, or a custom message standard of each manufacturer. The converted synonym message is forwarded to the system management module 130 for processing.

[0048] The system management module 130 sends a request for the second protocol format to the subsystem.

[0049] In this embodiment, after the request message is received, the translation and the request are dispatched, and the classification process is performed according to different functions of the request message. For example, the request of the alarm query class is distributed to the alarm subsystem, and the resource query class The request is dispatched to the resource query subsystem, the streaming media class request is dispatched to the streaming media subsystem, and the resulting message is replied to by the respective subsystems. Similarly, the interface management module 110 can integrate wsdl (network service description language) files, and can be dynamically adapted as a client of the network service for some resources that require SOAP (Simple Object Access Protocol) protocol calls.

[0050] The subsystem 140 acquires the streaming media resource in the first encapsulation and/or compression format according to the request, and the streaming media resource The source is converted into a second encapsulation and/or compression format of the corresponding requester by the first encapsulation and/or compression format, and the address of the streaming resource of the second encapsulation and/or compression format is used as a result for the requester to obtain by address Streaming media resources, the result is the address of the streaming media resource.

[0051] In this embodiment, for example, if the requester requests a video resource, then the subsystem can return the URL (address) of a video resource, and the requester can directly access the URL. In this embodiment, streaming media or picture resources, such as audio and video, can be given by encapsulating the URL in the JSON return message. The requester obtains these resources through standard methods such as RTSP (Real Streaming Protocol), RT MP (Real Message Transfer Protocol), HTTP, FTP (File Transfer Protocol), etc. after obtaining the URL of the stream and the picture.

[0052] In this embodiment, for the request for the streaming media resource, the corresponding subsystem providing the streaming media resource needs to have a code stream conversion module, and the module undertakes the resource positioning and dispatching task of the streaming media. As shown in FIG. 4A and FIG. 4B, the resource location is the resource location of the generated streaming media, that is, the URL, and the resource is uniquely indicated by the UR L. After receiving the media resource application message sent by the system management module 130, the module obtains the original stream from the streaming media server, that is, requests the original stream transcoding before the reply to generate the URL of the stream resource. After the URL is generated, it is returned to the system management module 130, and the system management module 130 returns it to the requester as it is. The code stream conversion module then converts the original stream, including media compression format conversion (G711 to AAC, MPEG4 to H.264, etc., G711, ACC, MPEG4, H.264 for different media compression formats), media packetization Conversion, such as TS (Transport Stream) Packet, PS (Program Stream) Packet, FLV (-Streaming Media Format) format, etc., so that streaming media can be decoded and played on different platforms and players. After the requester receives the URL, it can use the various means and protocols such as RTMP, RTSP, HLS (Dynamic Rate Rate Adaptive Technology) to apply for the resource according to the URL. The requester and the subsystem are peer-to-peer, that is, The requester of the media is directly requested to apply the streaming media to the subsystem providing the URL (specifically, the code stream conversion module therein) without passing through other intermediate links of the interface management module and the like. Due to the adoption of standard media negotiation methods and standard media packet formats, the selection conditions for streaming media processing and playback are very broad, further reducing the difficulty of calling the original applicant.

[0053] Throughout the device, the system interface module 120 and the system management module 130 are roughly equivalent to the ESB (Enterprise Service Bus, supporting routing, protocol conversion, message exchange, protocol authentication, security policy, load, etc.) Balance, dynamic access and other functions), they are responsible for protocol conversion, routing, service access and management services.

[0054] After the system management module 130 converts the result from the second protocol format to the first protocol format, the system interface module 120 and the interface management module 110 return the result to the requester.

[0055] The subsystem 140 adds a session f π interest in each transmitted resource data after transmitting the streaming media resource with the requester.

[0056] In this embodiment, the requester receives the streaming media URL and directly requests the streaming media resource through the player, and the application manner may be RTMP, RTSP, etc. according to the return format of the URL. For the security of the video stream transmission control, the technical solution of the embodiment is also considered, mainly by adding an authentication mechanism and an effective period authentication in the negotiation session. For example, in a video negotiation session, session information is added to the RTSP header field to indicate the inconsistency of each session, thereby improving the security of the session.

[0057] As shown in FIG. 5, in an embodiment of the present invention, a request processing method is provided. The method in this embodiment includes:

[0058] Step S510: Receive a request of the first protocol format sent by the requester.

[0059] In this embodiment, the type of the first protocol format is not limited, and specifically, HTTP may be adopted.

(Hypertext Transfer Protocol) + JSON (JavaScript Object Marker) format.

[0060] Step S520: Convert the request from the first protocol format to a second protocol format recognizable by the subsystem, and the subsystem is used to process the request.

[0061] In this embodiment, the type of the second protocol format is not limited, and specifically, a SIP (Session Initiation Protocol) or other proprietary format may be adopted. In this embodiment, this step implements protocol conversion, such as conversion from HTTP+JSON format to SIP or other proprietary format. In this embodiment, the step reflects the process of converting the standard protocol into an internal protocol, and implements the protocol conversion function.

[0062] Step S530, sending a request of the second protocol format to the subsystem.

[0063] In this embodiment, the corresponding subsystem is selected according to the converted request message to obtain the corresponding resource file. Specifically, the request packet after the protocol conversion is received, and the request packet is analyzed and processed, and different request messages are appropriately allocated to the corresponding subsystem. The request packet can be classified into a resource query, an alarm query, a media request, a picture query, and the like, and is distributed to different subsystems according to the type of the request message. If the requester sends more than one request. [0064] Step S540: The subsystem obtains the result of the second protocol format after processing the request.

[0065] In this embodiment, the number of subsystems is one or more, and is used to process requests for different services. In this embodiment, the subsystem performs the actual processing after receiving the dispatch request. For example, the subsystem can be an alarm management module that obtains an alarm management file and returns to the system management module 130.

[0066] In this embodiment, each subsystem processes only the corresponding item service and acquires the required resource file.

[0067] Step S550: The result is converted from the second protocol format to the first protocol format and returned to the requester.

In the present embodiment, for example, the processing result of the subsystem is converted into an HTTP+JSON format and returned to the original requester.

[0069] According to the technical solution of the embodiment, a complete technical solution for processing a request and allocating a result resource is implemented. Since the received request format can be, for example, HTTP+JSON, it is standard and extensible to implement the external interface, and there is no need to consider the version dependency of the operating system and related modules, that is, not affected by software heterogeneity. Therefore, according to the technical solution of the embodiment, the burst amount and the technical threshold required for acquiring resources are greatly reduced.

As shown in FIG. 6, an embodiment of the present invention provides a request processing method, and the method in this embodiment includes:

[0071] Step S610: Receive a request of the first protocol format sent by the requester, request the application for the streaming media resource, and perform verification and/or authentication on the request.

[0072] In this embodiment, the manner of verification and authentication is not limited. In this embodiment, an HTTP request for an external resource request is received, and a corresponding function is invoked for authentication and statistics, and the request is subsequently processed after the authentication succeeds. Specifically, after receiving the external HTTP+JSON request protocol, the source protocol checksum statistics may be performed on the request protocol, for example, verifying the validity according to the source address, and performing an authentication operation on the request protocol, that is, according to the account information in the request. Determine whether the request should be rejected or allowed. After the validity check and authentication operations are successful, generate a user interface admission prompt and perform subsequent operations.

[0073] Step S620: After the checksum/or authentication succeeds, the request is converted from the first protocol format to a second protocol format identifiable by the subsystem, and the subsystem is configured to process the request.

[0074] In this embodiment, the received request, such as the HTTP format, is protocol converted, converted into a message format that each subsystem can understand, such as SIP or other special format, or a custom message standard of each manufacturer. Prevail. [0075] Step S630, sending a request of the second protocol format to the subsystem.

[0076] In this embodiment, after the request message is received, the translation and the request are dispatched, and the classification process is performed according to different functions of the request message, for example, the request of the alarm query class is distributed to the alarm subsystem, and the resource query class The request is dispatched to the resource query subsystem, the streaming media class request is dispatched to the streaming media subsystem, and the resulting message is replied to by the respective subsystems. Similarly, you can also integrate wsdl (Network Service Description Language) files, which can be dynamically adapted as a client of a network service for certain resources that require SOAP (Simple Object Access Protocol) protocol calls.

[0077] Step S640, the subsystem acquires the streaming media resource in the first encapsulation and/or compression format according to the request, and converts the streaming media resource from the first encapsulation and/or compression format to the second encapsulation and/or compression of the corresponding requester. The format takes the address of the streaming resource in the second encapsulation and/or compression format as a result, so that the requester obtains the streaming media resource by address, and the result is the address of the streaming media resource.

[0078] In this embodiment, for example, if the requester requests a video resource, then the subsystem can return the URL (address) of a video resource, and the requester can directly access the URL. In this embodiment, streaming media or picture resources, such as audio and video, can be given by encapsulating the URL in the JSON return message. The requester obtains these resources through standard methods such as RTSP (Real Streaming Protocol), RT MP (Real Message Transfer Protocol), HTTP, FTP (File Transfer Protocol), etc. after obtaining the URL of the stream and the picture.

[0079] In this embodiment, for the request for the streaming media resource, the corresponding subsystem providing the streaming media resource needs to have a code stream conversion module, and the module undertakes the resource positioning and dispatching task of the streaming media. As shown in FIG. 4, the resource location is a resource location for generating a streaming media, that is, a URL, and the resource is uniquely indicated by using a URL. After receiving the submitted media resource application message, the module obtains the original stream from the streaming media server, that is, requests the original stream transcoding before the reply to generate the URL of the stream resource. After the U RL is generated, it is returned to the requester as it is. Afterwards, the code stream conversion module converts the original stream, including the conversion of the media compression format (G711 to AAC, MPEG4 to H.264, etc., G711, ACC, MPEG4, H.264 are different media compression formats), and the media packet method Conversion, such as TS (Transport Stream) Packet, PS (Program Stream) Packet, FLV (-Streaming Media Format) format, etc., so that streaming media can be decoded and played on different platforms and players. After receiving the URL, the requester can apply for resources by using various means and protocols such as R TMP, RTSP, HLS (Dynamic Rate Rate Adaptive Technology) according to the URL. The requester and the subsystem are in a peer-to-peer manner, that is, the requester of the media directly applies the streaming media to the subsystem providing the URL (specifically, the code stream conversion module therein) without passing through other intermediate links. Due to the adoption of standard media negotiation mode and standard media packet format, the selection conditions of streaming media processing and playback are very wide, which further reduces the difficulty of calling the original applicant.

[0080] Step S650, converting the result from the second protocol format to the first protocol format, and returning the result to the requester

[0081] Step S660: After the streaming media resource is transmitted with the requester, the session f π information is added to the resource data transmitted each time.

[0082] In this embodiment, the requester receives the streaming media URL and directly requests the streaming media resource through the player, and the application manner may be RTMP, RTSP, etc. according to the return format of the URL. For the security of the video stream transmission control, the technical solution of the embodiment is also considered, mainly by adding an authentication mechanism and an effective period authentication in the negotiation session. For example, in a video negotiation session, session information is added to the RTSP header field to indicate the inconsistency of each session, thereby improving the security of the session.

[0083] In one embodiment of the present invention, there is also provided a computer readable storage medium storing one or more programs, one or more programs executable by one or more processors, The steps of the request processing method of the foregoing embodiment are implemented.

[0084] According to the technical solution of the present invention, the request sent by the requester does not directly reach the subsystem that processes the request, but first needs to be converted by the protocol format, converted into a protocol format recognizable by the subsystem, and then sent. The subsystem is processed, and the processing result of the subsystem is also converted into the protocol format and returned to the requester. It can be seen that the conversion of the protocol format overcomes the influence of software heterogeneity between the requester and the subsystem, so that the requester and the requester Request processing and data interaction can be successfully completed between subsystems

[0085] It is to be noted that the terms "comprising", "including", or any other variations thereof are intended to encompass a non-exclusive inclusion, such that a process, method, article, or device that comprises a Those elements, but also other elements not explicitly listed, or elements that are inherent to such a process, method, item or device. An element that is defined by the phrase "comprising a ..." does not exclude the presence of additional elements in the process, method, article, or device that comprises the element. [0086] The foregoing serial numbers of the embodiments of the present invention are merely for the description, and do not represent the advantages and disadvantages of the embodiments.

[0087] Through the description of the above embodiments, those skilled in the art can clearly understand that the foregoing embodiment method can be implemented by means of software plus a necessary general hardware platform, and of course, can also be through hardware, but in many cases, the former It is a better implementation. Based on such understanding, the technical solution of the present invention, which is essential or contributes to the prior art, may be embodied in the form of a software product stored in a storage medium (such as ROM/RAM, disk, The optical disc includes a number of instructions for causing a terminal (which may be a cell phone, a computer, a server, an air conditioner, or a network device, etc.) to perform the methods described in various embodiments of the present invention.

The embodiments of the present invention have been described above with reference to the drawings, but the present invention is not limited to the specific embodiments described above, and the specific embodiments described above are merely illustrative and not restrictive. The skilled person is able to make various forms within the scope of the present invention without departing from the spirit and scope of the invention as claimed.

Industrial applicability

[0089] According to the technical solution of the present invention, the request sent by the requester does not directly reach the subsystem that processes the request, but first needs to be converted by the protocol format, converted into a protocol format recognizable by the subsystem, and then sent. The subsystem is processed, and the processing result of the subsystem is also converted into the protocol format and returned to the requester. It can be seen that the conversion of the protocol format overcomes the influence of software heterogeneity between the requester and the subsystem, so that the requester and the requester Request processing and data interaction can be successfully completed between subsystems. Therefore, it is industrial.

Claims

Claim

[Claim 1] A request processing method, the method comprising:

Receiving a request of the first protocol format sent by the requester;

Converting the request from the first protocol format to a second protocol format identifiable by the subsystem

The subsystem is configured to process the request;

Transmitting the request of the second protocol format to the subsystem;

And the subsystem obtains the result of the second protocol format after processing the request; converting the result from the second protocol format to the first protocol format; and returning the result to the requester.

[Claim 2] The method according to claim 1, wherein before the converting the request from the first protocol format to a second protocol format recognizable by the subsystem, the method further comprises: The request is verified and/or authenticated, and after the checksum/or authentication succeeds, the second protocol format that converts the request from the first protocol format to a subsystem identifiable is performed.

[Claim 3] The method according to claim 1, wherein the request is for applying for a streaming media resource, and the result is an address of the streaming media resource.

[Claim 4] The method according to claim 3, wherein the obtaining, by the subsystem, the result of the second protocol format after processing the request, specifically includes:

Obtaining, by the subsystem, the streaming media resource in a first encapsulation and/or compression format according to the request, converting the streaming media resource from the first encapsulation and/or compression format to a number corresponding to the requester And a second encapsulation and/or compression format, the address of the streaming media resource in the second encapsulation and/or compression format is used as the result, so that the requester obtains the streaming media resource according to the address.

[Claim 5] The method according to claim 4, wherein the address of the streaming media resource in the second encapsulation and/or compression format is used as the result for the requester Obtaining the streaming media resource according to the address, specifically:

After transmitting the streaming media resource with the requester, session information is added to each transmitted resource data.

[Claim 6] A request processing device, wherein the device comprises: An interface management module, configured to receive a request of a first protocol format sent by a requester, and a system interface module, configured to convert the request from the first protocol format to a second protocol format recognizable by a subsystem, where a subsystem for processing the request;

a system management module, configured to send the request in the second protocol format to the subsystem; the subsystem, configured to obtain a result of the second protocol format after processing the request; After the result is converted into the first protocol format by the second protocol format, the system interface module and the interface management module return the result to the requester.

The device according to claim 6, wherein

Before the converting the request from the first protocol format to a second protocol format recognizable by the subsystem, the interface management module further performs verification and/or authentication on the request, in the checksum / or after the authentication succeeds, the system interface module performs the conversion of the request from the first protocol format to a second protocol format recognizable by the subsystem.

The apparatus according to claim 6, wherein the request is for applying for a streaming media resource, and the result is an address of the streaming media resource.

The device according to claim 8, wherein

The device according to claim 9, wherein

The subsystem adds the session information to the resource data transmitted each time after transmitting the streaming media resource with the requester.

A computer readable storage medium, characterized in that the computer readable storage medium stores one or more programs, the one or more programs being executable by one or more processors to implement claim 1 The method of any of the methods of 5.