File transmission verification method, file transmission system, electronic equipment and storage medium

Abstract

The invention provides a file transmission verification method, a file transmission system, electronic equipment and a storage medium, and relates to the technical field of information. The method comprises the following steps that: client equipment stores data in a memory into a local disk to generate a plurality of original files, and sends a target compressed file to server equipment through an FTP (File Transfer Protocol) channel; if the server device receives the target compressed file, sending a receiving completion instruction to the client device; the client device responds to the receiving completion instruction and generates a client uploading check code according to the target compressed file; and the server device generates a server upload check code, determines whether the server upload check code is the same as the client upload check code, and sends an upload check success indication to the client device if the server upload check code is the same as the client upload check code. On the basis of being compatible with the existing FTP server, the file integrity is automatically checked by using the check code mechanism, so that the reliability of file transmission is ensured, and the transmission efficiency and the data security are also improved.

Description

Technical Field

[0001] The present application relates to the field of information technology, and in particular to a file transmission verification method, a file transmission system, an electronic device and a storage medium. Background Art

[0002] In various application scenarios such as network communication, file transfer is inevitable. It is crucial to ensure that files will not be damaged, tampered with or leaked during the transmission process and to ensure the authenticity and integrity of the files.

[0003] There are two existing solutions to the integrity problem of file transfer when using File Transfer Protocol (FTP) communication, one is manual verification, and the other is to use unofficial FTP extension instructions. Since FTP extension instructions are not supported by many FTP server frameworks, that is, they are not compatible with existing FTP servers, and manual verification is not feasible for systems that require frequent operations. Therefore, how to achieve both compatibility with existing FTP servers and automatic verification of file integrity is a problem that needs to be solved urgently by those skilled in the art. Summary of the invention

[0004] The purpose of this application is to provide a file transfer verification method, a file transfer system, an electronic device and a storage medium to address the deficiencies in the above-mentioned prior art, so as to solve the problem of how to achieve compatibility with existing FTP servers and automatically verify file integrity.

[0005] To achieve the above purpose, the technical solution adopted in the embodiment of the present application is as follows:

[0006] In a first aspect, an embodiment of the present application provides a file transfer verification method, which is applied to a file transfer system, wherein the file transfer system includes: a client device and a server device, and the method includes:

[0007] The client device stores the data in the memory into a local disk to generate a plurality of original files;

[0008] The client device compresses the multiple original files into a target compressed file, and sends the target compressed file to the server device through an FTP channel;

[0009] If the server device receives the target compressed file, it sends a reception completion indication to the client device;

[0010] The client device responds to the reception completion indication, generates a client upload verification code according to the target compressed file, and sends the client upload verification code to the server device;

[0011] The server device generates a server upload verification code according to the received target compressed file, and determines whether the server upload verification code is the same as the client upload verification code. If so, the server device sends an upload verification success indication to the client device.

[0012] In a second aspect, an embodiment of the present application provides a file transfer system, including a client device and a server device, wherein the client device and the server device perform file transfer based on the method described in any one of the first aspects.

[0013] In a third aspect, an embodiment of the present application provides an electronic device, comprising: a processor, a storage medium and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor and the storage medium communicate through the bus, and the processor executes the machine-readable instructions to execute the method steps executed by the client device or the method steps executed by the server device in the file transfer verification method as described in any one of the first aspects above.

[0014] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the method steps performed by a client device or the method steps performed by a server device in the file transfer verification method as described in any one of the first aspects above are executed.

[0015] According to the file transfer verification method, file transfer system, electronic device and storage medium of the embodiment of the present application, the client device stores the data in the memory to the local disk, generates multiple original files, and then compresses these files into a target compressed file, and sends it to the server device through the FTP channel. After receiving the target compressed file, the server device sends a reception completion indication to the client device. The client device generates a client upload verification code and sends it to the server device. The server device generates a server upload verification code and compares it with the client upload verification code. If the two are the same, an upload verification success indication is sent. According to the embodiment of the present application, on the basis of compatibility with the existing FTP server, the compressed file is transmitted through the FTP channel, and the file integrity is automatically verified using the verification code mechanism. Since FTP is a widely used file transfer protocol, most servers support FTP. Sending compressed files through the FTP channel ensures compatibility with existing FTP servers, and the client device and the server device generate verification codes respectively. After receiving the verification code uploaded by the client, the server device generates its own verification code and compares it with the verification code of the client. In this way, the integrity of the file transmission is ensured by generating and comparing the verification code, thereby improving the reliability of transmission and the security of data. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0017] Figure 1 A schematic diagram of the structure of a file transmission system provided by an embodiment of the present application is shown;

