阅读说明：本技术 实时存储数据的文件系统处理方法、装置、车载终端及商用车 (File system processing method and device for storing data in real time, vehicle-mounted terminal and commercial vehicle ) 是由 刘迎午 汤广松 于 2021-07-14 设计创作，主要内容包括：本申请提供一种实时存储数据的文件系统处理方法、装置、车载终端及商用车,其中文件系统处理方法包括：发起写文件请求；判断写文件是否为祼设备文件系统类型；如果为裸设备文件系统类型,则去掉存储写操作中页缓存分配和对文件元数据的更新操作,直接将数据写入物理存储介质；如果不为裸设备文件系统类型,则更新文件的元数据,将数据写入页缓存,将页缓存数据写入物理存储介质。根据本申请的方法能够提高智能安全视频监控终端数据存储的实时性,保证在存储介质工作失效瞬间前的行车记录数据可靠实时存储。(The application provides a file system processing method and device for storing data in real time, a vehicle-mounted terminal and a commercial vehicle, wherein the file system processing method comprises the following steps: initiating a file writing request; judging whether the written file is of a bare device file system type; if the file system type is the bare equipment file system type, removing page cache allocation and updating operation on file metadata in storage and writing operation, and directly writing data into a physical storage medium; and if the file is not the file system type of the bare equipment, updating the metadata of the file, writing the data into the page cache, and writing the page cache data into a physical storage medium. According to the method, the real-time performance of data storage of the intelligent safety video monitoring terminal can be improved, and the driving record data before the moment of working failure of the storage medium can be reliably stored in real time.)

1. A file system processing method for storing data in real time is used for monitoring a commercial vehicle, and is characterized by comprising the following steps:

initiating a file writing request;

judging whether the written file is of a bare device file system type;

if the file system type is the bare equipment file system type, removing page cache allocation and updating operation on file metadata in storage and writing operation, and directly writing data into a physical storage medium;

and if the file is not the file system type of the bare equipment, updating the metadata of the file, writing the data into the page cache, and writing the page cache data into a physical storage medium.

2. The method of claim 1, wherein determining whether the write file is of a bare device file system type comprises:

and judging whether the file is of a bare device file system type or not through the inode of the file.

3. The method of claim 1, further comprising:

the physical storage medium is a nonvolatile storage medium and comprises a hard disk and an SD card.

4. The method of claim 1, further comprising:

and partitioning the physical storage medium in blocks, and adopting a continuous allocation strategy for physical disk blocks of the same file to reduce addressing consumption.

5. The method of claim 1, further comprising:

the time taken to directly write data to the physical storage medium is less than 10 ms.

6. The method of claim 1, further comprising:

and after the real-time data is written in, backing up the data to the disaster recovery storage device.

7. The method of claim 1, further comprising:

the method is realized by writing a file library function through a heavy-load system.

8. An apparatus for file system processing of real-time stored data, comprising:

the request module is used for initiating a file writing request;

the judging module is used for judging whether the written file is of a bare device file system type;

the bare device processing module is used for removing page cache allocation and updating operation on file metadata in storage and writing operation aiming at the type of a file system of the bare device and directly writing data into a physical storage medium;

and the general file processing module is used for updating the metadata of the file, writing the data into the page cache and writing the page cache data into the physical storage medium.

9. A vehicle-mounted terminal characterized by comprising:

memory, processor and computer program stored in the memory and executable on the processor, characterized in that the processor implements the method of any of the preceding claims 1-8 when executing the computer program.

10. A commercial vehicle comprising the in-vehicle terminal according to claim 9.

Technical Field

The invention relates to the field of video monitoring of commercial vehicles, in particular to a file system processing method and device for storing data in real time, a vehicle-mounted terminal and a commercial vehicle.

Background

With the rapid development of intelligent transportation and internet of vehicles in China, a good opportunity is brought to the popularization of intelligent safety video monitoring terminals of commercial vehicles. However, how to ensure the storage safety and real-time performance of multimedia data and vehicle data becomes an important index of product reliability.

