Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the technical solutions of the present application will be described in detail and completely with reference to the following specific embodiments of the present application and the accompanying drawings. It should be apparent that the described embodiments are only some of the embodiments of the present application, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step are within the scope of the present application.
The embodiments of the present specification will be described in detail below with reference to the accompanying drawings.
Fig. 1 is a schematic diagram of an architecture of a traffic acquisition and cloud display system provided in an embodiment of the present disclosure, including a cross-platform support library 101, an upload module 103, and a cloud display subsystem 105.
The cross-platform support library 101 adapts, for user terminals of different operating systems, a corresponding traffic acquisition mode to the user terminal according to the permission of a user at the user terminal, and acquires the data traffic of the user terminal through the traffic acquisition mode, where the permission is Root permission (i.e. super user permission) or non-Root permission. The corresponding traffic acquisition mode includes a Root traffic acquisition mode or a non-Root traffic acquisition mode corresponding to the authority of the user.
The user terminal may be a mobile terminal or a fixed terminal, and based on personal selection of a user, the operating system may include any one of an iOS system, an Android system, a Linux system, a Unix system, a Windows system, or a MacOS system, which may also be extended to other types of systems as needed, and is not listed here.
Specifically, according to different permissions of a user on a user terminal, there are usually multiple preset packet capturing modes (when the acquisition objects are data packets appearing one by one, the traffic acquisition mode may also be referred to as a packet capturing mode), and each packet capturing mode corresponds to a packet capturing module, and is accessed into the user terminal in a modular form for the user to select. In the user terminal, the user permission is different, and a common situation is that the user has a Root permission or a non-Root permission.
As an exemplary implementation manner, an architectural diagram of a cross-platform support library is provided in an embodiment of the present specification, as shown in fig. 2, and fig. 2 is a modular diagram of an exemplary cross-platform support library provided in an embodiment of the present specification.
When the user is Root authority, the cross-platform support library 101 acquires data traffic from the kernel protocol stack, and the acquisition mode may include tandem interception or bypass replication.
For example, based on the Netfilter module, detection points (such as may be set by a HOOK function) are placed at certain positions in the kernel protocol stack, and some processing functions are registered at each detection point for processing, and traffic may be acquired when passing through the detection points, that is, data traffic of the user terminal is acquired from the kernel protocol stack in a tandem manner. As another example, the data traffic is mirrored by copying the data traffic from a bypass in the network link layer of the kernel protocol stack using the interface provided by Libpcap.
When the user is not Root, the cross-platform support library 101 establishes a Virtual Private Network (VPN), and acquires data traffic through a port of the VPN. In other words, the cross-platform support library 101 establishes a VPN at the user terminal, proxies the flow interaction process between the user terminal and the outside, and executes proxy packet capture through a port of the VPN.
For example, adaptive access is performed according to the type of an operating system of the user terminal (for example, an iOS system or an Android system), a VPN is established locally at the user terminal, external data traffic of each application APP on the user terminal is acquired through a VPN port, and data is written back to each APP; meanwhile, connection of the user terminal to the outside is established, the received external data traffic of each APP is analyzed, and the data traffic is sent to the outside.
The data traffic includes all data packets generated when the user terminal interacts with the outside world, obviously, the data traffic is usually a mixture of data packets of a plurality of APPs, and based on this, in order to improve the purity degree of the data traffic, the related data packets of each APP need to be separated, and only the traffic in which the user is interested is reserved.
Based on this, the cross-platform support library 101 is further configured to: acquiring data traffic belonging to a designated APP according to setting information of a user terminal, wherein the setting information of the user terminal comprises the information of the designated APP. That is, the data traffic belonging to a specific APP only includes the data packet generated when the APP interacts with the outside world, and does not include the data packets of other APPs.
The setting information of the user terminal may be a default certain or multiple APPs, or may provide multiple APPs run by the user terminal for the user to select and specify. In other words, the acquired traffic is identified and filtered according to the setting information of the user terminal, and only the data traffic belonging to the specified application is reserved.
It should be noted that the specific APPs may be one or more. When a user designates a plurality of APPs, each designated APP corresponds to a group of related data traffic. In addition, specifying the APP of interest to the user and selecting the traffic acquisition mode are typically performed prior to acquiring traffic. A user can designate an APP first and then select a flow acquisition mode; or the flow obtaining mode can be selected first, and then the APP is appointed.
In a specific embodiment, the cross-platform support library 101 may obtain data traffic related to an APP specified by a user in a port matching manner. Specifically, a data packet containing a port number is acquired through a preset traffic acquisition module; matching the port number with flow port information provided by an operating system of the user terminal to obtain an APP identifier corresponding to the port number, wherein the flow port information provided by the operating system of the user terminal comprises a corresponding relation between the port number and the APP identifier; and determining the data traffic related to the appointed APP according to a data packet containing a port number corresponding to the appointed APP identifier.
For example, in a Linux/Unix system, a tcp file in a "/proc/net" directory in the system stores a corresponding relationship between a port number and an APP unique identifier; and storing the corresponding relation between the port number and the APP unique identifier through a flow port table in the Windows system. That is, acquiring the port number of each data packet in the traffic, the APP identifier corresponding to the port number can be obtained in a matching manner, so as to obtain the data stream belonging to the APP.
In another specific embodiment, the cross-platform support library 101 may obtain the data traffic related to the designated APP by using a packet detection technology. Specifically, data traffic is acquired through a preset traffic acquisition mode; identifying the content of the data flow to acquire the data flow belonging to the appointed APP; the content of the data traffic includes one or more of a transport protocol, a port number, an IP address, a unique address identifier URL, or a data payload of the data traffic.
Since different APPs often depend on different protocols, which have their special features, such as specific ports, specific strings, or specific server IPs, the APP may generate Uniform Resource Locators (URLs) and specific interactive contents (e.g., when the APP requests downloading from the server) during the interaction with the outside world, and so on. Based on the data packet, a feature recognition technology can be adopted to determine the application corresponding to the data packet by detecting the relevant features in the data traffic. For example, Deep Packet Inspection (DPI) is used to identify the data payload of a Packet to determine the application to which the Packet belongs.
Through discerning user terminal's flow, can appoint according to actual need and catch the package, only keep the data flow who belongs to the APP that the user is interested in, improve the purity of flow, provide more accurate foundation for subsequent work.
The foregoing method describes how to identify data traffic belonging to an APP that is of interest to a user, and it should be noted that one APP may simultaneously employ multiple services, and the service of interest to the user can also be identified by the same principle (port number matching or deep packet identification), thereby further refining the attribution of the data traffic.
Further, the cross-platform support library 101 is further configured to: and generating a corresponding data flow file according to the acquired data flow, and storing the corresponding data flow file. For example, a pcap (pcap is a common data stream format) file is generated according to the acquired data traffic, and the file contains all relevant information of the acquired data packet. The obtained data traffic can be uploaded in real time or stored locally for uploading.
In the flow acquisition process, different flow acquisition modes can be combined with flow identification and data flow storage. As an exemplary implementation, an embodiment of the present specification provides a modular schematic diagram of a Root traffic acquisition mode, as shown in fig. 3; the embodiments of the present description further provide a modularized schematic diagram of a non-Root traffic acquisition mode, as shown in fig. 4.
It should be noted that, when a user specifies a plurality of APPs in advance, each APP has a group of data traffic belonging to it, and then a data traffic file belonging to each APP is obtained when generating a file.
The uploading module 103 sends the acquired data traffic/data traffic file to a cloud display subsystem.
The aforementioned cross-platform support library 101 may be accessed to the user terminal in the form of a plug-in or a bale plucker. As an exemplary implementation, in an actual application scenario, for a user terminal, the traffic acquisition and cloud display system may perform the following steps, as shown in fig. 5, where fig. 5 is a schematic flow chart of the steps performed by the traffic acquisition and cloud display system in the user terminal provided in this embodiment of the present disclosure:
s501, opening a packet capturing tool, initializing a system and prompting a flow acquisition mode;
s503, selecting a flow acquisition mode by a user, and designating an application to be captured;
s505, adaptively starting a cross-platform support library according to the setting of a user;
s507, judging whether the flow port information provided by the user terminal system can be read; if so, identifying the data traffic based on port and application Unique Identifier (UID) matching; if not, carrying out DPI identification on the data flow;
s509, writing the obtained data traffic into a data traffic file and storing the data traffic file;
s511, judging whether the data flow file needs to be uploaded to a cloud end, and if so, uploading the data flow file to a cloud end display system; if not, ending.
The obtained data traffic is not intuitive for general users, is difficult to understand without corresponding network professional knowledge, and is not efficient in performing corresponding service analysis according to the data traffic.
Based on this, the cloud display subsystem 105 receives the data traffic/data traffic file, and displays the data traffic file with a visual chart. Therefore, the data flow/data flow files are visually displayed in a chart mode to adapt to the level of workers, so that the workers with low network level are assisted to perform corresponding network analysis, and the analysis efficiency is improved.
Specifically, the data stream or the data stream file includes related information of a plurality of data packets, such as a port number, a sequence number, a receiving time, and the like of each data packet, and the related information is visually displayed in a form of a table or a graph according to a certain rule (for example, the related information of each data packet is sequentially arranged and filled in the table according to the sequence number). The flow data is easier to read and understand, and the development efficiency of subsequent services is improved. For example, when network debugging is performed according to data flow, the visual chart is displayed, so that a worker with low network level can be assisted in performing network debugging, and the debugging efficiency of professional network workers is improved. .
In a specific embodiment, the cloud display subsystem 105 analyzes the received data stream or data stream file to obtain a TCP connection record included therein; and displaying the TCP connection record in a visual chart.
In the process of TCP communication, the APP segments data and sequences the data to send so as to realize ordered transmission; reliability is guaranteed by an Acknowledgement (ACK) signal (the ACK signal is also typically numbered). Based on this, a table can be built to debug by analyzing the handshake and ACK sequence number of the TCP connection and other TCP related content in the data traffic/data traffic file. For example, the pcap file is analyzed to obtain TCP connection data related to each data packet, and a corresponding table is established.
In another specific embodiment, the cloud display subsystem 105 obtains the related information of each data packet in the data traffic/data traffic file; and displaying the relevant information of each data packet in a visual chart, wherein the relevant information of the data packet comprises one or more of a time stamp, a target address, a source address, a port number, a sequence number or a data length of the data packet.
For example, a two-dimensional plane coordinate system is established by taking the time of a data packet as an abscissa and the sequence number of the data packet as an ordinate, a (time, sequence number) graph of the data packet is obtained, and the transmission condition of the data packet is visually shown to perform subsequent services (for example, network debugging).
Further, when the cloud display subsystem 105 performs network debugging, in order to reduce workload of debugging personnel and realize intelligent debugging, a certain rule can be preset, the cloud display subsystem analyzes the visual chart, and when part or the whole of the chart accords with a preset rule, an error type is judged according to the preset rule.
For example, in a table built from data flows, when a plurality of identical packet numbers occur consecutively, it is judged that retransmission has occurred.
For another example, in a graph with time on the abscissa and serial number on the ordinate, when the slope of a straight line formed by two or more consecutive points is equal to 0, it is determined as retransmission (in the graph, it means that a curve is uniform), or when the distance between two points exceeds a certain value, it is determined that the delay is too large (in the graph, it means that the slope of the curve does not exceed a preset value, which may be artificially set according to different APPs).
Further, the cloud display subsystem is further configured to display, in a visual interface, prompt information related to the network error type, as shown in fig. 6, where fig. 6 is a schematic diagram of the cloud display subsystem displaying the prompt information related to the error type in the embodiment of the present specification.
As an exemplary implementation, in an actual application scenario, for the cloud subsystem, the flow acquiring and cloud displaying system may perform the following steps, as shown in fig. 7, where fig. 7 is a schematic flow diagram of the cloud subsystem, the flow acquiring and cloud displaying system performing steps, provided in this specification, and the flow diagram includes:
s701, receiving a data flow file;
s703, analyzing the data flow file to obtain a connection record of the data packet;
s705, analyzing, recording and storing the connection record of each data packet;
s707, performing WEB visual display on the data traffic according to a specified rule;
s709, intelligently judging the points with possible network errors and giving corresponding prompt information.
It should be noted that, in an actual application scenario, since the analysis of the data traffic requires corresponding professional knowledge, a general user generally has no ability to analyze the data traffic according to the obtained data traffic or data traffic file, and thus the visualization of the data traffic is generally performed in a cloud. However, visual presentation at the user's local terminal is also feasible.
Based on this, this specification embodiment also provides a show system for: and receiving data flow or a data flow file, and displaying the data flow file by using a visual chart.
By adaptively accessing the packet capturing modes with different permissions according to the types of the operating systems of the user terminals, the scheme can support the user terminals with various different operating systems (such as an iOS or an Android system) or different user permissions (such as Root permissions and non-Root permissions), and has wider application range; the obtained flow is visually displayed, so that more visual and deep analysis on the data flow is facilitated, and subsequent network debugging and other services are facilitated. In addition, the flow related to the designated APP can be obtained according to the instruction of the user, the purity degree of the flow is improved, and a more accurate basis is provided for subsequent services (such as network debugging).
Based on the same idea, the present invention further provides a traffic obtaining and cloud displaying method, as shown in fig. 8, fig. 8 is a schematic flow diagram of the traffic obtaining and cloud displaying method provided in the embodiment of the present specification, and the method includes:
s801, aiming at user terminals of different operating systems, adapting corresponding flow acquisition modes to the user terminals according to the authority of users at the user terminals;
s803, obtaining data traffic through the corresponding traffic obtaining mode, so as to send the data traffic to the cloud display subsystem; wherein the authority is Root authority or non-Root authority.
Further, in step S801, the preset flow obtaining mode at least includes any one of the following:
a Root mode, when the authority of the user at the user terminal is the Root authority, acquiring data flow from a kernel protocol stack; or in the non-Root mode, when the authority of the user at the user terminal is the non-Root authority, establishing a Virtual Private Network (VPN), and acquiring data traffic through a port of the VPN, wherein the VPN is used for acting traffic interaction between the local terminal and the outside.
Still further, the Root mode includes: and when the authority of the user at the user terminal is Root authority, acquiring data traffic from the kernel protocol stack in a serial connection or bypass mode.
The non-Root mode includes: when the authority of the user at the user terminal is a non-Root authority, adaptively establishing a VPN according to the type of an operating system of the user terminal; acquiring the external data traffic of each APP on the user terminal through the VPN port, and writing back data to each APP; and establishing connection of the user terminal to the outside, analyzing the received external data traffic of each APP, and sending the external data traffic to the outside through the VPN port.
Further, the method further comprises: s805, according to the setting information of the user terminal, obtaining the data flow belonging to the appointed APP, wherein the setting information of the user terminal comprises the information of the appointed APP.
Further, in the foregoing S805, obtaining the data traffic belonging to the designated APP according to the setting information of the user terminal includes: acquiring a data packet containing a port number through a preset traffic acquisition mode; matching the port number with traffic port information provided by an operating system of the user terminal to acquire an APP identifier corresponding to the port number, wherein the traffic port information comprises a corresponding relationship between the port number and the APP identifier; and determining the data traffic belonging to the appointed APP according to a data packet containing a port number corresponding to the appointed APP identifier.
Further, in the foregoing S805, obtaining the data traffic belonging to the designated APP according to the setting information of the user terminal includes: acquiring data flow through a preset flow acquisition mode; identifying the content of the data traffic to acquire the data traffic belonging to the specified APP; the content of the data traffic includes one or more of a transport protocol, a port number, an IP address, a unique address identifier URL, or a data payload of the data traffic.
Further, the method further comprises: and S807, generating a corresponding data flow file according to the acquired data flow, and storing the data flow file so as to send the data flow file to the cloud display subsystem.
Based on the same idea, an embodiment of the present specification further provides another traffic obtaining and cloud displaying method, as shown in fig. 9, where fig. 9 is a schematic flow diagram of the another traffic obtaining and cloud displaying method provided by the embodiment of the present specification, and the method includes:
s901, receiving a data flow/data flow file;
and S903, displaying the data flow/data flow file by using a visual chart.
Further, in S901, the data traffic/data traffic file includes a data traffic/data traffic file belonging to a specific APP, where the specific APP is determined by setting information of a user terminal, and the setting information of the user terminal includes information of the specific APP.
Further, for S903, the data traffic/data traffic file is shown in a visualization chart. The method comprises the following steps: analyzing the received data stream or data stream file to obtain the connection record of the APP contained in the data stream or data stream file and the external TCP; and displaying the TCP connection record in a visual chart.
Further, for S903, displaying the data traffic/data traffic file in a visualization chart, including: acquiring related information of each data packet in a data stream or a data stream file; and displaying the relevant information of each data packet in a visual chart, wherein the relevant information of the data packet comprises one or more of a time stamp, a target address, a source address, a port number, a sequence number or a data length of the data packet.
Further, the method further includes S905: and analyzing the visual chart, and judging the network error type according to a preset rule when part or the whole of the visual chart accords with the preset rule.
Further, the method further includes S907: and displaying prompt information related to the network error type in a visual interface.
Meanwhile, an embodiment of the present specification further provides a data traffic display method, including: and receiving a data stream or a data stream file, and displaying the data flow/the data flow file by using a visual chart.
Based on the same idea, an embodiment of the present specification further provides a flow rate obtaining apparatus, as shown in fig. 10, fig. 10 is a schematic structural diagram of the flow rate obtaining apparatus provided in the embodiment of the present specification, where the apparatus includes:
an adaptation module 1001, adapted to adapt a corresponding traffic acquisition mode to a user terminal of a different operating system according to a permission of a user at the user terminal, where the permission is a Root permission or a non-Root permission;
a traffic obtaining module 1003 for obtaining data traffic through the corresponding traffic obtaining mode;
and the uploading module 1005 is used for sending the data traffic to the cloud display subsystem.
Further, the apparatus further includes a traffic identification module 1007, configured to obtain, according to an instruction of a user, a data traffic belonging to a specified APP.
Further, the apparatus further includes a storage module 1009, which generates and stores a corresponding data traffic file according to the acquired data traffic; the upload module 1005 is further configured to send the data traffic file to a cloud display subsystem.
Further, the traffic obtaining module 1003 includes a Root traffic obtaining module, and when the user is in a Root right, obtains data traffic from the kernel protocol stack; and/or the presence of a gas in the gas,
and the non-Root flow acquisition module is used for establishing a Virtual Private Network (VPN) when the authority of the user at the user terminal is the non-Root authority, acquiring data flow through a port of the VPN, and using the VPN for proxying flow interaction between the local terminal and the outside.
Further, as shown in fig. 11, fig. 11 is a schematic structural diagram of the Root traffic acquiring module provided in the embodiment of the present specification, and the Root traffic acquiring module includes: a tandem traffic fetch sub-module 1101 or a bypass traffic fetch sub-module 1103.
Further, as shown in fig. 12, fig. 12 is a schematic structural diagram of the non-Root traffic acquiring module provided in the embodiment of the present specification, and the non-Root traffic acquiring module includes:
the system interface module 1201 is used for adaptive access according to the type of the user terminal operating system and establishing a VPN;
a traffic obtaining module 1203, obtaining external data traffic of each APP on the user terminal through the VPN port;
the write-back module 1205 writes back the data returned from the outside to each APP;
the connection management module 1207, which establishes the connection of the user terminal to the outside, forms a proxy channel, sends data to the outside, and calls the write-back module 1205 when receiving the data returned by the outside;
the external data transceiver module 1209 receives data returned from the outside and transmits the data to the outside.
Based on the same idea, an embodiment of the present specification further provides a flow rate display device, as shown in fig. 13, fig. 13 is a schematic structural diagram of the flow rate display device provided in the embodiment of the present specification, where the flow rate display device includes:
a receiving module 1301, which receives data traffic/a data traffic file;
and a display module 1303 for displaying the data traffic/data traffic file in a visual chart.
Further, the apparatus further includes an analyzing module 1305, which analyzes the received data stream or data stream file, and obtains a connection record between the APP contained in the data stream or data stream file and external TCP; the display module 1303 displays the TCP connection record in a visual chart. Or, the parsing module 1305 obtains the relevant information of each data packet in the data stream or the data stream file; the display module 1303 displays, in a visual chart, the related information of each data packet, where the related information of the data packet includes one or more of a timestamp, a destination address, a source address, a port number, a sequence number, or a data length of the data packet.
Further, the apparatus further includes a determining module 1307 configured to analyze the visual chart, and determine a network error type according to a preset rule when a part or an entirety of the visual chart meets the preset rule.
Further, the display module 1303 displays a prompt message related to the network error type in a visual interface.
Correspondingly, an embodiment of the present specification further provides a traffic obtaining device, including:
a memory storing a data traffic acquisition program;
and the processor calls the data flow acquisition program in the memory and executes:
aiming at user terminals of different operating systems, according to the authority of a user at the user terminal, adapting a corresponding flow acquisition mode to the user terminal;
acquiring data traffic through the corresponding traffic acquisition mode so as to send the data traffic to a cloud display subsystem;
wherein the authority is Root authority or non-Root authority.
Correspondingly, an embodiment of the present specification further provides a flow display device, including:
a memory storing a data traffic display program;
a processor for calling the data flow showing program in the memory and executing
Receiving a data flow/data flow file;
and displaying the data flow/data flow file by using a visual chart.
Correspondingly, embodiments of the present specification also provide a non-volatile computer storage medium storing computer-executable instructions configured to:
aiming at user terminals of different operating systems, according to the authority of a user at the user terminal, adapting a corresponding flow acquisition mode to the user terminal;
acquiring data traffic through the corresponding traffic acquisition mode so as to send the data traffic to a cloud display subsystem;
wherein the authority is Root authority or non-Root authority.
Correspondingly, embodiments of the present description also provide another non-volatile computer storage medium storing computer-executable instructions configured to:
receiving a data flow/data flow file;
and displaying the data flow/data flow file by using a visual chart.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, as for the method, apparatus, device and medium embodiments, since they are substantially similar to the system embodiments, the description is simple, and reference may be made to part of the description of the system embodiments for relevant points, which is not repeated here.
The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps or modules recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.
The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functions of the units may be implemented in the same software and/or hardware or in one or more pieces of software and/or hardware when implementing the embodiments of the present description.
As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include transitory computer readable media (transient media) such as modulated data signal numbers and carrier waves.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
As will be appreciated by one skilled in the art, one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and so forth) having computer-usable program code embodied therein.
Embodiments of the present description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular transactions or implement particular abstract data types. Embodiments of the present description may also be practiced in distributed computing environments where transactions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
The above description is only an example of the present specification, and is not intended to limit the present application. Various modifications and changes may occur to the embodiments described herein, as will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the embodiments of the present specification should be included in the scope of the claims of the present application.