[0018] Figure 2 A schematic diagram of a process flow of a file transmission verification method provided by an embodiment of the present application is shown;

[0019] Figure 3 A schematic diagram of a process flow of another file transfer verification method provided by an embodiment of the present application is shown;

[0020] Figure 4 A schematic diagram of a process of uploading a file provided in an embodiment of the present application is shown;

[0021] Figure 5 A schematic diagram of a process flow of a file downloading method provided in an embodiment of the present application is shown;

[0022] Figure 6 A schematic structural diagram of an electronic device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0023] To make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. It should be understood that the drawings in the present application only serve the purpose of explanation and description and are not used to limit the scope of protection of the present application. In addition, it should be understood that the schematic drawings are not drawn in real proportion. The flowchart used in this application shows the operations implemented according to some embodiments of the present application. It should be understood that the operations of the flowchart can be implemented out of sequence, and the steps without logical context can be reversed in order or implemented simultaneously. In addition, those skilled in the art can add one or more other operations to the flowchart under the guidance of the content of the present application, or remove one or more operations from the flowchart.

[0024] In addition, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application described and shown in the drawings here can be arranged and designed in various configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application claimed for protection, but merely represents the selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work belong to the scope of protection of the present application.

[0025] In order to enable those skilled in the art to use the content of this application, the following implementation is provided in conjunction with a specific application scenario "file integrity verification during FTP communication". For those skilled in the art, the general principles defined herein can be applied to other embodiments and application scenarios without departing from the spirit and scope of this application. Although this application is mainly described around a file transfer verification method, it should be understood that this is only an exemplary embodiment.

[0026] It should be noted that the term "comprising" will be used in the embodiments of the present application to indicate the existence of the features declared thereafter, but does not exclude the addition of other features.

[0027] The embodiment of the present application is based on the perspective of information security, and aims to be compatible with the existing FTP server, giving it the function of automatically verifying the integrity of the file, and proposes a set of systematic FTP file transfer processing procedures. The process includes compressing and backing up the file before transmission, verifying after the transmission is completed, and backing up the source file again before decompression, so as to ensure the consistency before and after the file transfer, prevent file loss, and ensure the consistency of the file transfer operation with the operating system. Through this series of measures, the present invention not only improves the performance of the transmission of scattered small files, making the overall transmission speed faster and the transmission result more stable, but also enhances the robustness of the system against network fluctuations, thereby ensuring the reliability and security of file transmission.

[0028] Figure 1 A schematic diagram of the structure of a file transmission system provided by an embodiment of the present application is shown. Figure 1 As shown, the file transfer system includes a client device and a server device, and the client device and the server device can interact through a data transmission network channel (General Remote Procedure Call, gRpc) and a file data transmission channel (File Transfer Protocol, FTP).

[0029] Optionally, based on the above-mentioned file transfer system, the client device stores the data in the memory to the local disk, generates multiple original files, and then compresses these files into a target compressed file, and sends it to the server device through the FTP channel. After receiving the target compressed file, the server device sends a reception completion indication to the client device. The client device generates a client upload verification code and sends it to the server device. The server device generates a server upload verification code and compares it with the client upload verification code. If the two are the same, an upload verification success indication is sent.

[0030] Optionally, the client device sends a review request to the server device, and the server device determines the target download file according to the request and sends a review response. The client device sends a download request according to the review response, and the server device then sends the target download file. After receiving the file, the client device generates a client download verification code and sends it to the server device. The server device generates a server download verification code and compares it with the server download verification code. If they are the same, a download verification success indication is sent.

[0031] Based on this, the file transfer system provided by the embodiment of the present application transmits files through the FTP channel on the basis of compatibility with the existing FTP server, and automatically verifies the integrity of the files using the verification code mechanism. This not only ensures the reliability of file transmission, but also improves the transmission efficiency and data security, and is very suitable for application scenarios that require ensuring data integrity and reliability.

[0032] The following is combined with the above Figure 1 The contents described in the file transfer system shown are used to explain in detail the file transfer verification method provided in the embodiment of the present application.

[0033] Figure 2 A schematic diagram of a file transfer verification method provided by an embodiment of the present application is shown. Figure 2 As shown, the execution subject of the method is the client device and the server device in the above file transfer system, and the method specifically includes the following steps:

[0034] S201. The client device stores the data in the memory in the local disk to generate multiple original files.

[0035] Optionally, the original file is a scattered small file, which has the characteristics of a large number of files, wide distribution (dispersed storage), and small individual files (relative to large files, each file occupies less storage space). Since the data in the memory is volatile, for example, once the client device loses power or restarts, the data in the memory will be lost, so storing the data in the memory on the disk can achieve persistent storage, and the data will not be lost even if the client device is restarted or powered off. In addition, converting the data in the memory into a file format and storing it on the local disk not only facilitates subsequent file transfer and backup operations, but also allows the file data to be restored from the local disk if the data in the memory is damaged for some reason.

[0036] S202: The client device compresses the multiple original files into a target compressed file, and sends the target compressed file to the server device through an FTP channel.

[0037] Optionally, the client device may use a compression algorithm to compress multiple original files into a target compressed file, such as tar.gz, zip, 7z, rar, etc. It should be noted that the compression means are not limited to the compression algorithms in the above examples, and different compression means have their own advantages and disadvantages. In actual applications, different compression means may be used for file compression processing according to different application scenarios and requirements. The client device compresses multiple original files into a target compressed file, and the size of the file can be significantly reduced by compression, thereby reducing the time and bandwidth required for transmission, and the compressed target compressed file is smaller in size and has a faster transmission speed.

[0038] Optionally, the client device sends the target compressed file to the server device through an FTP channel, that is, the client device connects to the server device through the FTP file transfer protocol and sends the target compressed file to the server device. FTP is a widely supported standard protocol that can ensure compatibility with existing FTP servers, and FTP supports breakpoint resuming, which can ensure the reliability of file transmission when the network is unstable.

[0039] S203: If the server device receives the target compressed file, it sends a reception completion indication to the client device.

[0040] Optionally, the server device receives the target compressed file sent by the client device, and sends a reception completion indication to the client device to confirm that the target compressed file has been successfully received. Since it is very important to ensure that the server device has indeed received the target compressed file during the target compressed file transmission process, the present application uses the sending and receiving completion indication as a confirmation mechanism to ensure that the client device knows that the target compressed file has been successfully transmitted to the server device. In addition, during the network transmission process, various problems such as network interruption and data packet loss may be encountered. By sending and receiving completion indications, it can be ensured that both the client device and the server device are aware of the status of the target compressed file transmission, thereby improving the reliability of file transmission.

[0041] S204: The client device responds to the reception completion indication, generates a client upload verification code according to the target compressed file, and sends the client upload verification code to the server device.

[0042] Optionally, the client device receives a reception completion indication, confirms that the target compressed file has been successfully received by the server device, and then generates a client upload verification code based on the target compressed file, and sends the generated client upload verification code to the server device. It should be noted that the client upload verification code is generated to verify the integrity of the target compressed file during the transmission process. Even if the server device confirms that the target compressed file has been received, it cannot completely guarantee that the target compressed file has not been damaged or tampered with during the transmission process. The client upload verification code can be used to detect whether data corruption occurs during the transmission process. If the target compressed file is damaged during the transmission process, the client upload verification code will be different from the server upload verification code generated by the server in the same way after receiving the target compressed file, so that the problem can be discovered and handled in time.

[0043] For example, during the file transfer process, in addition to generating a client upload verification code, a variety of different verification algorithms can also be used to ensure the integrity and security of the file. Specifically, the client device can use the SHA-256 algorithm to generate a hash code, and use the hash code as the client upload verification code. In addition, verification algorithms such as XCRC, XMD5, XSHA1, XSHA256, XSHA512, MD5, SHA-1, SHA-512, etc. can also be used to generate client upload verification codes. The verification algorithm is not limited to the above examples. The specific verification algorithm to be used can be selected according to specific application requirements.

[0044] Optionally, the client device sends the client upload verification code to the server device through the gRpc channel. Among them, gRpc supports features such as bidirectional flow and header compression, which can make the transmission of the client upload verification code more efficient. In addition, in addition to using gRpc for communication transmission, the present application may also use communication methods such as Transmission Control Protocol / Internet Protocol (TCP / IP) or User Datagram Protocol (UDP).

[0045] S205. The server device generates a server upload verification code according to the received target compressed file, and determines whether the server upload verification code is the same as the client upload verification code. If so, the server device sends an upload verification success indication to the client device.

