File uploading method and device, storage medium, electronic equipment and program product

Abstract

The invention discloses a file uploading method and device, a storage medium, electronic equipment and a program product, and relates to the technical field of computer networks and distributed storage, and the method comprises the steps: collecting metadata of a to-be-uploaded file and a network state of an uploading path between a client and a server in real time; calculating the size of a target fragment of the to-be-uploaded file for data uploading between the client and the server through the metadata and the network state; segmenting the to-be-uploaded file based on the target fragment size to obtain a plurality of data blocks; according to the method, the plurality of data blocks are used for uploading the file from the client to the server, and the uploading parameters of the different data blocks are recorded, so that the uploading result of the file to be uploaded transmitted to the server is determined through the uploading parameters, the technical problem that the uploading efficiency and robustness of the object storage system are poor is solved, and the uploading efficiency of the object storage system is improved. The technical effect of improving the uploading efficiency and robustness of the object storage system is achieved.

Description

Technical Field

[0001] The embodiments of the present application relate to the technical fields of computer networks and distributed storage. Specifically, the present application relates to a method, apparatus, storage medium, electronic device, and program product for uploading files. Background Art

[0002] With the development of Internet technology, file upload technology has also been widely applied. During the file upload process, the file to be uploaded is usually divided into multiple data blocks, and then the multiple data blocks are uploaded to the server separately to improve the file upload efficiency. Common file upload methods based on object storage generally use a fixed shard size and a simple retransmission mechanism as the main implementation means. However, since the fixed shard size cannot adapt to the dynamically changing network state (such as bandwidth fluctuations, increased latency, and changes in packet loss rate), when the network condition is poor, the fixed small shards will cause frequent request overheads and reduce the upload efficiency; while when the network condition is good, the fixed large shards may increase the probability of single transmission failure and affect the overall stability. Secondly, the related technologies rely on the server to return the status of the entire upload task and lack refined management of the status of each shard, and the retransmission failure rate of large shards is high. Therefore, the solutions in the related technologies cannot upload files under different stable network environments, and at the same time, they cannot effectively detect the data blocks during the file upload process, and usually only do so when the file upload fails. As a result, the overall file upload process is complex and the transmission efficiency is low.

[0003] In view of the problem of poor upload efficiency and robustness of the object storage system in the related technologies, no effective solution has been proposed yet. Summary of the Invention

[0004] The embodiments of the present application provide a method, apparatus, storage medium, electronic device, and program product for uploading files, so as to at least solve the problem of poor upload efficiency and robustness of the object storage system in the related technologies.

[0005] According to an embodiment of the present application, there is provided a method for uploading a file. The file to be uploaded is segmented based on the target shard size to obtain multiple data blocks; the multiple data blocks are used to upload the file from the client to the server, and the upload parameters of different data blocks are recorded to determine the upload result of the file to be uploaded transmitted to the server through the upload parameters.

[0006] According to another embodiment of the present application, there is provided an apparatus for uploading a file, including: a collection module, configured to collect in real time the metadata of the file to be uploaded and the network status of the upload path between the client and the server; a calculation module, configured to calculate, based on the metadata and the network status, a target shard size for data upload of the file to be uploaded between the client and the server;

[0007] a splitting module, configured to perform splitting processing on the file to be uploaded based on the target shard size to obtain a plurality of data blocks; an upload module, configured to upload the file from the client to the server using the plurality of data blocks and record the upload parameters of different data blocks, so as to determine the upload result of the file to be uploaded transmitted to the server through the upload parameters.

[0008] According to still another embodiment of the present application, there is further provided a computer-readable storage medium, in which a computer program is stored, and wherein the computer program is configured to execute the steps in any one of the above method embodiments when running.

[0009] According to still another embodiment of the present application, there is further provided an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0010] According to still another embodiment of the present application, there is further provided a computer program product, including a computer program, and the computer program, when executed by a processor, implements the steps in any one of the above method embodiments.

[0011] Through this application, before and during the upload process, basic information (metadata) about the file to be uploaded and the network conditions between the client and the server are continuously collected. This includes the file size, type, as well as real-time network bandwidth, latency, and packet loss rate, etc. Before and during the upload process, basic information (metadata) about the file to be uploaded and the network conditions between the client and the server are continuously collected. This includes the file size, type, as well as real-time network bandwidth, latency, and packet loss rate, etc. According to the file metadata and network status collected in real time, the shard size most suitable for the current upload conditions is calculated, and the large file to be uploaded is split into several smaller data blocks according to the calculated target shard size. These data blocks are used for concurrent upload, that is, multiple data blocks can be transmitted to the server simultaneously, thus accelerating the upload process. Then, according to the metadata of the file to be uploaded and the network status collected in real time on the client and the server side, the target shard size is dynamically calculated, the file is split and uploaded according to the target shard size, and the upload parameters are recorded to determine the upload result. Through the above method, the technical problems of poor upload efficiency and robustness of the object storage system are solved, and the technical effect of improving the upload efficiency and robustness of the object storage system is achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] To more clearly illustrate the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0013] Figure 1 is the hardware structure block diagram of the server device for a file upload method according to an embodiment of the present application;

[0014] Figure 2 is the flowchart of the file upload method according to an embodiment of the present application;

[0015] Figure 3 is the schematic diagram of the module composition of an adaptive shard upload architecture based on object storage according to an embodiment of the present application;

[0016] Figure 4 is the flowchart of an adaptive shard upload process based on object storage according to an embodiment of the present application;

[0017] Figure 5 is the structure block diagram of the file upload device according to an embodiment of the present application;

[0018] Figure 6 is the computer system structure block diagram of the electronic device according to an embodiment of the present application;

[0019] Among them, 102 in the above figure is a processor, 104 is a memory, 106 is a transmission device, 108 is an input / output device, 52 is a collection module, 54 is a calculation module, 56 is a segmentation module, 58 is an upload module, 800 is a computer system, 801 is a CPU, 802 is a ROM, 803 is a RAM, 804 is a bus, 805 is an I / O interface, 806 is an input part, 807 is an output part, 808 is a storage part, 809 is a communication part, 810 is a driver, and 811 is a removable medium. Detailed implementation manners

[0020] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the protection scope of the present application.

[0021] It should be noted that in the description of the present application, the terms "include", "comprise" or any other variant thereof are intended to cover a non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or device. The terms "first", "second", etc. in the present application are used to distinguish similar objects, rather than to describe a specific order or sequence.

[0022] In order to enable those skilled in the art of the present technology to better understand the solution of the present application, the present application will be further described in detail below in conjunction with the accompanying drawings and specific implementation manners.

[0023] As an optional implementation manner, the method embodiments provided in the embodiments of the present application can be executed on a server device or a similar computing device. Taking running on a server device as an example, Figure 1 is a hardware structure block diagram of a server device for an upload method of a file in an embodiment of the present application. As Figure 1 shown, the server device may include one or more ( Figure 1 only one is shown in the figure) processors 102 (the processor 102 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data. Among them, the above server device may further include a transmission device 106 for communication functions and an input / output device 108. Those of ordinary skill in the art can understand that Figure 1 the structure shown is only schematic and does not limit the structure of the above server device. For example, the server device may further include more than Figure 1more or fewer components shown therein, or having a configuration different from that Figure 1 shown.

[0024] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the file uploading method in the embodiments of the present application. The processor 102 executes various functional applications and data processing by running the computer programs stored in the memory 104, that is, implements the above-mentioned method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some instances, the memory 104 may further include a memory remotely disposed relative to the processor 102, and these remote memories can be connected to the server device through a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0025] The transmission device 106 is used to receive or send data via a network. Specific examples of the above-mentioned network may include a wireless network provided by a communication provider of the server device. In one instance, the transmission device 106 includes a network adapter (Network Interface Controller, abbreviated as NIC), which can be connected to other network devices through a base station and thus can communicate with the Internet. In one instance, the transmission device 106 can be a radio frequency (Radio Frequency, abbreviated as RF) module, which is used to communicate with the Internet wirelessly.

[0026] In this embodiment, a file uploading method is provided. Figure 2 is a flowchart of the file uploading method according to the embodiments of the present application, as Figure 2 shown, and the process includes the following steps:

[0027] Step S202, collect the metadata of the file to be uploaded and the network status of the upload path between the client and the server in real time; optionally, in this step S202, the client actively collects information (metadata) about the file to be uploaded and the status of the current network environment. The metadata may include attributes such as the size, type, and creation date of the file, while the network status covers key metrics such as real-time bandwidth, latency, and packet loss rate. This is to make more reasonable upload strategy decisions based on these data later.

[0028] Step S204: Calculate the target shard size for data upload between the client and the server based on metadata and network status. That is to say, after collecting metadata and network status information, a specific algorithm is used to calculate the optimal shard size. This calculation takes into account the characteristics of the file (such as whether it is a text, video, or compressed file) and the current network conditions (such as sufficient bandwidth or high latency). The dynamic calculation of the target shard size enables the upload operation to more flexibly handle different files and network environments, thereby improving the upload efficiency.

[0029] Step S206: Split the file to be uploaded based on the target shard size to obtain multiple data blocks.