Due to the complexity of the working environment of the commercial vehicle, the commercial vehicle is often influenced by factors such as vibration, electromagnetic interference, voltage fluctuation, current conflict, instant accidental power failure and the like; particularly, when an accident occurs, the factors are easy to simultaneously occur to cause that the storage medium cannot work normally, so that how to ensure the real-time storage of data before the accident occurs can restore the scene when the accident occurs through various driving data stored in the storage medium after the accident occurs, and the accident cause can be conveniently and quickly defined, the accident responsibility can be judged, and the precautionary measures for formulating the accident can be played a positive role.

The intelligent safety video monitoring terminal can be used for frequently touching the scene, after a commercial vehicle accident happens, the storage medium in the intelligent safety video monitoring terminal is taken out for playing, audio and video information and vehicle related data in a period of time before and after the frequent accident are lost, so that key information is difficult to recover when the accident happens, and great difficulty is brought to case detection and responsibility determination.

Disclosure of Invention

The application aims to provide a file system processing method and device for storing data in real time and electronic equipment, the file system and the file writing process are simply changed, different storage media are completely compatible, and the problem that the data are not timely stored and lost when the storage media work abnormally by a commercial vehicle intelligent safety video monitoring terminal can be effectively solved.

According to one aspect of the present application, a method for processing a file system storing data in real time is provided, which is used for commercial vehicle monitoring, and comprises the following steps:

initiating a file writing request;

judging whether the written file is of a bare device file system type;

if the file system type is the bare equipment file system type, removing page cache allocation and updating operation on file metadata in storage and writing operation, and directly writing data into a physical storage medium;

and if the file is not the file system type of the bare equipment, updating the metadata of the file, writing the data into the page cache, and writing the page cache data into a physical storage medium.

According to some embodiments, the aforementioned method further comprises:

and judging whether the file is of a bare device file system type or not through the inode of the file.

According to some embodiments, the aforementioned method further comprises that the physical storage medium is a nonvolatile storage medium, including a hard disk and an SD card.

According to some embodiments, the aforementioned method further comprises:

and partitioning the physical storage medium in blocks, and adopting a continuous allocation strategy for physical disk blocks of the same file to reduce addressing consumption.

According to some embodiments, the aforementioned method further comprises:

the time taken to directly write data to the physical storage medium is less than 10 ms.

According to some embodiments, the aforementioned method further comprises:

and after the real-time data is written in, backing up the data to the disaster recovery storage device.

According to some embodiments, the aforementioned method further comprises:

the method is realized by writing a file library function through a heavy-load system.

According to another aspect of the present application, there is provided an apparatus for file system processing of real-time storage data, including:

the request module is used for initiating a file writing request;

the judging module is used for judging whether the written file is of a bare device file system type;

the bare device processing module is used for removing page cache allocation and updating operation on file metadata in storage and writing operation aiming at the type of a file system of the bare device and directly writing data into a physical storage medium;

and the general file processing module is used for updating the metadata of the file, writing the data into the page cache and writing the page cache data into the physical storage medium.

According to another aspect of the present application, there is provided a vehicle-mounted terminal including:

memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that the processor implements the method of any of the above when executing the computer program.

According to another aspect of the present application, there is provided a commercial vehicle including the vehicle-mounted terminal described above.

According to the exemplary embodiment of the application, different storage media are completely compatible by only simply changing the file system and the file writing process.

According to the embodiment of the application, the problem that data are not timely stored and lost when the storage medium works abnormally by the intelligent and safe video monitoring terminal of the commercial vehicle can be effectively solved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without exceeding the protection scope of the present application.

FIG. 1 illustrates a write function write file flow diagram in accordance with an exemplary embodiment.

FIG. 2 illustrates a flow diagram of a fsync function write file according to an exemplary embodiment.

FIG. 3 shows a schematic flow diagram of a file write operation invocation according to an example embodiment of the present application.

Fig. 4 shows a schematic diagram of a vehicle-mounted terminal data transmission system according to an example embodiment of the present application.

Fig. 5 is a flowchart illustrating a file system processing method for storing data in real time according to an exemplary embodiment of the present application.

Fig. 6 shows a block diagram of a file system processing device storing data in real time according to an example embodiment of the present application.

