Detailed Description
Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the disclosure. One skilled in the relevant art will recognize, however, that the subject matter of the present disclosure can be practiced without one or more of the specific details, or with other methods, components, devices, steps, and the like. In other instances, well-known technical solutions have not been shown or described in detail to avoid obscuring aspects of the present disclosure.
The terms "a," "an," "the," and "said" are used in this specification to denote the presence of one or more elements/components/parts/etc.; the terms "comprising" and "having" are intended to be inclusive and mean that there may be additional elements/components/etc. other than the listed elements/components/etc.; the terms "first" and "second", etc. are used merely as labels, and are not limiting on the number of their objects.
Furthermore, the drawings are merely schematic illustrations of the present disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and thus their repetitive description will be omitted. Some of the block diagrams shown in the figures are functional entities and do not necessarily correspond to physically or logically separate entities.
Currently, in some specific application scenarios (for example, asynchronous scenarios such as data interaction by the front end through AJAX or WebSocket, realization of front end animation effect, and timers), the front end needs to write asynchronous code to realize communication with the back end server. And the front-end writing of the asynchronous code is mainly realized through callback, and if the function dependence is returned, the function dependence is realized in a manner of returning nesting.
On the other hand, on the one hand, data in the medium-large front-end items are mutually dependent, when a data request is made, the previous data is dependent on the next request, the callback nesting of a data request interface is inevitably caused, and when the nesting is too deep, the code logic is extremely complex. Particularly, in an IM application (instant messaging, abbreviated as IM), under a scenario where data interaction or data synchronization with a backend server is more frequent, we need to know whether a message is successfully sent or wait for data return of the backend server, which results in very complex application implementation and difficult maintenance. Furthermore, if a data structure is changed, the whole logic may be re-carded and re-implemented, which results in extremely high maintenance cost of our code and cannot be easily changed. On the other hand, the traditional callback function writing method enables codes to be mixed into a whole, and the codes become transversely developed rather than downwardly developed, so that the code meaning is unclear and the codes are not attractive.
In the embodiment of the disclosure, firstly, a server communication method is provided, which overcomes the defects of complex code layer-by-layer nesting logic and high maintenance cost in the related art at least to some extent.
Fig. 1 shows a flowchart of a server communication method in an exemplary embodiment of the present disclosure, and an execution subject of the server communication method may be a front end communicating with a back end server.
Referring to fig. 1, a server communication method according to one embodiment of the present disclosure includes the steps of:
step S110, sending a data request to a back-end server and generating a first request identifier;
step S120, an object instance is created, and the first request identification and the object instance are correspondingly stored in a key value pair mode;
step S130, sending a first message containing the first request identifier to a back-end server, and receiving a second message returned by the back-end server;
step S140, when the second request identifier corresponding to the second message is consistent with the first request identifier, determining the second message as the operation result of the object instance.
In the technical solution provided in the embodiment shown in fig. 1, on one hand, a data request is sent to a backend server, a first request identifier is generated, an object instance is created, and the first request identifier and the object instance are correspondingly stored in a key-value pair manner, which can facilitate to quickly find the object instance according to the request identifier in the following. On the other hand, the first message containing the first request identification is sent to the back-end server, the second message returned by the back-end server is received, and when the second request identification corresponding to the second message is consistent with the first request identification, the second message is determined as the operation result of the object instance, so that the technical problems of deep callback nesting and complex code logic caused by data interdependence in the related technology can be solved, the callback nesting of the code is changed into chain calling, the code structure is more attractive and clear, the code compiling logic is simplified, and the code maintenance cost is reduced.
The following describes the specific implementation of each step in fig. 1 in detail:
in an exemplary embodiment of the present disclosure, the front end, i.e., the foreground portion of the website, runs on a browser on a PC (Personal Computer), a mobile terminal, or the like, and displays a webpage browsed by a user. The front end can display related pages or information, and further, a user can perform interactive operation (for example, manual input or touch input information) on the front end to add, delete, search and modify the related pages and information.
The back-end server may be a server that provides relevant feedback response information for the front-end. When the user performs interactive operation at the front end and queries related resources, the front end can send a message containing the query content to the back end server. Furthermore, the back-end server can call the database associated with the back-end server to query and obtain the feedback response information corresponding to the query content, and the feedback response information is returned to the front end, so as to realize the response to the user interactive operation. For example, when the user performs an interactive operation on the front end and inputs "what is Artificial Intelligence technology", the front end may send a message containing query content "what is Artificial Intelligence" to the back end server, and then the back end server may call the associated database to query and obtain feedback response information "Artificial Intelligence (AI), abbreviated as english as AI. The method is a new technical science for researching and developing theories, methods, technologies and application systems for simulating, extending and expanding human intelligence, and returns feedback response information to a front end to realize response to user interactive operation.
In step S110, a data request is sent to the backend server and a first request identifier is generated.
In an exemplary embodiment of the present disclosure, the front-end may establish a Websocket long connection with the back-end server (i.e., establish a connection via the Websocket protocol). Further, for example, when the user a at the front end needs to query the phone number of the user B, the front end may send a data request to the back end server and generate a first request Identifier, where the first request Identifier may be a UUID (Universally Unique Identifier, UUID for short) identifying the data request.
When the front end sends a data request to the back end server, the request duration corresponding to the data request can be monitored in real time, a preset duration threshold value is set, and further, when the request duration is monitored to be larger than the preset duration threshold value, the session timeout between the front end and the back end server can be determined, and the session connection between the front end equipment and the back end server can be disconnected. Therefore, the technical problem that other tasks cannot be executed due to long-time waiting of the front end caused by errors of the rear end server or network and other problems can be avoided, and normal operation of the front end is guaranteed. Illustratively, the specific pseudo code (Pseudocode) implementation for disconnecting the session connection when the session times out (pseudo code) is an informal, similar to english structure, and used for describing the language of the module structure diagram) may be:
setTimeout(()=>{
if it times out, false is returned
resolve(false);
})
In step S120, an object instance is created, and the first request identifier is stored in correspondence with the object instance in the form of a key-value pair.
In an exemplary embodiment of the present disclosure, the front end may create an object instance, illustratively, a Promise object instance. The Promise object instance is used to represent the final state (completion or failure) of an asynchronous operation, as well as the resulting value of the asynchronous operation. The callback of the code can be nested into chain calling through the Promise object instance, and the code writing method of the callback layer by layer is simplified, so that the code is more simplified and the maintenance is more convenient. Illustratively, a specific pseudo-code implementation of creating an object instance may be:
var resolve=null;
var promise=new Promise((resolve)=>{resolve=resolve})
furthermore, the first request identifier and the created Promise object instance may be correspondingly stored in a pre-created message pool in a key-value pair manner. Exemplary, pseudo-code implementations of creating a message pool may be: var hashMap ═ new Map ().
Specifically, a message pool (key-key value set) may be created based on a Map object in JavaScript, where the Map object is an object that maps keys to values, a key is the request identifier, and a key value is the created object instance. For example, referring to table 1, the data stored in the key-value key pair stored in the message pool may be:
TABLE 1
Keywords (key)
|
Key value (value)
|
Request identification
|
Promise object instances |
It should be noted that the Promise object instance has only three states: asynchronous operation "outstanding", asynchronous operation "completed" (resolved), and asynchronous operation "failed" (rejected). Where such a change can only occur once, once the current state becomes "completed" or "failed," it means that no new state change can occur. Thus, the end results of the Promise object instances are only two. When the asynchronous operation succeeds, resolve is called (i.e. the status of the Promise object instance is changed from "not completed" to "completed", pending to resolved), and the result of the asynchronous operation is passed as a parameter. The reject is called when the asynchronous operation fails (i.e. the status of the Promise object instance is changed from "not completed" to "failed" and pending is changed to rejected), and the error reported by the asynchronous operation is passed as a parameter. However, whether the asynchronous operation succeeds or fails, the data return can be performed through the callback function resolve, and therefore, the Promise object instance in the present disclosure can be bound to the callback function resolve.
In view of this, the data structure of the Promise object instance in the key value may be: the first request identifier and a data structure of the Promise object instance (which may be referred to as Promise bundle in a specific programming language) may be correspondingly stored in the message pool in a form of a key-value pair, so as to conveniently and quickly find out an object instance corresponding to the request identifier in the following. For example, the specific pseudo-code implementation that correspondingly stores the first request identifier and the associated array of the Promise object instance in the form of a key-value pair in the message pool may be: set (message.id, [ premium, resolve ]).
Thus, referring to table 2, the data stored in the key-value key pair stored in the message pool may be:
TABLE 2
In step S130, the first message including the first request identifier is sent to the back-end server, and the second message returned by the back-end server is received.
In an exemplary embodiment of the present disclosure, the front end may send a first message packet containing the first request identifier to the back end server, where the message packet is a data unit exchanged and transmitted in the network, that is, a data block to be sent by the station at a time. The message contains complete data information to be sent, and the message is very inconsistent in length, unlimited in length and variable.
Specifically, the data request information and the first request identifier may be encapsulated and packaged to obtain a first message packet. Wherein the data request information may include one of: request content, data request type, transmission time stamp, information transmission state, and receiver information. For example, when the front-end user a needs to query the telephone number of the user B, the request content may be "the telephone number of B", and the data request type may include: chat type, system notification type, session type, etc. The sending timestamp is the time of sending the first message packet. The information transmission state may include: during transmission, the transmission is successful, and the transmission is failed. The recipient information, i.e. the recipient of the first message, is for example: a unique identification code or an IP Address (Internet Protocol Address, which is collectively referred to as an Internet Protocol Address, IP Address for short) of the back-end server that receives the first message packet.
The encapsulation is an information hiding technology, the encapsulation is realized in java through keywords private, protected and public, the encapsulation is to enclose processes and data, and the access to the data can only be through a defined interface. For example, a specific pseudo-code implementation for creating the first message packet may be: the var Message is a new Message (str), where a str string represents a first Message packet including the data request information and a first request identifier.
By packaging and packaging the data request information and the first request identifier, on one hand, various problems caused by separation of data and operation in the traditional structure method are thoroughly solved, reusability and maintainability of the program are improved, and burden of a programmer for maintaining data and operation content is reduced. On the other hand, the private data and the public data can be separated, so that the private data is protected, possible inter-module interference is reduced, and the purposes of reducing program complexity and improving controllability are achieved.
The front end can send a first message containing a first request identifier to the back end server through a full duplex communication protocol, after receiving the first message, the back end server can analyze and process the first message to obtain the first request identifier and the request content contained in the first message, and further, the back end server can query and obtain feedback response information corresponding to the request content (for example, query and obtain the telephone number of the user B), and package the feedback response information and a generated second request identifier (for distinguishing from the request identifier generated by the front end device, the second request identifier can be consistent with the first request identifier in actual processing) to obtain a second message. Further, the second message may be sent to the front end via a full duplex communication protocol.
In step S140, when the second request identifier corresponding to the second message is consistent with the first request identifier, the second message is determined as the operation result of the object instance.
In the exemplary embodiment of the present disclosure, after the front end receives the second message sent by the back end server through the full duplex communication protocol, the second message may be analyzed to obtain the second request identifier corresponding to the second message. For example, the specific pseudo code implementation that the front end receives the second message and analyzes the second message to obtain the second request identifier may be:
function Recive(message){
// get request ID for session
var id=message.id;
Furthermore, the second request identifier may be compared with the first request identifier, and if the comparison result is: if the second request identifier is consistent with the first request identifier, the second message may be determined as the operation result of the object instance. Specifically, the remise object instance corresponding to the first request identifier may be acquired from the message pool, a resolve callback function bound to the remise object instance is called, and the second message packet is transmitted to the remise object instance based on the resolve callback function, so as to determine the second message packet as the operation result of the remise object instance.
For example, the front end may receive a second message and search whether a request identifier consistent with the second request identifier exists in the message pool, and if not, directly enter the processing process of the next request by ignoring the second request identifier; if the message exists, the resolve callback function in the promisetbundle corresponding to the first request identifier may be taken out from the message pool, and the second message packet is returned based on the resolve callback function. A specific pseudo-code implementation of this process may be:
defining a receiving function which is a drop-back function of monitoring received messages of WebSocket
function Recive(message){
// get request ID for session
var id=message.id;
Searching whether a request identifier consistent with the second request identifier exists in the message pool
var promiseBundle=hashMap.get(id);
If not, directly enter the processing of the next request
if(!promiseBundle)return next(message);
If so, take out resolve in promisseBundle and return to
var[promise,resolve]=promiseBundle;
resolve(message)
}
If the comparison result is: if the second request identifier is not consistent with the first request identifier, it may be determined whether the second message packet corresponding to the second request identifier is an effective packet, and specifically, it may be determined whether the second message packet is an effective packet by identifying whether the second request identifier is consistent with the request identifiers corresponding to the other data requests. When the second message is identified as a valid message, the second message may be stored in a memory buffer (the buffer is a memory area, and is used between an input/output device and a Central Processing Unit (CPU) to store data). Therefore, effective information can be prevented from being lost, low-speed input and output equipment and a high-speed CPU can work in a coordinated mode, the low-speed input and output equipment is prevented from occupying the CPU, the CPU is liberated, and the high-speed CPU can work efficiently. When the second message is identified as an invalid message, the second message can be discarded, so that the memory occupation of the invalid information is avoided, and the system operation speed is increased.
In an exemplary embodiment of the present disclosure, the synchronous waiting for the result of the session operation may be implemented by the async and await syntaxes. The Await syntax can only be used in the context of async function, which can be followed by any JS (JavaScript for short, a high-level, multi-modal, interpreted programming language) expression, but the Await is mainly used to wait for the Promise object instance to become resolved, which causes the asynchronous function to stop executing and wait for the operation result of the Promise object instance when the Await is the Promise object instance. For example, the specific pseudo code implementation of waiting for the operation result corresponding to the request by using the async and await syntax to implement synchronization may be:
in business logic code, a session operation is defined and an async function is used at the call
async function Work(){
// synchronous wait (await) result of this session
var resultMessage=await Send(‘test’);
V/obtaining the return value of the current conversation to process the next step
}
Furthermore, when the await syntax receives the return value of the above-mentioned resolve callback function (response feedback information included in the second message), the front end may enter the next service processing logic.
Based on the technical scheme and the implementation codes, the method and the device can solve the technical problems that the codes are nested layer by layer to cause complex logic, data is dragged to move the whole body, and the codes are difficult to maintain in the related technology, simplify the code structure and the code writing logic, avoid a code writing method of callback layer by layer, and reduce the maintenance cost of the codes.
Exemplarily, referring to fig. 2, fig. 2 shows an overall flowchart of a server communication method in an exemplary embodiment of the present disclosure, which includes steps S201-S208, and a specific implementation is explained below with reference to fig. 2.
In step S201, start;
in step S202, the front end obtains data request information, where the data request information includes at least one of the following: request content, data request type, sending time stamp, information sending state and receiver information;
in step S203, the front end generates a first request identifier, encapsulates and packages the first request identifier and the data request information to obtain a first message, and sends the first message to the back end server;
in step S204, the front end creates an object instance, and stores the first request identifier and the object instance in a message pool;
in step S205, the front end receives the second message returned by the back end server, and analyzes the second message to obtain a second request identifier;
in step S206, the front end determines whether the second request identifier is registered (i.e. whether the second request identifier is consistent with the first request identifier) through the message pool;
in step S207, if yes, the callback function bound to the object instance is called, and the second message is transmitted to the object instance based on the callback function, so as to determine the second message as the operation result of the object instance.
In step S208, end;
if not, the process goes to step S208 and ends.
The present disclosure also provides a server communication device, and fig. 3 shows a schematic structural diagram of the server communication device in an exemplary embodiment of the present disclosure; as shown in fig. 3, the server communication device 300 may include a data request module 301, an object creation module 302, a message transmission module 303, and a determination module 304. Wherein:
a data request module 301, configured to send a data request to a backend server and generate a first request identifier.
In an exemplary embodiment of the disclosure, the data request module is configured to send a data request to a backend server and generate a first request identification.
The object creating module 302 is configured to create an object instance and store the first request identifier in correspondence with the object instance in the form of a key-value pair.
In an exemplary embodiment of the present disclosure, the object creating module is configured to create a message pool, where the message pool is a key-value pair set that uses the request identifier as a key and uses the object instance as a key; and correspondingly storing the first request identification and the object instance in a message pool in a key value pair mode.
The message sending module 303 is configured to send a first message including the first request identifier to the backend server, and receive a second message returned by the backend server.
In an exemplary embodiment of the present disclosure, the message sending module is configured to obtain data request information, where the data request information at least includes one of the following information: request content, data request type, sending time stamp, information sending state and receiver information; and packaging the data request information and the first request identifier to obtain a first message.
In an exemplary embodiment of the disclosure, the message sending module is configured to send a first message including a first request identifier to the backend server based on a full duplex communication protocol.
The determining module 304 is configured to determine the second message as an operation result of the object instance if the second request identifier corresponding to the second message is consistent with the first request identifier.
In the exemplary embodiment of the present disclosure, the determining module is configured to, when a second request identifier corresponding to a second message is consistent with the first request identifier, obtain an object instance corresponding to the first request identifier from the message pool and call a callback function bound to the object instance; and transmitting the second message to the object instance based on the callback function so as to determine the second message as the operation result of the object instance.
In an exemplary embodiment of the disclosure, after sending a data request to a backend server and generating a first request identifier, a determining module is configured to obtain a request duration corresponding to the data request; and when the request duration is greater than a preset duration threshold, determining that the data request is overtime and disconnecting the session connection between the front end and the back end server.
In an exemplary embodiment of the present disclosure, the determining module is configured to determine whether a second message corresponding to a second request identifier is an effective message when the second request identifier is inconsistent with the first request identifier; if the second message is a valid message, storing the second message in a memory buffer area; and if the second message is an invalid message, discarding the second message.
The specific details of each module in the server communication device have been described in detail in the corresponding server communication method, and therefore are not described herein again.
It should be noted that although in the above detailed description several modules or units of the device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit, according to embodiments of the present disclosure. Conversely, the features and functions of one module or unit described above may be further divided into embodiments by a plurality of modules or units.
Moreover, although the steps of the methods of the present disclosure are depicted in the drawings in a particular order, this does not require or imply that the steps must be performed in this particular order, or that all of the depicted steps must be performed, to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions, etc.
Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, the technical solution according to the embodiments of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (which may be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which may be a personal computer, a server, a mobile terminal, or a network device, etc.) to execute the method according to the embodiments of the present disclosure.
In an exemplary embodiment of the present disclosure, there is also provided a computer storage medium capable of implementing the above method. On which a program product capable of implementing the above-described method of the present specification is stored. In some possible embodiments, various aspects of the disclosure may also be implemented in the form of a program product comprising program code for causing a terminal device to perform the steps according to various exemplary embodiments of the disclosure described in the "exemplary methods" section above of this specification, when the program product is run on the terminal device.
Referring to fig. 4, a program product 400 for implementing the above method according to an embodiment of the present disclosure is described, which may employ a portable compact disc read only memory (CD-ROM) and include program code, and may be run on a terminal device, such as a personal computer. However, the program product of the present disclosure is not limited thereto, and in this document, a readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
A computer readable signal medium may include a propagated data signal with readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A readable signal medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
Program code embodied on a readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Program code for carrying out operations for the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device and partly on a remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computing device (e.g., through the internet using an internet service provider).
In addition, in an exemplary embodiment of the present disclosure, an electronic device capable of implementing the above method is also provided.
As will be appreciated by one skilled in the art, aspects of the present disclosure may be embodied as a system, method or program product. Accordingly, various aspects of the present disclosure may be embodied in the form of: an entirely hardware embodiment, an entirely software embodiment (including firmware, microcode, etc.) or an embodiment combining hardware and software aspects that may all generally be referred to herein as a "circuit," module "or" system.
An electronic device 500 according to this embodiment of the disclosure is described below with reference to fig. 5. The electronic device 500 shown in fig. 5 is only an example and should not bring any limitation to the functions and the scope of use of the embodiments of the present disclosure.
As shown in fig. 5, the electronic device 500 is embodied in the form of a general purpose computing device. The components of the electronic device 500 may include, but are not limited to: the at least one processing unit 510, the at least one memory unit 520, a bus 530 connecting the various system components (including the memory unit 520 and the processing unit 510), and a display unit 540.
Wherein the storage unit stores program code that is executable by the processing unit 510 to cause the processing unit 510 to perform steps according to various exemplary embodiments of the present disclosure as described in the above section "exemplary methods" of this specification. For example, the processing unit 510 may perform the following as shown in fig. 1: step S110, sending a data request to a back-end server and generating a first request identifier; step S120, an object instance is created, and the first request identification and the object instance are correspondingly stored in a key value pair mode; step S130, sending a first message containing the first request identifier to a back-end server, and receiving a second message returned by the back-end server; step S140, when the second request identifier corresponding to the second message is consistent with the first request identifier, determining the second message as the operation result of the object instance.
The memory unit 520 may include a readable medium in the form of a volatile memory unit, such as a random access memory unit (RAM)5201 and/or a cache memory unit 5202, and may further include a read only memory unit (ROM) 5203.
Storage unit 520 may also include a program/utility 5204 having a set (at least one) of program modules 5205, such program modules 5205 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may comprise an implementation of a network environment.
Bus 530 may be one or more of any of several types of bus structures including a memory unit bus or memory unit controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.
The electronic device 500 may also communicate with one or more external devices 600 (e.g., keyboard, pointing device, bluetooth device, etc.), with one or more devices that enable a user to interact with the electronic device 500, and/or with any devices (e.g., router, modem, etc.) that enable the electronic device 500 to communicate with one or more other computing devices. Such communication may occur via input/output (I/O) interfaces 550. Also, the electronic device 500 may communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the internet) via the network adapter 560. As shown, the network adapter 560 communicates with the other modules of the electronic device 500 over the bus 530. It should be appreciated that although not shown in the figures, other hardware and/or software modules may be used in conjunction with the electronic device 500, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.
Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, the technical solution according to the embodiments of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (which may be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which may be a personal computer, a server, a terminal device, or a network device, etc.) to execute the method according to the embodiments of the present disclosure.
Furthermore, the above-described figures are merely schematic illustrations of processes included in methods according to exemplary embodiments of the present disclosure, and are not intended to be limiting. It will be readily understood that the processes shown in the above figures are not intended to indicate or limit the chronological order of the processes. In addition, it is also readily understood that these processes may be performed synchronously or asynchronously, e.g., in multiple modules.
Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.