[0030] Optionally, according to the optimal shard size calculated in step S204, the file to be uploaded is split into multiple smaller data blocks (Chunks). The sizes of these data blocks are consistent, which is convenient for subsequent upload operations. A code block composed of the file to be uploaded and its dependent modules is called a Chunk. The generation of Chunks is the basis of the shard upload technology, which allows files to be uploaded in parallel, thereby accelerating the entire file transfer process.

[0031] Step S208: Use multiple data blocks to upload the file from the client to the server and record the upload parameters of different data blocks to determine the upload result of the file to be uploaded to the server through the upload parameters.

[0032] It can be understood that the data blocks generated in step S206 are uploaded to the server respectively, and the parameters during the upload of each data block are recorded, such as the protocol used, network conditions, upload start and end times, etc. These parameters help monitor the upload process and determine whether each data block is uploaded successfully. If a data block fails to upload, the reason can be traced through the recorded parameters and a decision can be made on whether to retry or take other measures. In addition, the determination of the upload result also includes tracking the upload status of the entire file to ensure the integrity and consistency of the file.

[0033] Through the above method, before and during the upload start, continuously collect the basic information (metadata) of the file to be uploaded and the network conditions between the client and the server. This includes the file size, type, and real-time network bandwidth, latency, and packet loss rate, etc. Before and during the upload start, continuously collect the basic information (metadata) of the file to be uploaded and the network conditions between the client and the server. This includes the file size, type, and real-time network bandwidth, latency, and packet loss rate, etc. According to the file metadata and network status collected in real time, calculate the shard size most suitable for the current upload conditions, and split the large file to be uploaded into several smaller data blocks according to the calculated target shard size. Use these data blocks for concurrent upload, that is, multiple data blocks can be transmitted to the server simultaneously, thus accelerating the upload process. Then, according to the metadata of the file to be uploaded and the network status collected in real time on the client and the server side, dynamically calculate the target shard size, split and upload the file according to the target shard size, and record the upload parameters to determine the upload result. Through the above method, the technical problems of poor upload efficiency and robustness of the object storage system are solved.

[0034] In an exemplary embodiment, calculating the target shard size for data upload between the client and the server for the file to be uploaded through metadata and network status includes: determining the file parameters of the file to be uploaded according to the metadata, where the file parameters at least include: the total file size of the file to be uploaded, the file type of the file to be uploaded; determining the network parameters for file transmission between the client and the server according to the network status, where the network parameters at least include: the upload path bandwidth between the client and the server, the network latency between the client and the server, the packet loss rate between the client and the server; inputting the file parameters and network parameters into a preset adaptive shard calculation formula to obtain the target shard size for data upload between the client and the server.

[0035] In an exemplary embodiment, the preset adaptive shard calculation formula is: P = α × (B / R) × (1 - L / 100) × log 10 (S), where P is the target shard size, α is the file type coefficient, B is the upload path bandwidth, R is the network protocol overhead coefficient, L is the packet loss rate, S is the total file size, and log 10 (S) is the file size logarithmic term.

[0036] In short, by analyzing the metadata of the file to be uploaded, parameters related to the file are determined. These parameters at least include the total size of the file and the file type. The total file size (S) is crucial for calculating the number of shards, while the file type (T) affects the calculation of the shard size. Different types of files may have different optimal shard sizes due to different content natures (such as text, video, or compressed files). At the same time, the network status between the client and the server is monitored in real time. These network parameters at least include the bandwidth (B) of the upload path, network latency (D), and packet loss rate (L). Bandwidth determines the speed of data transmission, while network latency and packet loss rate affect the reliability and efficiency of transmission. These parameters are extremely crucial for calculating the optimal shard size and adjusting the upload strategy. By inputting the obtained file parameters and network parameters into a pre-set calculation formula, the system can dynamically calculate the target shard size (P). This calculation formula takes into account the size, type of the file, and real-time network conditions, including bandwidth, latency, and packet loss rate, to determine a dynamic shard size that can both maximize bandwidth utilization and ensure upload stability.

[0037] In summary, by comprehensively analyzing the size, type of the file, and real-time network conditions (bandwidth, latency, packet loss rate), the optimal shard size is dynamically determined, thereby optimizing the data upload efficiency and stability from the client to the server. Compared with the traditional fixed shard size upload, it is more intelligent and adaptable, and can automatically adjust in different network environments to achieve the best upload effect.

[0038] In an exemplary embodiment, before the metadata of the file to be uploaded and the network status of the upload path between the client and the server are collected in real time, the above method further includes: obtaining the maximum transmission rate between the client and the server; determining the polling time for real-time collection according to the maximum transmission rate, and setting a monitoring thread based on the polling time.

[0039] It is understandable that before any upload operation starts, the maximum transmission rate between the client and the server (usually referred to as peak bandwidth or maximum bandwidth) is first estimated or measured. This is done through a series of tests or pre-configured parameters, such as using a network performance testing tool to measure the speed, or predicting based on historical data and empirical rules. The maximum transmission rate is an important indicator for measuring the transmission capacity of the network channel and provides basic data for subsequent shard size calculation and upload strategy. Once the maximum transmission rate is obtained, based on this information, the frequency of monitoring the network status and file metadata, that is, the polling time, is determined. The length of the polling time affects the real-time performance and accuracy of data collection. If the maximum transmission rate is very high, meaning the network connection is very stable, a longer polling time can be set to reduce the running frequency of the monitoring thread and save computing resources. On the contrary, if the maximum transmission rate is low, indicating that the network may have fluctuations, a shorter polling time needs to be set to monitor the network status more frequently and adjust the upload strategy in a timely manner.

[0040] Optionally, the monitoring thread runs on the client in the form of a daemon process, responsible for periodically polling the network status and file metadata to ensure that changes in network conditions and file information can be captured in real time during the upload process. The determination of the polling time is directly related to the efficiency and resource consumption of the monitoring thread. By setting it reasonably, while ensuring the upload efficiency, unnecessary waste of computing resources can be avoided.

[0041] In summary, adopting the above solution can ensure that subsequent dynamic shard size calculation and upload process can be carried out under real-time monitoring and at an appropriate frequency, thereby improving the efficiency and stability of uploading files to the object storage service. It enables the file upload to better adapt to changes in the network environment, intelligently adjust the upload behavior, and reduce upload failures and resource waste caused by network fluctuations.

[0042] In an exemplary embodiment, the file to be uploaded is split based on the target shard size to obtain multiple data blocks, including: splitting the file to be uploaded into multiple consecutive data blocks using the target shard size; numbering each of the multiple consecutive data blocks one by one; recording the status of different data blocks based on the numbering result and a preset shard status table to obtain a target shard status table, where the preset shard status table at least includes: the number corresponding to each data block, the hash value corresponding to each data block, and the real-time status corresponding to each data block; in the case of determining that the status recording is completed, determining multiple data blocks through the data blocks with completed records and the target shard status table.

[0043] According to the optimal shard size (P) calculated in step S204, the entire file to be uploaded is evenly divided into multiple consecutive data chunks. This means that the file will be cut into parts of the same size, each part being a portion of the file, and these parts are arranged in sequence. After the division, each data chunk is uniquely numbered, usually starting from 1 and increasing sequentially. The purpose of numbering is to facilitate the management and tracking of the status of each data chunk, and in the subsequent upload process, to be able to reconstruct the file in the correct order. Then, a target shard status table is created, which is used to record the current status of each data chunk, including but not limited to: the number of the data chunk, the hash value of the data chunk (for data integrity verification), and the real-time status of the data chunk (such as pending upload, uploading, upload success, or upload failure). This status record is crucial for the resume upload function because it can help the client and the server synchronously understand which data chunks have been successfully uploaded and which still need to be retried. By establishing the above target shard status table, it is also possible to check which data chunks have been marked as "upload success", and in the case of resume upload, only select those data chunks that are still in the "pending upload" state for upload, thus avoiding duplicate transmission and resource waste.

[0044] In summary, through the above-described embodiments, it is ensured that the adaptive shard upload of the file can not only dynamically adjust the shard size according to the network status, but also support resume upload and data integrity verification through meticulous status management, improving the efficiency and reliability of the upload. By assigning numbers to each data chunk and recording its status, the upload progress can be monitored in real time. Even in the case of network interruption or other anomalies, it is possible to quickly identify which data chunks need to be retransmitted and which have been successfully uploaded, thus greatly improving the robustness of the upload process, reducing unnecessary data transmission and waiting time, and optimizing the overall upload experience.

[0045] In an exemplary embodiment, before uploading a file from a client to a server using multiple data chunks, the above method further includes: obtaining first thread information of the client, where the first thread information at least includes: the number of cores of the central processing unit on the client, the available memory on the client, the current load of the client, and the maximum number of concurrent requests of the server connected to the client; using the first thread information to calculate the target number of threads for file upload.