Fig. 7 shows a block diagram of the components of a vehicle-mounted terminal according to an exemplary embodiment.

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 embodiments 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 same reference numerals denote the same or similar parts in the drawings, and thus, a repetitive description thereof will be omitted.

Furthermore, 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 application. One skilled in the relevant art will recognize, however, that the subject matter of the present application can be practiced without one or more of the specific details, or with other methods, components, devices, steps, and so forth. In other instances, well-known methods, devices, implementations, or operations have not been shown or described in detail to avoid obscuring aspects of the application.

The block diagrams shown in the figures are functional entities only and do not necessarily correspond to physically separate entities. I.e. these functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor means and/or microcontroller means.

The flow charts shown in the drawings are merely illustrative and do not necessarily include all of the contents and operations/steps, nor do they necessarily have to be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the actual execution sequence may be changed according to the actual situation.

It will be understood that, although the terms first, second, third, etc. may be used herein to describe various components, these components should not be limited by these terms. These terms are used to distinguish one element from another. Thus, a first component discussed below may be termed a second component without departing from the teachings of the present concepts. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items.

It will be appreciated by those skilled in the art that the drawings are merely schematic representations of exemplary embodiments, and that the blocks or processes shown in the drawings are not necessarily required to practice the present application and are, therefore, not intended to limit the scope of the present application.

At present, the Linux operating system has the internal design of a file system which is mostly very complex, good in universality and multiple in functions. However, for data file storage in special scenes, the complex storage structures of the data files cause large storage delay and limit system performance, and many functions in the complex designs cannot be used. The method for improving the real-time property of write-in data by the current general file system comprises the following steps: when the operating system implements certain file I/O (e.g., disk files). To ensure I/O efficiency. A dedicated area (memory or separate I/O address space) is typically used in the kernel as an I/O data buffer.

The application can view this chip area as a high-speed hub for I/O data. When the write () function is called to write out data. Once the data is written to the buffer. The function immediately returns. The data written at this time can be read back with read () and also read by other processes, but it does not mean that they have been written to the external persistent storage medium, even after the file is closed by calling close ().

The data in the kernel I/O data buffer is only transmitted by the peripheral started by the operating system when appropriate, and the real transmission action is finished by a peripheral controller independent from the CPU or the peripheral (Linux is called as a DMA engine).

Therefore, from the viewpoint that data is actually written to the disk, file data written out with write () is not completely synchronized with the external storage device. In modern computer systems, such asynchronous time intervals are very short, typically only a few seconds or a dozen seconds, depending in detail on the amount of data written and the state of the I/O data buffer. Although the interval of non-synchronization is very short, it can be assumed that a power loss or system crash occurs during this period, which results in the situation where the written data is lost in time to the disk.