[0046] Optionally, after receiving the target compressed file, the server device generates a server upload verification code in the same way as the client and compares it with the client upload verification code. If the server upload verification code is the same as the client upload verification code, the server device sends an upload verification success indication to the client device. If the target compressed file is damaged during the transmission process, the server upload verification code and the client upload verification code will reflect this change, which means that by comparing whether the server upload verification code is the same as the client upload verification code, it can not only confirm that the target compressed file algorithm is damaged or tampered with during the transmission process, thereby ensuring the integrity of the data, but also provide an error detection mechanism. If the target compressed file is found to be incomplete, retransmission and other measures can be taken in time to reduce the number of retransmissions caused by data damage.

[0047] Based on this, according to a file transfer verification method provided by an embodiment of the present application, on the basis of compatibility with existing FTP servers, compressed files are transmitted through an FTP channel, and the integrity of the files is automatically verified using a verification code mechanism. Since FTP is a widely used file transfer protocol, most servers support FTP, and sending compressed files through an FTP channel ensures compatibility with existing FTP servers, while the client device and the server device generate verification codes respectively. After receiving the verification code uploaded by the client, the server device generates its own verification code and compares it with the verification code of the client, thereby ensuring the integrity of the file transfer by generating and comparing the verification code, thereby improving the reliability of the transmission and the security of the data.

[0048] As a possible implementation manner, after the client device compresses the multiple original files into a target compressed file in step S202, the method further includes:

[0049] The client device encrypts the multiple original files to obtain encrypted files; stores the encrypted files in a local disk; and deletes the multiple original files.

[0050] Exemplarily, the client device encrypts multiple original files to obtain encrypted files, ensuring the security of data during storage and transmission, preventing unauthorized access or data leakage, and the encrypted files are difficult to tamper with. Even if the files are illegally accessed, their actual contents cannot be read.

[0051] Furthermore, the encrypted file is stored in the local disk, and multiple original files are deleted to ensure that the original files no longer exist on the local disk. In this way, the risk of data leakage can be further reduced by deleting the original files to ensure that only the encrypted file exists on the local disk.

[0052] Based on this, multiple original files are encrypted through the client device, and the encrypted files are stored in the local disk, while the original files are deleted, which can ensure the security and integrity of the data and reduce the risk of data leakage. This not only improves the security of the data, but also enhances the trust of users.

[0053] As a possible implementation manner, after the server device sends an upload verification success indication to the client device, the method further includes:

[0054] The client device responds to the upload verification success indication and deletes the encrypted file;

[0055] The server device determines whether the decompressed file corresponding to the target compressed file is stored in the server device. If so, the decompressed file is compressed and backed up, and the target compressed file is decompressed and the decompressed file is saved.

[0056] Exemplarily, the decompressed file corresponding to the target compressed file includes a folder or uncompressed file with the same file name as the target compressed file. After receiving the upload verification success indication sent by the server device, the client device deletes the uploaded encrypted file to release local storage space and avoid useless files occupying resources. The server device checks whether there is already a decompressed file corresponding to the target compressed file in its storage to avoid repeated storage of the same content and save storage space. Specifically, if there are decompressed files corresponding to the target compressed file in the server device, these files are compressed and backed up, and the new target compressed file is decompressed to replace the original decompressed file to ensure data consistency and security.

[0057] Based on this, the client device deletes the encrypted file after receiving the upload verification success indication, and the server device checks and processes the decompressed file corresponding to the target compressed file, which can ensure the integrity and consistency of the data and improve the efficiency of data transmission and processing.

[0058] As a possible implementation manner, after sending the target compressed file to the server device, the method further includes:

[0059] If the client device does not receive the receiving completion indication sent by the server device, it re-uploads the target compressed file and records the first number of re-uploads; if the first number of re-uploads reaches the first preset number, the client device outputs a first error prompt.

[0060] Exemplarily, if the client device does not receive a receiving completion indication sent by the server device after uploading the target compressed file, indicating that the upload may have failed or been interrupted, the client device will re-upload the target compressed file and record the number of re-uploads, that is, the first number of re-uploads, to ensure that the upload is not attempted indefinitely. If the first number of re-uploads reaches a preset number, that is, the first preset number, for example, three times, the client device will stop re-uploading and output an error prompt. Among them, the retry mechanism can significantly increase the probability of successful upload, especially when the network conditions are unstable, and setting an upper limit on the number of retries can avoid unlimited consumption of network resources and computing resources.