[0046] Optionally, before calculating the target number of threads used for file upload using the first thread information, the above method further includes: obtaining a preset thread formula for calculating threads, where the preset thread formula is: T = Min(C × (1 + N), M / m × (1 - L), QPS), T is the target number of threads, C is the number of cores of the central processing unit, N is the number of blocks corresponding to multiple data blocks, M is the available memory, m is the memory occupancy of a single thread, L is the current load, and QPS is the maximum number of concurrent requests; substituting the first thread information into the preset thread formula for calculation.

[0047] That is to say, in the file upload preparation stage, several key resource information of the client will be collected first. These information at least include: the number of CPU cores (C): The number of CPU cores reflects the computing and processing power of the client and affects the upper limit of concurrent thread execution. Available memory (M): The size of the memory resource determines how many data blocks can be processed simultaneously without affecting system performance. Current load (L): Represents the current workload of the client and is used to evaluate the remaining available resources. The maximum number of concurrent requests of the server (QPS): This is an important server parameter that limits the degree of concurrency of the client to upload data blocks to prevent server overload. Use the collected first thread information and a preset thread calculation formula to determine the most suitable target number of threads (T). This calculation formula comprehensively considers the resource limitations of the client and the server. Specifically, C × (1 + N) is the number of threads that the client can theoretically support calculated based on the relationship between the number of CPU cores and the number of data blocks. M / m × (1 - L) is the number of threads that the client can actually schedule estimated according to the available memory, the memory occupancy of a single thread, and the resource situation after deducting the current load. QPS directly limits the number of shards that the client can upload simultaneously using the maximum number of concurrent requests of the server. By taking the minimum value of these three expressions, it is ensured that the calculated target number of threads will neither exceed the computing and memory capabilities of the client nor exceed the concurrent request upper limit of the server, thus finding a balance between upload efficiency and resource management.

[0048] In summary, through the above process, the optimal target number of threads can be intelligently calculated according to the actual resource situation of the client and the concurrent request capabilities of the server, further optimizing the efficiency and stability of file upload to the object storage service.

[0049] In an exemplary embodiment, after using multiple data blocks to upload a file from the client to the server, the above method further includes: when multi-threaded upload is enabled between the client and the server, configuring an independent data block to be uploaded for each thread; generating a request message header according to the recorded data corresponding to an independent data block in the target shard status table; and updating the recorded data in the target shard status table in real time through the upload result of the request message header.

[0050] It is understandable that after the target number of threads (T) is determined, the client will start the corresponding number of threads, and each thread is responsible for independently uploading a data block to the server. This parallel upload method can make full use of the multi-core CPU and network bandwidth of the client, significantly improving the overall upload speed of the file. Especially when dealing with large files, the effect is more obvious. The independent upload of data blocks also reduces the impact of the failure of a certain shard upload on the overall upload progress, enhancing the robustness of the upload operation. Before each thread uploads a data block, a specific request message header will be generated. This request message header contains key information of the data block in the target shard status table, such as: file identifier with unique identifier attribute (such as FileID), data block number, hash value of the data block, and possible other metadata, such as file type, size, etc. The generation of the request message header is to provide the server with sufficient information during upload, enabling the server to perform verification and storage operations based on this information. For example, the server can locate the correct object storage space through the file ID, verify the integrity of the data through the hash value of the data block, and ensure the correct sorting of data blocks and avoid duplicate uploads through the data block number. When the data block is uploaded to the server, the server will return a response indicating the upload result, usually including a status code of success or failure. After receiving this response, the client will immediately update the status record of the corresponding data block in the target shard status table. If the upload is successful, the upload status of this data block in the status table will be marked as "completed", and the successful upload time and possible other information will be recorded. If the upload fails, the status table will keep this data block in the "to be uploaded" state, providing a basis for subsequent retries or fault handling. This real-time update mechanism ensures the synchronization and consistency of the upload progress between the client and the server. Especially in the context of resume from breakpoint, the target shard status table becomes the key basis for judging which data blocks need to be retransmitted, thus avoiding unnecessary duplicate uploads, saving network resources and time, and improving the overall efficiency and user experience of the upload.

[0051] In summary, through multi-threaded concurrent upload of data blocks, generating request message headers according to the status table, and real-time updating the upload results, an efficient, stable and intelligent process of uploading files to the object storage service is achieved. Under the conditions of dealing with large amounts of data or complex network conditions, it can ensure that the file reaches the storage destination completely and accurately, while maximizing the utilization of resources of the client and the server.

[0052] In an exemplary embodiment, after uploading a file from a client to a server using multiple data blocks, the method further includes: obtaining a file upload result; parsing the file upload result to determine the block numbers and block hash values corresponding to the data blocks for which the upload has been completed; looking up the pre-upload hash value corresponding to the block number in a target shard status table; comparing the pre-upload hash value with the block hash value to determine whether to continue storing the data blocks for which the upload has been completed on the server.

[0053] Optionally, after each data block is uploaded, the client receives an upload result from the server. This result usually contains the status information of the data block upload, such as whether it is successful, the reason for the error, etc. After receiving the upload result, the client parses this result to determine which data blocks have been successfully uploaded. This includes identifying the numbers of the successfully uploaded data blocks (i.e., Chunk numbers) and calculating or recording the hash values of these data blocks. The hash value is used to verify the integrity and consistency of the data blocks. The client saves a target shard status table locally, which records the pre-upload hash values (pre-upload hash values) of each data block. When a data block is successfully uploaded, the client looks up the record of this data block in the status table to obtain the pre-upload hash value for comparison. If the two are the same, it means that the data block has not been damaged or changed during transmission. At this time, the client will confirm that the server can continue to store this data block. If the two are inconsistent, this may be due to a transmission error, data tampering, or a problem during server storage. The client will mark this data block as needing to be retransmitted to ensure the integrity and accuracy of the data.

[0054] In summary, after the data block is uploaded, by obtaining the upload result, parsing and determining the hash value and number of the uploaded data block, and comparing with the pre-upload hash value, the integrity verification and consistency guarantee of the data blocks for which the upload has been completed are achieved. Ensure that the data upload in the object storage service is not only efficient but also reliable.

[0055] In an exemplary embodiment, comparing the pre-upload hash value with the block hash value to determine whether to continue storing the data blocks for which the upload has been completed on the server includes: in the case where the similarity between the pre-upload hash value and the block hash value is less than a preset similarity, determining that the data block corresponding to the block number is an abnormally uploaded data block, and prohibiting the data block content from being written into the storage system of the server; in the case where the similarity between the pre-upload hash value and the block hash value is greater than or equal to the preset similarity, determining that the data block corresponding to the block number is a normally uploaded data block, and allowing the data block content to be written into the storage system of the server.

[0056] Briefly speaking, before and after the data block is uploaded to the server, two hash values are calculated respectively, namely the pre-upload hash value and the post-upload block hash value. These two hash values are used to verify the integrity and consistency of the data block during transmission. The pre-upload hash value is calculated before the data block leaves the client, while the block hash value is returned to the client after the server receives the data block and stores it. By comparing these two hash values, it is possible to effectively detect whether the data block has been modified or damaged during transmission. The preset similarity is a pre-set comparison criterion used to determine whether two hash values are similar enough to consider that there is no error or change in the upload of the data block. This threshold is usually 100% match because the design principle of hash values is to ensure the uniqueness and immutability of data blocks. However, in some cases, a very small difference may be considered to account for possible calculation errors or characteristics of the hash algorithm. If the similarity between the pre-upload hash value and the block hash value is lower than the preset threshold (usually a non-match situation), it is considered that there is an abnormality in the upload of the data block. This may be due to network errors during transmission, data block tampering, or failures during the server storage process. In this case, the client will prevent the server from writing the content of this data block into the storage system to prevent potential data inconsistency or errors. On the contrary, if the pre-upload hash value and the block hash value are exactly the same or the similarity is higher than the preset threshold, the client considers that the upload of the data block is normal and the data block maintains integrity and consistency during transmission. At this time, the client will instruct the server to safely write the content of this data block into the storage system and become part of the file.

[0057] In summary, through the above embodiments, it is possible to automatically detect and correct data block errors during upload, avoid the storage of inconsistent data, and improve the reliability of data and the data quality of the server storage system.

[0058] In an exemplary embodiment, after comparing the pre-upload hash value and the block hash value to determine whether to continuously store the data block that has completed upload on the server, the method further includes: generating a global shard status table corresponding to the storage system on the server, where the global shard status table at least includes: the file identifier corresponding to the to-be-uploaded file that has been stored, the block number corresponding to the stored data block, the block hash value corresponding to the stored data block, the upload timestamp corresponding to the stored data block, and the upload status corresponding to the stored data block; determining the final upload result of the to-be-uploaded file between the client and the server according to the global shard status table.