For this reason, Linux provides two means to achieve this. One of the methods is to set an O _ SYNC flag to a file. This ensures that each write data is written directly to the disk. Assuming this flag is set, the write () call will not return until after the data has been safely written to disk (without going through the system's I/O buffers) (see FIG. 1). However, it is inefficient to keep synchronization every time data (metadata and data) is written, and data accumulation is liable to occur when writing a large amount of data, and real-time writing is impossible.

Yet another approach is to call the function fsync () only when needed, which forces all the modified data (containing data in the in-core I/O buffers) of the file to which the descriptive statement file (file descriptor) is attached to be transferred to the external persistent medium. I.e. all information of the file given by the files is refreshed. The process that calls fsync () will jam until the device reports that the transfer has been completed. Here "all changed data" includes data written by the user as well as characteristic data of the file itself. Such as access time, change time, owner of the file, etc. (see fig. 2). It results in a long time consuming operation and is also not suitable for frequent use in large data writes.

In the monitoring of specific services of commercial vehicles, for example, a freight vehicle needs to travel for a long time in a long distance, and is often influenced by factors such as vibration, electromagnetic interference, voltage fluctuation, current conflict, instant accidental power failure and the like due to the complexity of a traveling environment; these factors are more likely to occur simultaneously, especially in the event of an accident, resulting in the storage medium not functioning properly. The invention provides a file system and a file writing operation process thereof aiming at the specific service requirement of commercial vehicle monitoring, and ensures the real-time performance of data writing as much as possible, so that the real-time data writing of the intelligent and safe video monitoring terminal of the commercial vehicle can reach the 10ms level. After an accident occurs, the scene of the accident can be restored through various driving data stored in the storage medium, so that the accident occurrence reason can be conveniently and quickly defined, and the accident responsibility can be judged.

Exemplary embodiments of the present application will be described below with reference to the accompanying drawings.

FIG. 3 shows a schematic flow diagram of a file write operation invocation according to an example embodiment of the present application.

Referring to the virtual file system architecture of FIG. 3, the dashed lines represent the modified file write operation invocation schematic.

Virtual File Systems (VFS) were created by Sun microsystems, Inc. when defining the Network File System (NFS). It is a distributed file system for network environments that is an interface that allows different file system implementations from the operating system. The Virtual File System (VFS) is an interface layer between the physical file system and the service that abstracts all the details of each file system of Linux, so that different file systems appear the same to the Linux kernel and other processes running in the system. Strictly speaking, VFS is not a practical file system. It exists only in memory and not in any external memory space. The VFS is established at system start-up and disappears at system shut-down.

Linux is a new operating system developed in recent years, and one of the most important features of Linux is to support multiple file systems, so that Linux is more flexible and coexists with many other operating systems. Linux supports various file systems such as ext, ext2, xia, minix, umsdos, msdes, fat32, ntfs, proc, stub, ncp, hpfs, affs, ufs and the like. In order to achieve the purpose, Linux adopts a uniform file interface for all file systems, and a user operates different file systems through an operation interface of files. For the user, we do not care about the specific operation process of different file systems, but only operate a virtual file operation interface, which is the Virtual File System (VFS) of Linux. Therefore, each file system does not interfere with each other, and only calls the corresponding program to realize the functions of the file systems. In the kernel file of Linux, VFS and specific file system programs are all placed in Linux \ FS, where each file system corresponds to a subdirectory, and there are some common VFS programs.

In a specific implementation, each file system has its own file-operations data structure. Therefore, the VFS is used as a software layer in the Linux kernel to provide a file system interface for programs in the user space, and also provides an abstraction function in the kernel to allow different file systems to coexist well. The VFS has a common interface to various special file systems, such as superblocks, inodes, file manipulation function entries, etc. The details of the actual file system, uniformly indexed by the common interface of the VFS, are transparent to the system kernel and user processes.

The file system real-time scheme is mainly realized by eliminating uncertain time delay introduced to the execution of a process when the file system writes files. 1. The time delay of data writing caused by the allocation and management of the general file system page cache in the storage writing operation is removed; 2. removing the updating operation of the file metadata in the general file system in the storage writing operation, and only updating data; 3. and removing the middle layer of a specific file system, directly writing the bare device, and ensuring that the application layer adopts a continuous allocation strategy for the physical disk blocks of the same file, thereby reducing addressing consumption.

Fig. 4 shows a schematic diagram of a vehicle-mounted terminal data transmission system according to an example embodiment of the present application.

As shown in fig. 4, the in-vehicle terminal data transmission system includes an in-vehicle terminal apparatus 101, a network 102, and a server 103.

It should be understood that the number of terminals, server devices and networks in fig. 4 is merely illustrative. There may be any number of terminals, server devices and networks, as is practical.

The network 102 may be a medium that provides an internet communication link between the in-vehicle terminal apparatus 101 and the server 103, and may include various connection types such as a mobile communication link and the like.

The in-vehicle terminal apparatus 101 may be an electronic apparatus having a display screen, and includes one or more processors and storage devices, and may interact with the server 103 via the network 102 to receive or send a message or the like.

According to an example embodiment, the server 103 receives multimedia data, vehicle positioning data, and the like transmitted by the in-vehicle terminal apparatus 101 in the present application.

Alternatively, the vehicle-mounted terminal device 101 may be applied to various commercial vehicles, such as passenger cars, freight cars, dangerous goods cars, buses, new energy cars, school buses, commercial concrete cars, muck cars, taxis, and the like. For example, a freight car needs to travel for a long distance and a long time, and is often influenced by factors such as vibration, electromagnetic interference, voltage fluctuation, current conflict, instant accidental power failure and the like due to the complexity of a traveling environment; particularly, when an accident occurs, the factors are easy to occur simultaneously, so that the storage medium cannot work normally, the file writing operation process of the embodiment of the application ensures the real-time data writing as much as possible, the real-time data writing of the commercial vehicle terminal can reach the 10ms level, the scene of the accident can be restored through various driving data stored in the storage medium after the accident occurs, and the accident occurrence reason can be conveniently and quickly defined and the accident responsibility can be judged.

Fig. 5 is a flowchart illustrating a file system processing method for storing data in real time according to an exemplary embodiment of the present application.

At S501, a library function is called to initiate a write file request.

According to some embodiments, the library function write is rewritten and called to write to the file.

At S503, an opened file list item of the virtual file system is located;

the opened file list entry to the virtual file system is located by examining the file descriptor of the process.

In S505, the inode of the file is found by searching in the directory entry module.

With some embodiments, the write () function links to the directory entry module through the file table entry, retrieves in the directory entry module according to the incoming file path, finding the inode for the file.

Files are stored on a hard disk, and the smallest unit of storage of the hard disk is called a "Sector" (Sector). Each sector stores 512 bytes (equivalent to 0.5 KB). When the operating system reads the hard disk, the hard disk is not read by sectors, so that the efficiency is low, and a plurality of sectors are continuously read at one time, namely one block (block) is read at one time. Such a "block" consisting of a plurality of sectors is the minimum unit of file access. The "block" size is most commonly 4KB, i.e., eight sectors in a row make up a block.

The file data is stored in "blocks", and it is obvious that one must also find a place to store the "meta-information" of the file, such as the creator of the file, the creation date of the file, the size of the file, etc. This area storing meta-information of the file is called an inode, and Chinese is translated as an "inode".

Each file has a corresponding inode that contains some information about the file. The inode contains meta-information of the file, specifically the following:

size: the number of bytes of the file; uid: user ID of the file owner; gid: group ID of the file; access: the read, write and execution authority of the file; time stamp of the file, three in total: change refers to the last Change time of the inode; the Modify refers to the last time the file content changed; access refers to the last time when the file is opened; inode: the location of the file data block; number of Blocks; IO Blocks: a block size; device: device number, etc.

Each inode has a number, and the operating system identifies different files by the inode number. The Unix/Linux system does not internally use filenames, but uses inode numbers to identify files. For the system, the file name is just another name or nickname which is convenient for the inode number to identify. Ostensibly, the user opens the file by file name. In fact, this process is divided into three steps inside the system: firstly, the system finds the inode number corresponding to the file name; secondly, obtaining the inode information through the inode number; and finally, finding the block where the file data is located according to the inode information, and reading out the data.

In S507, it is determined whether the file is of the bare device file system type according to the inode of the file.

A raw device, also called a raw partition (original partition), is a special block device file that is not formatted and is not read by Unix through a file system. It is up to the application program to read and write it.

In S509, for the bare-device file system type, closing the update of the write operation on the file metadata, where the file metadata mainly includes: file size, device identifier, user group identifier, file mode, extended attributes, timestamp of file read or modification, number of links, pointers to disk blocks storing the content, file classification, etc.

In S511, the management operation related to the search hit of the page cache is directly skipped for the bare-device file system type.

When the original write () function is called to write out data, the data is written into a kernel I/O data buffer, namely a page cache, and the data in the buffer is only started by an operating system for transmission when appropriate.

In S513, for the bare-device file system type, data is directly written to the physical storage device until the write completion returns.

According to some embodiments, the physical storage medium is a non-volatile storage medium, including a hard disk, an SD card, or the like. And the physical storage medium is divided into blocks, and a continuous allocation strategy is adopted for the physical disk blocks of the same file, so that the addressing consumption is reduced.

According to some embodiments, after the real-time data is written, the written data is backed up to another disaster recovery storage device at the same time, and the storage device can also be a bare device.

In S515-S519, the original file writing operation steps for the write function are not described herein again.

According to some embodiments, the file writing operation process improves the real-time performance of data writing, and enables the real-time data writing of the commercial vehicle terminal to reach the 10ms level.

It should be clearly understood that this application describes how to make and use particular examples, but the application is not limited to any details of these examples. Rather, these principles can be applied to many other embodiments based on the teachings of the present disclosure.

Those skilled in the art will appreciate that all or part of the steps implementing the above embodiments are implemented as computer programs executed by a CPU. When executed by the CPU, performs the functions defined by the methods provided herein. The program of (a) may be stored in a computer readable storage medium, which may be a read-only memory, a magnetic or optical disk, or the like.

Furthermore, it should be noted that the above-mentioned figures are only schematic illustrations of the processes involved in the method according to exemplary embodiments of the present application, 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.

Having described example embodiments, those skilled in the art will readily appreciate that a method of file system processing for storing data in real time according to embodiments of the present application may have at least one or more of the following advantages.

According to an exemplary embodiment, different storage media are fully compatible by only making simple changes to the file system and the file write flow.

According to the embodiment, the problem that data are not timely stored and lost when the storage medium works abnormally by the intelligent and safe video monitoring terminal of the commercial vehicle can be effectively solved.

FIG. 6 illustrates a block diagram of a file system processing device that stores data in real-time, according to an example embodiment. The apparatus shown in fig. 6 may perform the aforementioned method for file system processing of real-time storage data according to an embodiment of the present application.

As shown in fig. 6, the file system processing apparatus for storing data in real time may include: a request module 610, a judgment module 620, a bare device processing module 630 and a general file processing module 640.

Referring to fig. 6 and with reference to the previous description:

a request module 610, configured to initiate a file writing request;

the judging module 620 is configured to judge whether the write file is of a bare device file system type;

the bare device processing module 630 is configured to, for a bare device file system type, remove page cache allocation and update operations on file metadata in a storage write operation, and directly write data into a physical storage medium;

the general file processing module 640 is configured to update metadata of a file, write data into a page cache, and write page cache data into a physical storage medium.

The device performs functions similar to those of the method provided above, and other functions can be referred to above, and will not be described again here.

FIG. 7 shows a block diagram of an electronic device according to an example embodiment.

An electronic device 200 according to this embodiment of the present application is described below with reference to fig. 7. The electronic device 200 shown in fig. 7 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.

As shown in fig. 7, the electronic device 200 is embodied in the form of a general purpose computing device. The components of the electronic device 200 may include, but are not limited to: at least one processing unit 210, at least one memory unit 220, a bus 230 connecting different system components (including the memory unit 220 and the processing unit 210), a display unit 240, and the like.

Wherein the storage unit stores program code that can be executed by the processing unit 210 such that the processing unit 210 performs the methods according to various exemplary embodiments of the present application described herein. For example, the processing unit 210 may perform the methods as shown in fig. 3, 4.

The storage unit 220 may include readable media in the form of volatile storage units, such as a random access memory unit (RAM)2201 and/or a cache memory unit 2202, and may further include a read only memory unit (ROM) 2203.

The storage unit 220 may also include a program/utility 2204 having a set (at least one) of program modules 2205, such program modules 2205 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 230 may be one or more 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 200 may also communicate with one or more external devices 300 (e.g., keyboard, pointing device, bluetooth device, etc.), with one or more devices that enable a user to interact with the electronic device 200, and/or with any devices (e.g., router, modem, etc.) that enable the electronic device 200 to communicate with one or more other computing devices. Such communication may occur via an input/output (I/O) interface 250. Also, the electronic device 200 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 260. The network adapter 260 may communicate with other modules of the electronic device 200 via the bus 230. 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 200, 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. The technical solution according to the embodiments of the present application 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, or a network device, etc.) to execute the above method according to the embodiments of the present application.

The software 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 storage 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 storage 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 storage 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 of the present application 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).

Those skilled in the art will appreciate that the modules described above may be distributed in the apparatus according to the description of the embodiments, or may be modified accordingly in one or more apparatuses unique from the embodiments. The modules of the above embodiments may be combined into one module, or further split into multiple sub-modules.

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 embodiment of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can 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 can be a personal computer, a server, a mobile terminal, or a network device, etc.) to execute the method according to the embodiment of the present application.

Exemplary embodiments of the present application are specifically illustrated and described above. It is to be understood that the application is not limited to the details of construction, arrangement, or method of implementation described herein; on the contrary, the intention is to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.