[0061] Based on this, by re-uploading the target compressed file when the client device does not receive the reception completion indication sent by the server device, and recording the number of re-uploads until the preset upper limit is reached, the reliability and rationality of the upload process can be ensured, and the success rate of the upload can be improved.

[0062] As a possible implementation manner, after determining whether the verification code uploaded by the server is the same as the verification code uploaded by the client, the method further includes:

[0063] If the verification code uploaded by the server is different from the verification code uploaded by the client, the server device deletes the received target compressed file and sends a re-upload instruction to the client device;

[0064] If the second number of re-uploads reaches the second preset number, the server device sends an upload failure indication to the client device; the client device outputs a second error prompt according to the upload failure indication.

[0065] For example, if the verification code uploaded by the server is different from the verification code uploaded by the client, it means that the file may have been damaged or tampered with during the transmission process. The server device deletes the received target compressed file and sends a re-upload instruction to the client device, notifying the client device to re-upload the file. At the same time, the client device records the number of re-uploads and records it as the second number of re-uploads. If the second number of re-uploads reaches a predetermined number, that is, a second preset number, for example, three times, the server device sends an upload failure indication to the client device, and the client device outputs a second error prompt according to the upload failure indication.

[0066] Based on this, when the server device receives a verification inconsistency indication, it deletes the received file and sends a re-upload indication to the client device, while recording the number of re-uploads until the preset upper limit is reached. This can ensure the reliability and rationality of the upload process and improve the reliability of data transmission.

[0067] Figure 3 The following is a flow chart showing another method for verifying file transmission provided by an embodiment of the present application. Figure 3 As shown, the execution subject of the method is the client device and the server device in the above file transfer system, and the method specifically includes the following steps:

[0068] S301, the client device sends a viewing request to the server device.

[0069] For example, before officially downloading, the client device needs to confirm whether the target file exists to avoid invalid downloading, and if the file does not exist, directly initiating a download request will result in download failure, resulting in a waste of network resources. In this application, the client device first sends a review request to the server device, the purpose of which is for the client device to confirm the existence of the target download file and its basic information, such as file size, file name, etc., so as to decide whether to download the file.

[0070] S302: The server device determines the target download file according to the inspection request, and sends an inspection response to the client device.

[0071] For example, the server device searches and determines the target download file requested by the client according to the received inspection request, and sends an inspection response to the client device. Through the inspection response, the client device can know the existence of the target file in advance, that is, it can ensure that the file requested by the client device does exist, avoiding invalid operations caused by the non-existence of the file.

[0072] S303: The client device sends a download request to the server device based on the inspection response.

[0073] For example, the client device sends a download request to the server device according to the inspection response, requesting to download the specified target download file, ensuring that the server device sends the correct file and avoiding mistransmission or sending of the wrong file. And through the orderly interaction of the inspection response and the download request, the efficiency of file transmission can be improved, ensuring that each transmission is effective and the specificity and accuracy of the request are ensured.

[0074] S304: The server device sends the target download file to the client device according to the download request.

[0075] Exemplarily, the server device determines the target download file based on the received download request and sends the target download file to the client device. Through the download request, the client device can specify a specific file, and the server device sends the corresponding file according to the request instead of sending unnecessary files, thereby improving transmission efficiency and reducing unnecessary network load. Furthermore, the correctness and orderliness of file transmission can be ensured, transmission efficiency can be improved, and user experience can be enhanced. This method not only clarifies the operating intentions of both parties, but also enhances the security of the transmission process.

[0076] S305: If the client device receives the target download file, it generates a client download verification code according to the target download file, and sends the client download verification code to the server device.

[0077] Exemplarily, after receiving the file, the client device generates a client download verification code and sends it to the server device for verification. Specifically, the client device can use the SHA-256 algorithm to generate a hash code and use the hash code as the client download verification code. In addition, XCRC, XMD5, XSHA1, XSHA256, XSHA512, MD5, SHA-1, SHA-512 and other verification algorithms can also be used to generate client download verification codes. The verification algorithm is not limited to the above examples. The specific verification algorithm to be used can be selected according to specific application requirements.

[0078] S306. The server device generates a server download verification code according to the target download file stored on the server device, and determines whether the server download verification code is the same as the client download verification code. If so, the server device sends a download verification success indication to the client device.