[0059] Optionally, after receiving the data blocks uploaded by the client, the server will generate a global shard status table to record and manage the progress and status of file upload. This status table at least includes: File identifier (such as FileID): used to uniquely identify the file that the client attempts to upload. Block number: The number of each data block in the file, used to track and manage specific data blocks. Block hash value: The hash value of the uploaded data block, used to verify the integrity and consistency of the data block. Upload timestamp: Records the time point when the data block is uploaded to the server, used for time management of file upload. Upload status: Marks whether the upload of the data block is successful, failed, or in progress. At the end of the upload process, the client and the server will determine the final upload result of the file based on the global shard status table maintained by the server. The specific operations include: checking the upload status of each data block in the status table to confirm whether all data blocks have been uploaded successfully. Verifying the integrity and consistency of the data block according to the hash value and timestamp recorded in the status table, and confirming the upload order and time. If the upload status of all data blocks shows success and the hash value verification passes, the client and the server can confirm that the file upload is complete. This result confirmation process is achieved by the client sending a query request to the server, and the server will return the status of all data blocks related to the file identifier (FileID) in the global shard status table. By parsing this returned information, the client can determine whether the file has been completely and correctly uploaded to the server's storage system.

[0060] In summary, by maintaining the global shard status table and determining the final upload result according to its content, the transparency, reliability, and traceability of the upload process are ensured. Furthermore, efficient status synchronization between the client and the server is performed when processing large file uploads, facilitating error troubleshooting and log auditing.

[0061] In an exemplary embodiment, after determining the block numbers and block hash values corresponding to the data blocks that have been uploaded, the above method further includes: verifying the multiple block numbers to be uploaded received by the server; when the number value of each block number in the multiple block numbers to be uploaded meets the range of the total number of shards corresponding to the file to be uploaded, determining whether the multiple block numbers to be uploaded exist in the target shard status table; when the multiple block numbers to be uploaded all exist in the target shard status table, determining that the data blocks corresponding to the block numbers to be uploaded are duplicate upload data; when at least one of the multiple block numbers to be uploaded does not exist in the target shard status table, determining the data blocks corresponding to at least one of the block numbers to be uploaded as data that needs to be uploaded.

[0062] Optionally, when the server receives one or more data blocks from the client, it first needs to verify the numbers of these data blocks, that is, the "number values of the block numbers". This verification is mainly to ensure that the number values of the data blocks fall within the total number of shards corresponding to the file. That is, the number of each data block should be a legal value, which should be greater than or equal to 1 and less than or equal to the total number of shards N of the file. To ensure the correctness of the data block numbers and avoid chaos caused by incorrect numbers, such as erroneously uploading shards that do not belong to the file or the shard numbers uploaded exceeding the actual file shard range. Next, the server will check whether the block numbers to be uploaded have been recorded in the target shard status table to determine whether the data blocks to be uploaded are for the first upload or a repeated upload attempt. Among them, the target shard status table is a database table that stores key information related to file uploads, including the unique identifier of the file, the number of each data block, the corresponding hash value, and the upload status, etc.

[0063] If all the block numbers to be uploaded have appeared in the target shard status table and the status indicates that they have been successfully uploaded, then the server can determine that these data blocks are repeated uploads. This means that the client is attempting to upload again the data blocks that have been confirmed by the server as successfully uploaded, which may be due to incorrect client configuration, repeated sending of instructions caused by network problems, or additional verification for ensuring data consistency. In this case, the server does not need to store the same data blocks again, but can directly inform the client that these data blocks have been successfully uploaded, avoiding unnecessary resource consumption. On the contrary, if one or more of the block numbers to be uploaded do not appear in the target shard status table, or are marked as upload failed in the status table, then the server will regard the data blocks corresponding to these block numbers as the data to be uploaded. This indicates that the client is attempting to upload new or unsuccessfully uploaded data blocks, and the server should receive and store these data blocks to complete the file upload process.

[0064] In summary, through the above implementation methods, the server can intelligently determine whether the received data blocks need to be stored, avoiding resource waste caused by repeated uploads, and at the same time ensuring that all shards of the file can be correctly and completely stored in the object storage system, providing higher accuracy and efficiency for file upload.

[0065] In an exemplary embodiment, after using the multiple data blocks to upload a file from the client to the server and recording the upload parameters of different data blocks to determine the upload result of the file to be uploaded transferred to the server through the upload parameters, the method further includes: when the upload result indicates an upload interruption, determining the differential upload parameters of the data blocks between the server and the client; locating the untransmitted data block numbers of multiple target data blocks not uploaded to the server according to the differential upload parameters to obtain multiple untransmitted data block numbers; and invoking data blocks in the client based on the multiple untransmitted data block numbers for interruption recovery.

[0066] During the file upload process, the client and the server record the upload parameters related to each data block. These parameters may include, but are not limited to: the size of the data block, the number of the data block, the hash value of the data block, the number of concurrent threads, the start time of the upload, the end time of the upload, network condition data such as bandwidth, latency, and packet loss rate. If the upload is interrupted due to network problems, server failures, or other factors, the client will receive an upload result from the server, indicating that there are data blocks that have failed to upload or are incomplete during the upload process. This upload result may include the overall status of the current file upload and the specific upload status of which data block or data blocks is / are abnormal. After detecting the upload interruption, the client and the server will conduct a communication to exchange information about the data blocks that have been successfully uploaded and the data blocks that have not been successfully uploaded. The client will compare the expected upload parameters with the actual upload parameters feedback by the server to find the differences. The differential parameters mainly refer to the upload parameters of those data blocks that are recorded as uploaded in the client but are not received or not confirmed to be received in the server. By analyzing the differential upload parameters, the client can accurately locate which data block numbers correspond to the data blocks that have not been successfully uploaded to the server. These numbers are called "untransmitted data block numbers", which indicate the data blocks that need to be focused on and retransmitted during interruption recovery. Once the numbers of the untransmitted data blocks are determined, the client will reorganize the interruption recovery operation. The specific approach is: according to the untransmitted data block numbers, read the corresponding untransmitted data blocks from the original file. Re-upload these data blocks using the same or optimized upload parameters as the original upload until the server confirms that all data blocks have been successfully uploaded. During the re-upload process, the network status may also be continuously monitored, and the upload parameters may be adjusted according to the real-time network conditions to ensure the most efficient upload recovery.

[0067] In summary, after a file upload is interrupted, the client and the server can quickly locate which data blocks need to be retransmitted by communicating the differences in the upload parameters, rather than blindly restarting the entire upload process or retransmitting all data blocks in full. This not only reduces the waste of network bandwidth but also shortens the time required for upload recovery, greatly improving the efficiency and robustness of file uploads. Especially for large files or in an environment with unstable network conditions, the upload success rate and user experience can be significantly improved.

[0068] In an exemplary embodiment, before determining the differential upload parameters of the data blocks between the server and the client when the upload result indicates an upload interruption, the above method further includes: determining whether the upload interruption is a real situation through a preset heartbeat mechanism and / or an exception capture mechanism; and controlling the client to send a resume upload request to the server when it is determined that the upload interruption is a real situation, where the resume upload request at least includes: a file identifier corresponding to the file to be resumed; and obtaining a list of block numbers to be re-uploaded determined by the server based on the resume upload request.

[0069] Optionally, the heartbeat mechanism mainly is: the client periodically sends a heartbeat signal (usually a simple request) to the server, and the server responds to the heartbeat signal to confirm the validity of the connection. If the client does not receive a heartbeat response from the server within a preset time, this may indicate a network connection interruption or a server failure. The exception capture mechanism mainly is: when the client encounters abnormal events such as network timeouts or the server returning an error response code during the upload process, the exception capture mechanism will be activated, record the exception, and pause the upload process. Then, by combining these two mechanisms, it helps the client determine whether an upload interruption has actually occurred, rather than just a temporary network jitter or false alarm. If it is confirmed that the upload interruption is real, the client will execute the subsequent resume upload process. After the client confirms the authenticity of the upload interruption, it will construct and send a resume upload request to the server. This request at least contains the following information: the file identifier (such as FileID) information of the file to be resumed: used by the server to identify which file's upload process has been interrupted; the status information of the client, including the block numbers of the data blocks that have been successfully uploaded, the latest upload status, etc., used to assist the server in quickly locating the data blocks that need to be re-uploaded.

[0070] Optionally, when the server receives a resume upload request, it queries its global shard status table, compares the file identifier with the status of the successfully stored data blocks, and thus identifies which data blocks have not been successfully stored, i.e., which data blocks are still in the "pending upload" or "failed" upload status. The server generates a list of block numbers to be re-uploaded and returns it to the client as part of the response. This list contains the numbers of all the data blocks that need to be re-uploaded. The client can selectively re-upload the specified shards based on this list instead of re-uploading the entire file, which greatly improves the upload efficiency and saves network resources.

[0071] In summary, through the above-described embodiments, the client and the server can cooperate to handle interruptions during the upload process, avoid unnecessary full re-uploads, and support intelligent resume upload. This method is particularly suitable for handling large file uploads or environments with unstable network conditions, as it can adapt to sudden connection problems while ensuring the integrity and efficiency of file uploads.

[0072] In an exemplary embodiment, after obtaining the list of block numbers to be re-uploaded determined by the server based on the resume upload request, the above method further includes: searching for a plurality of data blocks to be re-uploaded that match the list of block numbers to be re-uploaded from the plurality of data blocks to obtain a set of re-upload data blocks; and using the set of re-upload data blocks to perform file upload between the client and the server.

[0073] It can be understood that when the client receives the list of block numbers to be re-uploaded returned by the server, it filters out those data blocks from the existing set of data blocks whose numbers match those in the list. This filtering process ensures that the client only re-uploads those data blocks that the server has clearly indicated as not being successfully received, rather than the entire file or the successfully uploaded data blocks. The purpose of this is to improve the upload efficiency, reduce waste of network resources, and avoid unnecessary data transmission. After searching and filtering, the client collects all the data blocks that need to be re-uploaded to form a dedicated set of re-upload data blocks. This set contains all the data blocks with the numbers to be uploaded, and the client will organize subsequent upload activities based on this set. Finally, the client uses this set of re-upload data blocks to perform the file upload process with the server. This upload process may involve the following steps:

[0074] Step 1: The client dynamically adjusts the upload parameters, such as the shard size and the number of concurrent threads, according to the current network conditions and resource status.

[0075] Step 2: Upload each data block in the set of re-upload data blocks concurrently, while recording the upload status and upload parameters.

[0076] Step 3: During the upload process, the client and the server continue to maintain the connection status through the heartbeat mechanism to ensure the continuity of data transmission.

[0077] Step 4: After the upload is completed, the server performs a verification of the hash value and block number to confirm the integrity and uniqueness of the data block.

[0078] Step 5: The server updates the global shard status table to record the status of the data blocks that have been successfully uploaded.

[0079] In summary, even if an interruption occurs during the upload process, the client can quickly and accurately locate which data blocks need to be re-uploaded, without having to upload the entire file from the beginning. This significantly improves the upload efficiency and success rate. Especially when dealing with large files or in the case of unstable network conditions, it can effectively reduce the amount of retransmitted data, save network resources, and improve the user upload experience. In cloud storage and distributed systems, this resume and re-upload mechanism can enhance the stability and reliability of the system.

[0080] In an exemplary embodiment, after using the re-upload data block set for file upload between the client and the server, the above method further includes: obtaining the file upload result of the re-upload data block set; in the case where the file upload result indicates successful completion of the upload of the re-upload data block set, generating a final upload message for the file to be uploaded between the client and the server, and feeding back the final upload message to the management object corresponding to the file to be uploaded; in the case where the file upload result indicates that the upload of the re-upload data block set has not been successfully completed, sending a prompt message indicating file upload failure to the management object corresponding to the file to be uploaded.

[0081] After the client finishes the upload using the re-uploaded data block set, it fetches a result feedback about this upload from the server. The upload result feedback usually includes: the upload status (success, failure, or unknown) of each data block, the hash values and block numbers of the successfully uploaded data blocks, the block numbers of the failed data blocks, and the reasons for failure; this information is used by the client to confirm whether all the re-uploaded data blocks have successfully reached the server and whether there are any upload failures. If the upload result feedback indicates that all the re-uploaded data blocks have been successfully received and confirmed by the server, it means that the file upload process has been completely completed without any missing or failed data blocks. At this time, the client generates a final confirmation message, namely the "final upload message". This message will contain the file identifier of the file (such as FileID), the completion status of the file upload, and other relevant information (such as upload time, upload strategy used, etc.). The client then feeds back this final upload message to the object or component responsible for managing the file upload process, which could be a file manager, upload task controller, or any other part that manages the file upload logic on the client. This feedback mechanism ensures the closed-loop of the file upload process, enabling the system to know that the file upload has been successfully completed. On the contrary, if the upload result feedback shows that there are still data blocks that have not been successfully uploaded, then the upload process is not fully completed. In this case, the client does not generate a final upload message but sends a file upload failure prompt message to the file management object. This prompt message will detail which data blocks have failed to upload, the reasons for failure, and possible remedial measures. For example, the client may suggest re-trying to upload the failed data blocks again, or provide an option for the user to decide whether to continue the upload. This message will also be fed back to the component responsible for managing the file upload so that the component can handle it accordingly based on the failure information, such as restarting the upload process or notifying the user of the upload status.

[0082] Among them, the execution subject of the above steps can be a server, a terminal, etc., but is not limited thereto.

[0083] To facilitate the understanding of the implementation manner of this application, relevant scenarios are now explained, but it does not limit this application.

[0084] As an optional implementation manner, an optional embodiment of this application provides an adaptive sharding upload method based on object storage. This method is mainly applied to the efficient upload scenario of large-scale files in an object storage service. And the above method can dynamically adjust the upload according to the network status and file characteristics, as well as perform intelligent concurrent control and resume interrupted transfer, improving the upload efficiency and robustness of the file upload.

[0085] Optionally, Figure 3It is a schematic diagram of the module composition of an adaptive shard upload architecture based on object storage according to an embodiment of the present application. Specifically, it includes a client and a server. The client mainly monitors through information collection, dynamically calculates the allowed shard size, and shards the client's file according to the calculation result. For example, file 1 is decomposed into N data blocks, namely {Chunk1, Chunk2,..., ChunkN}. Then, after the decomposition of file 1 is completed, through intelligent concurrent control, file 1 is converted into N shards and shard-uploaded to the server through a preset transmission protocol (such as HTTP / HTTPS). The server performs joint verification through the information corresponding to the file identifier and the data block. In the case of passing the verification, file 1 is stored in the server through a distributed object storage system, and at the same time, the storage result is fed back to the client through the network.

[0086] It can be understood that by dynamically adjusting the shard size, the optimal shard size is dynamically calculated according to the real-time network status (bandwidth, latency, packet loss rate) and file characteristics (size, type), maximizing the bandwidth utilization rate and improving the upload efficiency; through intelligent concurrent control, according to the server API limit and the client resource capacity, the concurrent thread number is dynamically adjusted to avoid resource competition; when the upload is interrupted, through a double verification mechanism, that is, simultaneously verifying the hash value at the data block level and the serial number corresponding to the file identifier corresponding to the data block, ensuring data uniqueness, only retransmitting the wrong shards, avoiding repeated transmission of successfully sharded data, preventing different files or wrong shards from overwriting the target file, and improving the overall throughput and robustness.

[0087] Optionally, Figure 4 It is a flowchart of an adaptive shard upload process based on object storage according to an embodiment of the present application. The specific implementation content is as follows.

[0088] Step S401: Collect the metadata information of the file to be uploaded at the client and initialize the upload task;

[0089] Step S402: Collect the network status and file metadata of the upload path in real time and dynamically calculate the optimal shard size;

[0090] Step S403: Split the file into multiple data blocks Chunk according to the dynamic shard size, dynamically adjust the number of threads, and concurrently upload to the object storage system;

[0091] Step S404: Synchronously maintain a shard status table at the client and the object storage server, and record the serial number and hash value of the file identifier corresponding to the uploaded data block Chunk;

[0092] Step S405: When the object storage server receives the data block Chunk, perform joint verification through the file hash value and the serial number of the data block Chunk to prevent data overwrite;

[0093] Step S406: In response to the upload interruption, the client obtains the sequence numbers of the unfinished data blocks Chunk according to the shard status table and continues the upload from the breakpoint.

[0094] As an optional embodiment, when the client collects the metadata information of the file to be uploaded and initializes the upload task, it mainly includes the following steps:

[0095] Step S42: Start a monitoring thread to monitor the network status and file characteristics in real time. The monitoring thread runs in the client in the form of a daemon process and polls at regular intervals to obtain;

[0096] Step S44: Collect file metadata, mainly including the total file size (S) and file type (T, such as text / video / compressed package);

[0097] Step S46: Initialize the upload task. The client generates a file identifier fileID for the file based on the UUID (Universally Unique Identifier) and timestamp.

[0098] As an optional embodiment, the network status of the upload path is collected in real time and the optimal shard size is calculated dynamically, mainly including the following steps:

[0099] Step S52: The client collects network status information, mainly including real-time monitoring of the upload path bandwidth (B), network latency (D), and packet loss rate (L) of the client;

[0100] Step S54: Integrate the network status and file metadata information to calculate the optimal shard size of the current file. The adaptive shard size calculation formula is: P = α × (B / R) × (1 - L / 100) × log 10 (S); where: P is the optimal shard size, α is the file type coefficient (text = 1.0, video = 1.5, compressed package = 2.0); B is the upload path bandwidth; R is the network protocol overhead coefficient (Hypertext Transfer Protocol HTTP = 1.2, Hypertext Transfer Security Protocol HTTPS = 1.5); L is the network packet loss rate; S is the file size; log 10 (S) is the file size logarithm term, which is used to ensure that the shards of large files are larger.

[0101] Step S56: Dynamically adjust the shard size. When the network status changes (e.g., the bandwidth drops by 20%), trigger the recalculation of the shard size. Example: The file size is 1GB, the bandwidth is 10Mbps, the latency is 50ms, the packet loss rate is 1%, and the file type is video, and it is transmitted using the Hypertext Transfer Protocol HTTP. Then the shard size is: P = 1.5×(10 / 1.2)×(1 - 0.01)×log10(1024) ≈ 1.5×8.33×0.99×3.01 ≈ 37.5MB.