[0079] Exemplarily, the server device uses the same method as the client device to generate a server download verification code based on the target download file stored on the server device, and compares the server download verification code with the client download verification code. If the server download verification code is the same as the client download verification code, the server device sends a download verification success indication to the client device. If the target compressed file is damaged during the transmission process, the server download verification code and the client download verification code will reflect this change, which means that by comparing whether the server download verification code is the same as the client download verification code, it can not only confirm that the target compressed file algorithm is damaged or tampered with during the download process, thereby ensuring the integrity of the data, but also provide an error detection mechanism. If the target compressed file is found to be incomplete, retransmission and other measures can be taken in time to reduce the number of retransmissions caused by data damage.

[0080] Based on this, according to another file transfer verification method provided in an embodiment of the present application, the client device sends a review request to the server device, and the server device determines the target download file based on the request and sends a review response. The client device sends a download request based on the review response, and the server device then sends the target download file. After receiving the file, the client device generates a client download verification code and sends it to the server device. The server device generates a server download verification code and compares it with the server. If they are the same, a download verification success indication is sent. According to the review and verification mechanism in the file download process provided in an embodiment of the present application, confirmation of the existence of the file, orderly transmission, and verification of data integrity can be achieved during the file download process, thereby not only improving the reliability of file transmission, but also enhancing the accuracy and consistency of data transmission, thereby improving the user experience and the overall quality of data transmission.

[0081] As a possible implementation manner, after the server device sends a download verification success indication to the client device, the method further includes:

[0082] The client device responds to the download verification success indication, decompresses the received target download file, writes the decompressed data into the memory of the client device, and deletes the target download file.

[0083] Exemplarily, the client device receives a download verification success indication sent by the server device, which means that the integrity of the target download file has been verified, and then the client device decompresses the received target download file to restore the file to its original state.

[0084] Furthermore, the client device writes the decompressed data into its memory for further processing or use, and deletes the decompressed target download file to free up storage space.

[0085] Based on this, the download verification success indication ensures that the target download file is not damaged or tampered with during the transmission process, thereby improving the reliability of the data. Since the memory access speed is much higher than the disk access speed, writing the decompressed data into the memory can speed up the data processing. In addition, deleting the decompressed target download file can free up storage space and prevent temporary files from occupying too much disk space.

[0086] As a possible implementation manner, after sending the target download file to the client device, the method further includes:

[0087] If the client device does not receive the target download file, it resends the download request to the server device and records the first number of re-downloads; if the first number of re-downloads reaches a third preset number, the client device outputs a third error prompt.

[0088] For example, if the client device does not receive the target download file within the expected time, it is considered that the download has failed. The client device will resend the download request to the server device and record the number of re-downloads, that is, the first number of re-downloads. If the first number of re-downloads reaches a preset number, that is, the third preset number, for example, three times, the client device will stop trying to re-download and output an error prompt. Among them, by resending the download request, it is possible to deal with download failures caused by network instability or temporary failures, and ensure that the file can be successfully downloaded in the end. By setting a preset number limit, it is possible to prevent resource waste and system burden caused by unlimited retries. When the number of retries reaches the upper limit and the download still fails, the client device outputs an error prompt to inform the user of the download failure, so that the user can take other measures or contact technical support.

[0089] Based on this, the client device resends the download request when the target download file is not received, and records the number of re-downloads until the preset upper limit is reached, so as to ensure the reliability and rationality of the download process. This method not only improves the download success rate and makes rational use of system resources, but also improves the user experience and the convenience of fault diagnosis through error prompts.

[0090] As a possible implementation, after determining whether the server download verification code is the same as the client download verification code, the method further includes:

[0091] If the verification code downloaded by the server is different from the verification code downloaded by the client, the server device sends a verification inconsistency indication to the client device;

[0092] The client device deletes the downloaded target download file according to the verification inconsistency indication, resends the download indication to the server device, and records the second re-download count; if the second re-download count reaches a fourth preset count, the client device outputs a fourth error prompt.

[0093] Exemplarily, if the server download verification code is different from the client download verification code, it means that the file may have been damaged or tampered with during the transmission process. The server device sends a verification inconsistency indication to the client device to notify the client that the file verification has not passed. According to the verification inconsistency indication, the client device deletes the downloaded target download file, resends the download request to the server device, and records the number of downloads as the second number of re-downloads. If the second number of re-downloads reaches a preset number, that is, a fourth preset number, for example, three times, the client device will stop trying to re-download and output an error prompt. Among them, the verification code mechanism ensures that the file has not been tampered with or damaged during the transmission process, which not only improves the reliability of data transmission, but also can detect errors in the file transmission process in a timely manner to avoid the use of damaged files.