[0102] That is to say, by collecting the network status (such as bandwidth, latency, packet loss rate) and file metadata (such as size, type) in real time, the optimal shard size is dynamically calculated, and then dynamic shard uploading is performed to improve the transmission efficiency and stability, avoiding the efficiency bottleneck of the traditional fixed shard size in a complex network environment. In addition, when the network fluctuates (such as high latency, low bandwidth), the shard size can be automatically reduced to reduce the probability of single transmission failure; when the network is good, the shard size can be increased to improve the throughput, achieving a dynamic balance between transmission efficiency and stability. This avoids the efficiency bottleneck of the traditional fixed shard size in a complex network environment.

[0103] As an optional embodiment, the file is divided into multiple data blocks Chunk according to the dynamic shard size, the number of threads is dynamically adjusted, and they are concurrently uploaded to the object storage system, which mainly includes the following steps:

[0104] Step S602: Calculate the number of shards N according to the optimal shard size, divide the file into N consecutive data blocks Chunk, and number the data blocks Chunk, and the number range is [1…N].

[0105] Step S604: The client initializes the shard status table, records the serial numbers of all shard data blocks Chunk, the hash values of the data blocks Chunk, and the status (to be uploaded / uploaded / failed);

[0106] Step S606: Obtain the number of client CPU cores (C), available memory (M), current load (L), and the maximum concurrent request number QPS of the object storage server through the monitoring thread;

[0107] Step S608: Piecewise uploading is an I / O intensive task. By integrating strategies such as QPS constraint, piecewise merging, and memory optimization, and combining parameters such as the number of CPU cores, the number of pieces, memory, and load, the thread number calculation formula is derived as: T = Min(C×(1 + N), M / m×(1 - L), QPS), where T is the current optimal number of threads (equivalent to the target number of threads in the above embodiments), C is the number of cores of the central processing unit, such as 4 cores, N is the number of pieces, such as 100 file pieces (equivalent to the number of blocks corresponding to multiple data blocks in the above embodiments), M is the available memory (in GB, such as 16GB), m is the memory occupied by a single thread, in GB, such as 0.1GB / thread (equivalent to the memory occupied by a single thread in the above embodiments), L is the current load (value range [0, 1]), and QPS is the maximum concurrent request number of the object storage server (such as 1000req / s).

[0108] Step S610: Start multi-threaded uploading. Each thread independently uploads a data block Chunk, and the request header carries the file identifier FileID, the sequence number of the data block Chunk, and the hash value of the data block Chunk. After receiving it, the server stores the data of the data block Chunk and returns the upload result (success / failure).

[0109] It should be noted that through intelligent dynamic thread scheduling: dynamically adjust the number of threads according to the number of pieces, and concurrently upload multiple data blocks Chunk, making full use of system resources (such as CPU and memory) and network bandwidth. In the scenario of large file uploading, it avoids resource contention or waste caused by traditional fixed concurrent thread numbers and improves the overall uploading speed.

[0110] As an optional embodiment, a piece status table is synchronously maintained on the client side and the object storage server side, recording the sequence number and hash value of the uploaded data block Chunk, which mainly includes the following steps:

[0111] Step S702: Client piece status table update: The client updates the local piece status table according to the upload result returned by the server, marks the successfully uploaded data block Chunk as the "uploaded" status, and records its hash value;

[0112] Step S704: Server piece status table synchronization: The server stores the global piece status table, which includes the file identifier FileID, the sequence number of the data block Chunk, the hash value of the data block Chunk, the upload timestamp, and the upload status.

[0113] As an optional embodiment, when the object storage server receives the data block Chunk, it performs joint verification through the file hash value and the sequence number of the data block Chunk to prevent data overwrite, which mainly includes the following steps:

[0114] Step S706: When the server receives the data block Chunk request uploaded by the client, it extracts the file identifier FileID, the hash value of the data block Chunk and the data block Chunk sequence number in the request header, and verifies whether the hash value in the request is consistent with the file hash recorded in the shard status table. If they are consistent, the data block Chunk is written into the object storage system and the uploaded set in the shard status table is updated; if they are inconsistent, it is determined to be an illegal request, and the server refuses to receive the data block Chunk and returns an error code.

[0115] Step S708, the server verifies the validity of the data block Chunk number, and checks whether the data block Chunk number is in the range of the total number of shards of the current file (that is, the data block Chunk number must be greater than or equal to 1 and less than or equal to N). If the sequence number of the current data block Chunk already exists in the uploaded set of the shard status table, it is determined to be a duplicate upload, and the server directly skips the storage operation of the data block Chunk and returns a success status.

[0116] Step S710: The server stores the upload status of the data block Chunk (including the file identifier FileID, the hash value of the data block Chunk, and the data block Chunk sequence number) persistently in the shard status table to ensure that the upload progress can be quickly restored when the upload is resumed.

[0117] As an optional embodiment, in response to the interruption of uploading, the client obtains the sequence number of the unfinished data block Chunk according to the fragmentation status table and continues uploading from the breakpoint, which mainly includes the following steps:

[0118] Step S712: The client determines whether the upload is interrupted through a heartbeat mechanism (such as detecting thread activity every 5 seconds) or exception capture (such as network timeout, server error).

[0119] Step S714: The client sends a resume request to the server with the file identifier FileID. The server queries the fragment status table according to the file identifier FileID and returns only the Chunk sequence number list of the fragment data blocks that have not been uploaded.

[0120] Step S716: The client reads the list of sequence numbers of the sharded data blocks that have not been uploaded, uploads the incomplete data blocks, and skips the successfully uploaded data blocks.

[0121] It should be noted that by synchronously maintaining the shard status table between the client and the server, recording the sequence number and hash value of each uploaded data block Chunk, refined shard status management is realized. After the upload is interrupted (such as network fluctuations or abnormal exit of the client), the client can accurately locate the incomplete data block Chunk, and only needs to retransmit the missing part, avoiding the resource waste of "whole segment retransmission" or "manual breakpoint positioning" in the traditional scheme, and improving the file transmission efficiency. At the same time, the server jointly verifies through the file hash and shard sequence number to ensure the uniqueness of the uploaded data block Chunk, preventing data overwrite problems caused by network jitter or repeated uploads by the client, and ensuring the data accuracy of the object storage system.

[0122] In summary, the above-described embodiment solutions can effectively improve the file upload efficiency and stability of the object storage system. Compared with the existing solutions, through the dynamic shard upload mechanism, adaptively calculate the shard size, intelligently control the number of concurrent threads, resume broken-point transmission, and jointly verify to prevent data overwrite, so as to improve the upload efficiency and robustness of the object storage system.

[0123] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. The computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions for causing a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in various embodiments of the present application.

[0124] In this embodiment, a file upload system is also provided. This system is used to implement the above embodiments and preferred implementation manners, and those that have been described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0125] Figure 5 is a structural block diagram of a file upload device according to an embodiment of the present application. As Figure 5 shown, the system includes:

[0126] An acquisition module 52, configured to collect metadata of the file to be uploaded in real time and the network status of the upload path between the client and the server;

[0127] A calculation module 54, configured to calculate a target shard size for data upload of the file to be uploaded between the client and the server based on the metadata and the network status;

[0128] A splitting module 56, configured to split the file to be uploaded based on the target shard size to obtain a plurality of data blocks;

[0129] An upload module 58, configured to upload a file from the client to the server using the plurality of data blocks, and record upload parameters of different data blocks, so as to determine an upload result of the file to be uploaded transmitted to the server based on the upload parameters.

[0130] With the above device, before and during the upload, basic information (metadata) about the file to be uploaded and the network status between the client and the server are continuously collected. This includes the file size, type, and real-time network bandwidth, latency, and packet loss rate, etc. Before and during the upload, basic information (metadata) about the file to be uploaded and the network status between the client and the server are continuously collected. This includes the file size, type, and real-time network bandwidth, latency, and packet loss rate, etc. According to the file metadata and network status collected in real time, the shard size most suitable for the current upload conditions is calculated, and the large file to be uploaded is split into several smaller data blocks according to the calculated target shard size. These data blocks are used for concurrent upload, that is, multiple data blocks can be transmitted to the server simultaneously, thereby accelerating the upload process. Then, according to the metadata and network status of the file to be uploaded on the client and the server collected in real time, the target shard size is dynamically calculated, the file is split and uploaded according to the target shard size, and the upload parameters are recorded to determine the upload result. Through the above method, the technical problems of poor upload efficiency and robustness of the object storage system are solved.

[0131] In an exemplary embodiment, the above acquisition module is further configured to determine file parameters of the file to be uploaded according to the metadata, where the file parameters at least include: the total file size of the file to be uploaded, the file type of the file to be uploaded; determine network parameters for file transmission between the client and the server according to the network status, where the network parameters at least include: the upload path bandwidth between the client and the server, the network latency between the client and the server, the packet loss rate between the client and the server; input the file parameters and the network parameters into a preset adaptive shard calculation formula to obtain a target shard size for data upload between the client and the server. The preset adaptive shard calculation formula is: P = α×(B / R)×(1 - L / 100)×log 10 (S), where P is the target shard size, α is the file type coefficient, B is the upload path bandwidth, R is the network protocol overhead coefficient, L is the packet loss rate, S is the total file size, log10 (S) is the logarithmic term of the file size.