[0094] Based on this, when the client device receives a verification inconsistency indication, it deletes the downloaded file and resends the download request, and records the number of re-downloads until the preset upper limit is reached, thereby ensuring the reliability and rationality of the download process and improving the reliability of data transmission.

[0095] As a possible implementation, Figure 4 The following is a flow chart of a method for uploading a file provided in an embodiment of the present application. Figure 4 As shown, before uploading file data, the client (APP) first writes the information in the memory to a local file, then compresses the folder A to be uploaded to generate an A.tar.gz compressed package, and uploads it to the server (RC) through the FTP channel. After compressing A.tar.gz, the client encrypts the content in the local folder A and saves it as an A.zip file, and then deletes the unencrypted local A folder. When the same file is uploaded again, the locally stored A.zip file will be replaced.

[0096] After the client receives the message that the server has completed the acceptance, it sends the hash code generated by A.tar.gz according to the SHA-256 algorithm through the gRpc channel. The server also uses the SHA-256 algorithm to generate a hash code for the received A.tar.gz file and compares it with the hash code sent by the client. If the hash codes are inconsistent, it means that the data has been changed during the transmission process. At this time, the server will delete the received file and re-download the verification (for example, repeat three times in total). If the maximum number of retries is exceeded, the user will be prompted to continue processing on the client; if the verification is consistent, the client will delete the A.tar.gz compressed package, and the server will check whether it has an A folder. If the server has an A folder, it will be compressed and backed up, and A.tar.gz will be decompressed to replace the original A folder.

[0097] As a possible implementation, Figure 5 The following is a flow chart of a file downloading method provided by an embodiment of the present application. Figure 5 As shown, when the client (APP) downloads a file, it first checks the folder existing on the server (RC) and directly sends a request to download the corresponding folder .tar.gz compressed package. If the server does not have the relevant file compression package, the server will compress the folder first and then send it back to the client. After the client completes the download, it uses the SHA-256 algorithm to generate a hash code for the compressed package, and sends the hash code to the server through the gRpc channel, waiting for the server to return the comparison result. If the hash codes are consistent, the client decompresses the compressed package and reads the decompressed content into memory for subsequent processing by the system. Subsequently, the client deletes the downloaded compressed package and the local files generated after decompression to prevent leaks.

[0098] In addition, if the hash code comparison results are inconsistent or an exception occurs during the download process, the client will delete the locally downloaded file and retry the download until the maximum number of retries (for example, 3 times) is reached. If the retry still fails, the client will display an exception message. In this way, not only the integrity of file transfer and data consistency are ensured, but also the reliability of the system is improved through multiple verification and retry mechanisms. In addition, by timely deleting the downloaded compressed package and the decompressed local file, the security of the data is enhanced and the potential risk of data leakage is prevented.

[0099] Based on this, the embodiment of the present application transmits after compressing the file, which reduces the amount of data to be transmitted on the one hand, and integrates scattered small files into a large compressed file on the other hand, thereby reducing a large number of protocol headers in the FTP transmission process, increasing the transmission ratio of effective data, and significantly improving the file transfer rate. In addition, through the process of autonomous verification confirmation and re-download, the adverse effects of data tampering and loss on system stability during transmission are effectively avoided. Since the embodiment of the present application is an extension of existing instructions based on the current standard, it has wide compatibility with FTP servers, and the original files to be transmitted are backed up through controllable redundant compressed files, which prevents data loss and well ensures the atomicity of FTP file transmission in the entire system. In this way, not only the transmission efficiency is improved, but also the reliability and data security of the system are enhanced.

[0100] The present application embodiment also provides an electronic device 600, such as Figure 6 As shown, it is a schematic diagram of the structure of an electronic device 600 provided in an embodiment of the present application, including: a processor 601, a memory 602, and optionally, a bus 603. The memory 602 stores machine-readable instructions executable by the processor 601. When the electronic device 600 is running, the processor 601 communicates with the memory 602 through the bus 603. When the machine-readable instructions are executed by the processor 601, the method steps executed by the client device or the method steps executed by the server device in any of the above file transfer verification methods are executed.

[0101] An embodiment of the present application also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the method steps performed by a client device or the method steps performed by a server device in any of the file transfer verification methods described above are executed.