[0132] In an exemplary embodiment, the above-mentioned device further includes: a monitoring module, configured to collect metadata of the file to be uploaded in real time and obtain the maximum transmission rate between the client and the server before the network status of the upload path between the client and the server; determine the polling time for real-time collection according to the maximum transmission rate, and set a monitoring thread based on the polling time.

[0133] In an exemplary embodiment, the above-mentioned splitting module is further configured to split the file to be uploaded into multiple consecutive data blocks using the target shard size; number each of the multiple consecutive data blocks one by one; record the status of different data blocks based on the numbering result and a preset shard status table to obtain a target shard status table, where the preset shard status table at least includes: the number corresponding to each data block, the hash value corresponding to each data block, and the real-time status corresponding to each data block; in the case of determining that the status recording is completed, determine multiple data blocks through the data blocks with completed records and the target shard status table.

[0134] In an exemplary embodiment, the above-mentioned device further includes: an obtaining module, configured to obtain the first thread information of the client before uploading the file from the client to the server using multiple data blocks, where the first thread information at least includes: the number of cores of the central processing unit on the client, the available memory on the client, the current load of the client, and the maximum number of concurrent requests of the server connected to the client; calculate the target number of threads used for file upload using the first thread information.

[0135] In an exemplary embodiment, the above-mentioned device further includes: an updating module, configured to, after uploading the file from the client to the server using multiple data blocks, in the case of enabling multi-threaded upload between the client and the server, configure an independent uploaded data block for each thread; generate a request message header according to the recorded data corresponding to an independent uploaded data block in the target shard status table; and update the recorded data in the target shard status table in real time through the upload result of the request message header.

[0136] In an exemplary embodiment, the above-mentioned device further includes: a determining module, configured to obtain the file upload result after uploading the file from the client to the server using multiple data blocks; parse the file upload result to determine the block number and block hash value corresponding to the data block that has been uploaded; find the pre-upload hash value corresponding to the block number in the target shard status table; compare the pre-upload hash value with the block hash value to determine whether to continuously store the data block that has been uploaded on the server.

[0137] In an exemplary embodiment, the above-mentioned determination module is further configured to, when the similarity between the pre-upload hash value and the block hash value is less than a preset similarity, determine the data block corresponding to the block number as abnormally uploaded data and prohibit the content of the data block from being written into the storage system of the server; when the similarity between the pre-upload hash value and the block hash value is greater than or equal to the preset similarity, determine the data block corresponding to the block number as normally uploaded data and allow the content of the data block to be written into the storage system of the server.

[0138] In an exemplary embodiment, the above-mentioned determination module further includes: a first determination unit, configured to compare the pre-upload hash value and the block hash value to determine whether, after continuously storing the uploaded data blocks on the server, a global sharding status table corresponding to the storage system on the server is generated, where the global sharding status table at least includes: the file identifier corresponding to the to-be-uploaded file that has been stored, the block number corresponding to the stored data block, the block hash value corresponding to the stored data block, the upload timestamp corresponding to the stored data block, and the upload status corresponding to the stored data block; and determine the final upload result of the to-be-uploaded file between the client and the server according to the global sharding status table.

[0139] In an exemplary embodiment, the above-mentioned determination module further includes: a second determination unit, configured to, after determining the block number and the block hash value corresponding to the uploaded data block, verify a plurality of to-be-uploaded block numbers received by the server; when the number value of each block number in the plurality of to-be-uploaded block numbers conforms to the range of the total number of shards corresponding to the to-be-uploaded file, determine whether the plurality of to-be-uploaded block numbers exist in the target sharding status table; when the plurality of to-be-uploaded block numbers all exist in the target sharding status table, determine the data block corresponding to the to-be-uploaded block number as duplicate uploaded data; when at least one of the plurality of to-be-uploaded block numbers does not exist in the target sharding status table, determine the data block corresponding to at least one to-be-uploaded block number as data to be uploaded.

[0140] In an exemplary embodiment, the above-mentioned Zhuang Hai further includes: a recovery module, configured to, after uploading a file from the client to the server using the plurality of data blocks and recording the upload parameters of different data blocks to determine the upload result of the to-be-uploaded file transmitted to the server through the upload parameters, when the upload result indicates an upload interruption, determine the differential upload parameters of the data blocks between the server and the client; locate the untransmitted data block numbers of a plurality of target data blocks that have not been uploaded to the server according to the differential upload parameters to obtain a plurality of untransmitted data block numbers; and call data blocks in the client based on the plurality of untransmitted data block numbers for interruption recovery.

[0141] In an exemplary embodiment, the above recovery module further includes: a third determination unit, configured to, when the upload result indicates an upload interruption, before determining the differential upload parameter of data blocks between the server and the client, determine whether the upload interruption is a real situation through a preset heartbeat mechanism and / or an exception capture mechanism; and when determining that the upload interruption is a real situation, control the client to send a resume upload request to the server, where the resume upload request at least includes: a file identifier corresponding to the file to be resumed; and obtain a list of block numbers to be re-uploaded determined by the server based on the resume upload request.

[0142] In an exemplary embodiment, the above recovery module further includes: an upload unit, configured to, after obtaining a list of block numbers to be re-uploaded determined by the server based on the resume upload request, find a plurality of re-upload data blocks that match the list of block numbers to be re-uploaded from a plurality of data blocks, to obtain a re-upload data block set; and use the re-upload data block set to perform file upload between the client and the server.

[0143] In an exemplary embodiment, the above recovery module further includes: a message unit, configured to, after using the re-upload data block set to perform file upload between the client and the server, obtain a file upload result of the re-upload data block set; when the file upload result indicates that the upload of the re-upload data block set is successfully completed, generate a final upload message of the file to be uploaded between the client and the server, and feedback the final upload message to a management object corresponding to the file to be uploaded; and when the file upload result indicates that the upload of the re-upload data block set is not successfully completed, send a prompt message indicating file upload failure to the management object corresponding to the file to be uploaded.

[0144] It should be noted that the above-mentioned various modules can be implemented by software or hardware. For the latter, it can be implemented in the following ways, but not limited to: the above-mentioned modules are all located in the same target processor; or, the above-mentioned various modules are respectively located in different target processors in any combination form.

[0145] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, where the computer program is configured to execute the steps in any one of the above method embodiments when running.

[0146] In an exemplary embodiment, the above computer-readable storage medium may include, but is not limited to: various media such as a USB flash drive, a read-only memory, a random access memory, a mobile hard disk, a magnetic disk, or an optical disc that can store a computer program.

[0147] Embodiments of the present application also provide an electronic device, including a target memory and a target processor. A computer program is stored in the target memory, and the target processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0148] Optionally, Figure 6 is a block diagram of the computer system structure of the electronic device according to an embodiment of the present application. As Figure 6 shown, the computer system 800 includes a CPU 801 (Central Processing Unit, central processor, abbreviated as CPU), which can execute various appropriate actions and processes according to the program stored in the ROM 802 (Read-Only Memory, abbreviated as ROM) or the program loaded from the storage section 808 into the RAM 803 (Random Access Memory, abbreviated as RAM). In the RAM 803, various programs and data required for system operations are also stored. The CPU 801, ROM 802, and RAM 803 are connected to each other via a bus 804. The I / O interface 805 (Input / Output interface, input / output interface, i.e., I / O interface) is also connected to the bus 804.

[0149] The following components are connected to the I / O interface 805: an input section 806 including a keyboard, a mouse, etc.; an output section 807 including, for example, a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a local area network card, a modem, etc. The communication section 809 performs communication processing via a network such as the Internet. The drive 810 is also connected to the input / output interface 805 as needed. A removable medium 811, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 810 as needed, so that the computer program read from it can be installed into the storage section 808 as needed.

[0150] In an exemplary embodiment, the above electronic device may further include a transmission device and an input / output device, where the transmission device is connected to the above central processor (CPU 801), and the input / output device is connected to the above central processor (CPU 801).

[0151] Embodiments of the present application also provide a computer program product. The computer program product includes a computer program, and when the computer program is executed by a processor, it implements the steps in any one of the above method embodiments.

[0152] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium storing a computer program, and when the computer program is executed by a processor, the steps in any one of the above method embodiments are implemented.

[0153] An embodiment of the present application further provides a computer program, which includes computer instructions stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the steps in any one of the above method embodiments.

[0154] Specific examples in this embodiment may refer to the examples described in the above embodiments and exemplary embodiments, and will not be elaborated herein.

[0155] Those skilled in the art can further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

[0156] Obviously, those skilled in the art should understand that the above modules or steps of the present application can be implemented by a general-purpose computing device. They can be concentrated on a single computing device or distributed on a network composed of multiple computing devices. They can be implemented by program codes executable by the computing device, so that they can be stored in a storage device and executed by the computing device. And in some cases, the steps shown or described can be executed in a different order than here, or they can be separately made into individual integrated circuit modules, or multiple modules or steps among them can be made into a single integrated circuit module to implement. Thus, the present application is not limited to any specific combination of hardware and software.