[0102] Those skilled in the art can clearly understand that, for the convenience and simplicity of description, the specific working process of the system and device described above can refer to the corresponding process in the method embodiment, and will not be repeated in this application. In the several embodiments provided in this application, it should be understood that the disclosed system, device and method can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the modules is only a logical function division. There may be other division methods in actual implementation. For example, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0103] In addition, each functional unit in each embodiment of the present application can be integrated into a processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention is essentially or part of the technical solution that contributes to the prior art or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, RandomAccess Memory), disk or optical disk and other media that can store program code.

[0104] The above are only specific implementation methods of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be covered by the protection scope of the present application.

Claims

1. A file transfer verification method, characterized in that: Applied to a file transmission system, the file transmission system includes: a client device and a server device, the method includes: The client device stores the data in the memory into a local disk to generate a plurality of original files; The client device compresses the multiple original files into a target compressed file, and sends the target compressed file to the server device through an FTP channel; If the server device receives the target compressed file, it sends a reception completion indication to the client device; The client device responds to the reception completion indication, generates a client upload verification code according to the target compressed file, and sends the client upload verification code to the server device; The server device generates a server upload verification code according to the received target compressed file, and determines whether the server upload verification code is the same as the client upload verification code. If so, the server device sends an upload verification success indication to the client device.

2. The method according to claim 1, characterized in that After the client device compresses the multiple original files into a target compressed file, the method further includes: The client device encrypts the multiple original files to obtain encrypted files; The client device stores the encrypted file in a local disk; The client device deletes the multiple original files.

3. The method according to claim 2, characterized in that After the server device sends an upload verification success indication to the client device, the method further includes: The client device deletes the encrypted file in response to the upload verification success indication; The server device determines whether a decompressed file corresponding to the target compressed file is stored in the server device. If so, the decompressed file is compressed and backed up, and the target compressed file is decompressed and replaced with the decompressed file.

4. The method according to claim 1, characterized in that: The step of sending the client upload verification code to the server device includes: The client device sends the client upload verification code to the server device through the gRpc channel.

5. The method according to claim 1, characterized in that After sending the target compressed file to the server device, the method further includes: If the client device does not receive the receiving completion indication sent by the server device, re-upload the target compressed file and record the first re-upload count; If the first re-upload count reaches a first preset count, the client device outputs a first error prompt.

6. The method according to claim 1, characterized in that After determining whether the verification code uploaded by the server is the same as the verification code uploaded by the client, the method further includes: If the server upload verification code is different from the client upload verification code, the server device deletes the received target compressed file and sends a re-upload instruction to the client device; If the second re-upload number reaches a second preset number, the server device sends an upload failure indication to the client device; The client device outputs a second error prompt according to the upload failure indication.

7. The method according to any one of claims 1 to 6, characterized in that: Also includes: The client device sends a viewing request to the server device; The server device determines the target download file according to the inspection request, and sends an inspection response to the client device; The client device sends a download request to the server device according to the inspection response; The server device sends the target download file to the client device according to the download request; If the client device receives the target download file, it generates a client download verification code according to the target download file, and sends the client download verification code to the server device; The server device generates a server download verification code according to the target download file stored on the server device, and sends a download verification success indication to the client device based on whether the server download verification code is the same as the client download verification code. If so, the server device 8. The method according to claim 7, characterized in that After the server device sends a download verification success indication to the client device, the method further includes: The client device responds to the download verification success indication, decompresses the received target download file, writes the decompressed data into the memory of the client device, and deletes the target download file.

9. The method according to claim 7, characterized in that: After sending the target download file to the client device, the method further includes: If the client device does not receive the target download file, resend the download request to the server device and record the first re-download count; If the first re-download times reaches a third preset times, the client device outputs a third error prompt.

10. The method according to claim 7, characterized in that After determining whether the server download verification code is the same as the client download verification code, the method further includes: If the verification code downloaded by the server is different from the verification code downloaded by the client, the server device sends a verification inconsistency indication to the client device; The client device deletes the downloaded target download file according to the verification inconsistency indication, resends the download indication to the server device, and records the second re-download number; If the second re-download times reaches a fourth preset times, the client device outputs a fourth error prompt.

11. A file transmission system, characterized in that: The system includes a client device and a server device, and the client device and the server device perform file transmission based on the method according to any one of claims 1-10.

12. An electronic device, characterized in that: include: A processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor executes the machine-readable instructions to execute the method steps executed by the client device or the method steps executed by the server device in the file transfer verification method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, which, when executed by a processor, executes the method steps executed by a client device or the method steps executed by a server device in the file transmission verification method according to any one of claims 1 to 10.

Images