[0157] The above has introduced in detail an upload system, method, medium, electronic device and program product of a file provided by the present application. Specific examples are used in this article to elaborate on the principle and implementation manner of the present application. The description of the above embodiments is only used to help understand the method and its core idea of the present application. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the protection scope of the claims of the present application.

Claims

1. A method for uploading a file, characterized in that, Including: Real-time collect the metadata of the file to be uploaded and the network status of the upload path between the client and the server; Calculate the target shard size for data upload of the file to be uploaded between the client and the server based on the metadata and the network status; Perform splitting processing on the file to be uploaded based on the target shard size to obtain multiple data blocks; Use the multiple data blocks to upload the file from the client to the server, and record the upload parameters of different data blocks to determine the upload result of the file to be uploaded transmitted to the server through the upload parameters.

2. The file uploading method according to claim 1, wherein Calculating the target shard size for data upload of the file to be uploaded between the client and the server based on the metadata and the network status includes: Determine the file parameters of the file to be uploaded according to the metadata, where the file parameters at least include: the total file size of the file to be uploaded, the file type of the file to be uploaded; Determine the network parameters for file transmission between the client and the server according to the network status, where the network parameters at least include: the upload path bandwidth between the client and the server, the network latency between the client and the server, the packet loss rate between the client and the server; Input the file parameters and the network parameters into a preset adaptive sharding calculation formula to obtain the target shard size for data upload between the client and the server.

3. The method for uploading a file according to claim 2, wherein The preset adaptive sharding calculation formula is: P = α × (B / R) × (1 - L / 100) × log 10 (S), where P is the target shard size, α is the file type coefficient, B is the upload path bandwidth, R is the network protocol overhead coefficient, L is the packet loss rate, S is the total file size, and log 10 (S) is the file size logarithmic term.

4. The method for uploading a file according to claim 1, wherein Before real-time collecting the metadata of the file to be uploaded and the network status of the upload path between the client and the server, the method further includes: Obtain the maximum transmission rate between the client and the server; Determine the polling time for real-time collection according to the maximum transmission rate, and set a monitoring thread based on the polling time.

5. The method for uploading a file according to claim 1, characterized in that, Performing splitting processing on the file to be uploaded based on the target shard size to obtain multiple data blocks includes: Use the target shard size to split the file to be uploaded into multiple consecutive data blocks; Number each of the multiple consecutive data blocks one by one; Record the status of different data blocks based on the numbering result and a preset shard status table to obtain a target shard status table, where the preset shard status table at least includes: the number corresponding to each data block, the hash value corresponding to each data block, the real-time status corresponding to each data block; In the case of determining that the status recording is completed, determine the multiple data blocks through the data blocks with completed recording and the target shard status table.

6. The method for uploading a file according to claim 1, wherein Before using the multiple data blocks to upload the file from the client to the server, the method further includes: Obtain the first thread information of the client, where the first thread information at least includes: the number of cores of the central processing unit on the client, the available memory on the client, the current load of the client, the maximum number of concurrent requests of the server connected to the client; Calculate the target number of threads for file upload using the first thread information.

7. The method for uploading a file according to claim 6, wherein Before calculating the target number of threads used for file upload using the first thread information, the method further includes: Obtain a preset thread formula for calculating threads, where the preset thread formula is: T = Min(C×(1 + N), M / m×(1 - L), QPS), where T is the target number of threads, C is the number of cores of the central processing unit, N is the number of blocks corresponding to multiple data blocks, M is the available memory, m is the memory occupancy of a single thread, L is the current load, and QPS is the maximum number of concurrent requests; Substitute the first thread information into the preset thread formula for calculation.

8. The method for uploading a file according to claim 1, wherein After uploading a file from the client to the server using the multiple data blocks, the method further includes: When enabling multi-threaded upload between the client and the server, configure an independent upload data block for each thread; Generate a request message header according to the record data corresponding to the independent upload data block in the target shard status table; Real-time update the record data in the target shard status table through the upload result of the request message header.

9. The method for uploading a file according to claim 1, wherein After uploading a file from the client to the server using the multiple data blocks, the method further includes: Obtain the file upload result; Parse the file upload result to determine the block number and block hash value corresponding to the data block that has been uploaded; Find the pre-upload hash value corresponding to the block number in the target shard status table; Compare the pre-upload hash value with the block hash value to determine whether to continuously store the data block that has been uploaded on the server.

10. The method for uploading a file according to claim 9, wherein Comparing the pre-upload hash value with the block hash value to determine whether to continuously store the data block that has been uploaded on the server includes: In the case where the similarity between the pre-upload hash value and the block hash value is less than the preset similarity, determine that the data block corresponding to the block number is an abnormally uploaded data block, and prohibit writing the content of the data block into the storage system of the server; In the case where the similarity between the pre-upload hash value and the block hash value is greater than or equal to the preset similarity, determine that the data block corresponding to the block number is a normally uploaded data block, and allow writing the content of the data block into the storage system of the server.

11. The method for uploading a file according to claim 9, characterized in that, After comparing the pre-upload hash value with the block hash value to determine whether to continuously store the data block that has been uploaded on the server, the method further includes: Generate a global shard status table corresponding to the storage system on the server, where the global shard status table at least includes: file identifiers corresponding to the to-be-uploaded files that have been stored, block numbers corresponding to the stored data blocks, block hash values corresponding to the stored data blocks, upload timestamps corresponding to the stored data blocks, and upload statuses corresponding to the stored data blocks; Determine the final upload result of the to-be-uploaded file between the client and the server according to the global shard status table.

12. The method for uploading a file according to claim 9, wherein After determining the block number and block hash value corresponding to the data block that has been uploaded, the method further includes: Verify the multiple to-be-uploaded block numbers received by the server; When the number value of each block number among the multiple block numbers to be uploaded conforms to the range of the total number of shards corresponding to the file to be uploaded, determine whether the multiple block numbers to be uploaded exist in the target shard status table; When the multiple block numbers to be uploaded all exist in the target shard status table, determine that the data blocks corresponding to the block numbers to be uploaded are duplicate uploaded data; When at least one of the multiple block numbers to be uploaded does not exist in the target shard status table, determine the data blocks corresponding to the at least one block number to be uploaded as data to be uploaded.

13. The method for uploading a file according to claim 1, characterized in that, After using the multiple data blocks to upload a file from the client to the server and recording the upload parameters of different data blocks to determine the upload result of the file to be uploaded transferred to the server through the upload parameters, the method further includes: When the upload result indicates an upload interruption, determine the differential upload parameters of the data blocks between the server and the client; According to the differential upload parameters, locate the untransmitted block numbers of multiple target data blocks that have not been uploaded to the server to obtain multiple untransmitted block numbers; Based on the multiple untransmitted block numbers, call data blocks in the client for interruption recovery.

14. The method for uploading a file according to claim 13, wherein Before determining the differential upload parameters of the data blocks between the server and the client when the upload result indicates an upload interruption, the method further includes: Determine whether the upload interruption is a real situation through a preset heartbeat mechanism and / or an exception capture mechanism; When it is determined that the upload interruption is a real situation, control the client to send a resume upload request to the server, where the resume upload request at least includes: the file identifier corresponding to the file to be resumed; Obtain the list of block numbers to be re-uploaded determined by the server based on the resume upload request.

15. The method for uploading a file according to claim 14, characterized in that, After obtaining the list of block numbers to be re-uploaded determined by the server based on the resume upload request, the method further includes: Search for multiple re-upload data blocks that match the list of block numbers to be re-uploaded from the multiple data blocks to obtain a re-upload data block set; Use the re-upload data block set to perform file upload between the client and the server.

16. The method for uploading a file according to claim 15, wherein After using the re-upload data block set to perform file upload between the client and the server, the method further includes: Obtain the file upload result of the re-upload data block set; When the file upload result indicates that the upload of the re-upload data block set is successfully completed, generate a final upload message of the file to be uploaded between the client and the server, and feedback the final upload message to the management object corresponding to the file to be uploaded; When the file upload result indicates that the upload of the re-upload data block set is not successfully completed, send a prompt message of file upload failure to the management object corresponding to the file to be uploaded.

17. An upload device for a file, characterized in that, including: An acquisition module for real-time acquisition of the metadata of the file to be uploaded and the network status of the upload path between the client and the server; A calculation module, configured to calculate a target shard size for data upload of the file to be uploaded between the client and the server according to the metadata and the network status; A splitting module, configured to split the file to be uploaded based on the target shard size to obtain a plurality of data blocks; An upload module, configured to upload the file from the client to the server using the plurality of data blocks, and record upload parameters of different data blocks, so as to determine an upload result of the file to be uploaded transmitted to the server according to the upload parameters.

18. An electronic device, characterized in that, Comprising: A memory, configured to store a computer program; A processor, configured to implement the steps of the file upload method according to any one of claims 1 to 16 when executing the computer program.

19. A computer-readable storage medium, characterized in that, A computer program is stored in the computer-readable storage medium, wherein the computer program implements the steps of the file upload method according to any one of claims 1 to 16 when being executed by a processor.

20. A computer program product, comprising a computer program, characterized in that, The computer program implements the steps of the file upload method according to any one of claims 1 to 16 when being executed by a processor.

Images