File transfer disaster recovery method, electronic equipment, storage medium and program product

Abstract

The embodiment of the invention provides a file transfer disaster recovery method, electronic equipment, a storage medium and a program product. The file transmission disaster recovery method is applied to a client, and comprises the following steps: in a process of transmitting a target file through a default gateway, detecting an operation state of the default gateway; when the running state of the default gateway is abnormal and the transmission of the target file is not completed, recording progress information of transmitted file data, and determining an available standby gateway; and continuing to transmit the remaining file data of the target file through the standby gateway based on the progress information. According to the method, the client side autonomously detects the state of the gateway, the standby gateway can be rapidly switched without back-end triggering, resource consumption and time delay are reduced, meanwhile, a service interruption blind area formed due to the fact that no client side has no sensing capacity is avoided, the system toughness and user experience of financial services in the high-concurrency and high-availability environment are remarkably improved, and the service experience of the financial services is improved. And the autonomous controllability of the bank on the terminal service stability is enhanced.

Description

Technical Field

[0001] This application relates to the field of computer software, and more particularly to a file transfer disaster recovery method, electronic device, storage medium, and program product. Background Technology

[0002] Bank counter services commonly employ hybrid development frameworks, with the WebView component serving as the core for business interactions. Daily counter operations involve numerous file uploads and downloads, resource loading, and other operations, all of which must be performed through a gateway. The gateway's stability directly impacts business continuity and user experience.

[0003] In existing technologies, disaster recovery solutions for network links and services are mostly based on the backend service operation and maintenance level. For example, by monitoring network access traffic and combining it with disaster recovery data center switching mechanisms to realize application disaster recovery switching, although it can reduce the complexity of backend disaster recovery switching and cope with backend data center or service cluster failures, this solution has significant shortcomings: First, the switching is large-scale, switching on an application or data center basis, which consumes a lot of resources and has high latency, and cannot meet the real-time requirements of bank counter file upload and download; Second, it can only detect backend service anomalies and cannot identify single point of failure of the default gateway on the client side. When the gateway failure causes the file transfer link to be interrupted, if the backend traffic is normal, no disaster recovery action will be triggered, creating a blind spot for business interruption; Third, there is no independent disaster recovery capability on the client side, relying entirely on the backend architecture support, which cannot accurately adapt to file upload and download scenarios and makes it difficult to ensure business continuity under gateway failure.

[0004] Therefore, there is an urgent need for a file transfer disaster recovery solution for client applications to ensure the continuity of file transfer in the event of gateway failure and to support the orderly operation of bank counter services. Summary of the Invention

[0005] This application provides a file transfer disaster recovery method, electronic device, storage medium, and program product. By detecting the status of the default gateway from the client side and automatically switching to the backup gateway for interrupted transmission in case of an anomaly, a file transfer disaster recovery solution is realized on the client side, improving the continuity of file transfer and ensuring the high availability of banking services.

[0006] In a first aspect, embodiments of this application provide a file transfer disaster recovery method, comprising: detecting the operating status of the default gateway during the transmission of a target file through the default gateway; recording the progress information of the transmitted file data and determining an available backup gateway when the operating status of the default gateway is abnormal and the target file has not been completely transmitted; and continuing to transmit the remaining file data of the target file through the backup gateway based on the progress information.

[0007] In one possible implementation, before continuing to transmit the remaining file data of the target file through the backup gateway based on the progress information, the process includes: determining the concurrency level based on the file transfer scenario type of the target file, so as to continue transmitting the remaining file data of the target file through the backup gateway based on the progress information under concurrency control; the concurrency level is used to control the number of transmission requests sent by the client to the backup gateway.

[0008] In one possible implementation, the file transfer scenario is a file upload type. Based on progress information and concurrency, the remaining file data of the target file continues to be transmitted through a backup gateway. This includes: determining the remaining unuploaded slices based on the sequence numbers of the uploaded slices in the progress information; encapsulating the remaining slices into request messages based on the protocol specifications of the backup gateway; and uploading a set of request messages for the corresponding number of remaining slices in parallel through the backup gateway according to the concurrency and slice sequence number, so that the file resource server can reassemble the parsed remaining slices into a complete file based on the slice sequence number; and receiving a file storage success confirmation message or the file identifier of the target file returned by the file resource server.

[0009] In one possible implementation, the file transfer scenario is a file download. Based on progress information and concurrency, the remaining file data of the target file continues to be transmitted through a backup gateway. This includes: determining the undownloaded remaining slices based on the offset of the downloaded bytes in the progress information; for each remaining slice, converting the download request format according to the protocol specification of the backup gateway; sending a set of format-converted download requests in parallel to the backup gateway according to the concurrency and slice sequence number, so as to receive the remaining slices returned by the file resource server through the backup gateway; and merging the received remaining slices with the downloaded data of the target file to obtain the target file.

[0010] In one possible implementation, the file transfer scenario is a webpage view page resource loading type. Based on progress information and concurrency, the remaining file data of the target file continues to be transferred through a backup gateway. This includes: intercepting the Uniform Resource Locator (URL) corresponding to the target file through a request interception callback function, simultaneously starting a timer of a preset duration, adding the intercepted URLs to a buffer queue, and establishing a corresponding resource pipeline for each intercepted URL. The webpage view kernel is suspended and waits for a response. When the timer expires, the remaining file data of each URL is determined according to the progress information corresponding to each URL in the buffer queue, and the buffer queue is cleared. Based on the protocol specifications of the backup gateway, the remaining file data of each URL is... The download requests for the remaining file data undergo format conversion; download requests are transmitted in parallel to the backup gateway according to concurrency, so that the backup gateway can receive the file slices corresponding to each Uniform Resource Locator (URI) returned by the file resource server, and combine the slices into a complete file to obtain the target file corresponding to each URI; each target file is re-sharded according to the byte stream order, and the re-sharded slice data is written in parallel to the write end of the corresponding resource pipeline; the slice data is sequentially read from the read end of each resource pipeline through the web page view kernel, and the read slice data is rendered to the page as a network response; when all the data corresponding to any URI has been read and rendered by the web page view kernel, the resource pipeline corresponding to the URI is released.

[0011] In one possible implementation, the file transfer scenario is a browser tool resource loading type. Based on progress information and concurrency, the remaining file data of the target file continues to be transferred through a backup gateway. This includes: determining the undownloaded remaining slices based on the offset of the downloaded bytes in the progress information; for each remaining slice, converting the download request format according to the protocol specification of the backup gateway; sending a set of format-converted download requests in parallel to the backup gateway according to the concurrency and slice order, so as to receive the remaining slices returned by the file resource server through the backup gateway; merging the received remaining file slices with the downloaded data of the target file to obtain the target file, storing it locally on the client and generating a local file path; passing the local file path to the browser tool so that the browser tool can load and render the corresponding resources based on the local path; and releasing the local cached resources corresponding to the target file after the browser tool confirms that the resources have been fully loaded.

[0012] In one possible implementation, detecting the operating status of the default gateway includes: collecting the response latency and connection success rate of the default gateway; receiving the status configuration of the default gateway issued by the server based on the user account dimension or the network node dimension; and determining the operating status of the default gateway based on the response latency and connection success rate of the default gateway, as well as the status configuration of the default gateway.

[0013] Secondly, embodiments of this application provide a file transfer disaster recovery device, comprising: a status detection module, used to detect the operating status of the default gateway during the transmission of a target file through the default gateway; an exception handling module, used to record the progress information of the transmitted file data and determine an available backup gateway when the operating status of the default gateway is abnormal and the target file has not been completely transmitted; and a resume execution module, used to continue transmitting the remaining file data of the target file through the backup gateway based on the progress information.

[0014] In one possible implementation, the status detection module is specifically used for: collecting the response latency and connection success rate of the default gateway; receiving gateway status configurations issued by the server based on user account or network location dimensions; and determining the operating status of the default gateway based on the response latency and connection success rate of the default gateway, as well as the issued gateway status configurations.

[0015] In one possible implementation, the device further includes a concurrency determination module, configured to: determine the concurrency level based on the file transfer scenario type of the target file before continuing to transmit the remaining file data of the target file through the backup gateway based on the progress information, so as to continue transmitting the remaining file data of the target file through the backup gateway under concurrency control; the concurrency level is used to control the number of transmission requests sent by the client to the backup gateway.

[0016] In one possible implementation, the resume execution module is specifically used for: if the file transfer scenario type is file upload, determining the remaining unuploaded slices based on the sequence number of the uploaded slices in the progress information; encapsulating the remaining slices into request messages based on the protocol specification of the backup gateway; and uploading a set of request messages for the corresponding number of remaining slices in parallel through the backup gateway according to the concurrency and slice sequence number, so that the file resource server can reassemble the parsed remaining slices into a complete file according to the slice sequence number; and receiving the file storage success confirmation information or the file identifier of the target file returned by the file resource server.

[0017] In one possible implementation, the resume execution module is specifically used for: if the file transfer scenario type is file download, determining the remaining undownloaded slices based on the offset of the downloaded bytes in the progress information; for each remaining slice, performing format conversion on the download requests of the remaining slices based on the protocol specifications of the backup gateway; sending a set of format-converted download requests in parallel to the backup gateway according to the concurrency and slice sequence number, so as to receive the remaining slices returned by the file resource server through the backup gateway; and merging the received remaining slices with the downloaded data of the target file to obtain the target file.

[0018] In one possible implementation, the resume execution module is specifically used for: if the file transfer scenario type is webpage view page resource loading, then intercepting the Uniform Resource Locator (URL) corresponding to the target file through a request interception callback function, simultaneously starting a timer of preset duration, adding the intercepted URLs to a buffer queue, and establishing a corresponding resource pipeline for each intercepted URL. The webpage view kernel is suspended and waits for a response. When the timer expires, determining the remaining file data for each URL based on the progress information corresponding to each URL in the buffer queue, and clearing the buffer queue. Based on the protocol specifications of the backup gateway, processing the download requests for the remaining file data of each URL. The process involves: format conversion; parallel transmission of download requests to a backup gateway based on concurrency; receiving file slices corresponding to each Uniform Resource Locator (URI) returned by the file resource server through the backup gateway; merging the slices into a complete file to obtain the target file corresponding to each URI; re-slicing each target file according to the byte stream order; writing the re-sliced ​​slice data in parallel to the write end of the corresponding resource pipeline; sequentially reading the slice data from the read end of each resource pipeline via the web view kernel; rendering the read slice data as a network response to the page; and releasing the resource pipeline corresponding to any URI after all data has been read and rendered by the web view kernel.

[0019] In one possible implementation, the resume execution module is specifically used for: if the file transfer scenario type is browsing tool resource loading type, determining the remaining undownloaded segments based on the offset of the downloaded bytes in the progress information; for each remaining segment, performing format conversion on the download requests corresponding to the remaining segments based on the protocol specifications of the backup gateway; sending a set of format-converted download requests of a corresponding number in parallel to the backup gateway according to the concurrency and segment order, so as to receive the remaining segments returned by the file resource server through the backup gateway; merging the received remaining file segments with the downloaded data of the target file to obtain the target file, storing it locally on the client and generating a local file path; passing the local file path to the browsing tool so that the browsing tool can load and render the corresponding resources based on the local path; and releasing the local cached resources corresponding to the target file after the browsing tool confirms that the resources have been fully loaded.

[0020] Thirdly, embodiments of this application provide a file transfer disaster recovery device, including: a memory and a processor; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0021] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0022] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0023] The file transfer disaster recovery method, electronic device, storage medium, and program product provided in this application embodiment actively detect the response latency and connection success rate of the default gateway during file transfer to promptly detect default gateway anomalies. When a default gateway anomaly causes file transfer interruption, progress information is obtained by recording the file transfer progress, providing a basis for seamless gateway switching. Simultaneously, when the default gateway is abnormal, the client automatically determines an available backup gateway and, based on the progress information, completes the transfer of the remaining file data through that backup gateway. This method allows the client to perform status judgment, progress recording, and link switching decisions locally, reducing disaster recovery response time and ensuring seamless continuity for financial services with high real-time requirements even when the gateway is abnormal. Based on slice progress, only the incomplete portion is retransmitted, effectively avoiding duplicate data transmission. Furthermore, the client intelligently adjusts protocol encapsulation, concurrency control, and data processing strategies according to different file transfer scenarios, achieving a single architecture covering multiple business scenarios and reducing maintenance complexity. Attached Figure Description

[0024] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0025] Figure 1 A schematic diagram illustrating one application scenario provided in this application;

[0026] Figure 2 Flowchart of the file transfer disaster recovery method provided in this application Figure 1 ;

[0027] Figure 3 Flowchart of the file upload disaster recovery method provided for this application Figure 2 ;

[0028] Figure 4 Scenario illustration of the file upload disaster recovery method provided in this application Figure 3 ;

[0029] Figure 5 Flowchart of the file download disaster recovery method provided for this application Figure 4 ;

[0030] Figure 6 Scenario illustration of the file download disaster recovery method provided in this application Figure 5 ;

[0031] Figure 7 A flowchart illustrating the disaster recovery method for loading webpage view resources provided in this application. Figure 6 ;

[0032] Figure 8 A scenario illustration of the disaster recovery method for loading webpage view page resources provided in this application. Figure 7 ;

[0033] Figure 9 A flowchart illustrating the disaster recovery method for loading browsing tool resources provided in this application. Figure 8 ;

[0034] Figure 10 A scenario illustration of the disaster recovery method for loading browsing tool resources provided in this application. Figure 9 ;

[0035] Figure 11 Schematic diagram of the file transfer disaster recovery device provided in this application Figure 10 ;

[0036] Figure 12 Schematic diagram of the file transfer disaster recovery device provided in this application Figure 10 one.

[0037] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0038] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0039] First, let me explain the terms used in this application:

[0040] Default gateway: refers to the main network access point preset by the client for all file transfer services. It is the primary and preferred communication channel connecting the client and the file resource server.

[0041] Backup gateway: refers to a pre-configured alternative network access point that is activated when the default gateway fails. Its function is to take over the transmission tasks of the default gateway and ensure business continuity.

[0042] Concurrency: refers to the maximum number of transmission requests that a client is allowed to send simultaneously to the default gateway or backup gateway in a specific file transfer scenario. Concurrency is used to balance transmission rate and success rate and can be dynamically adjusted according to gateway performance.

[0043] Webpage view resource loading: In the webpage view component, this is the process of acquiring and rendering network resources embedded in the page, which is automatically initiated by the browser kernel.

[0044] Resource loading for browsing tools: This refers to the process by which a financial client responds to a business instruction and calls a third-party application to open a network file, such as a word processing system (WPS) or an image viewer.

[0045] Intercept callback function: This refers to a specific programming interface provided by the client to the web page view component. When the web page view kernel is about to initiate a network request, the system calls this function, giving the client an opportunity to check and decide whether to intercept the request, thereby intervening in the subsequent processing flow.

[0046] Uniform Resource Locator (URL): A standard address string used to uniquely identify and locate a resource on the Internet.

[0047] Resource pipeline: refers to a cross-process or cross-thread data transmission channel created within the client to efficiently and orderly transfer file slice data streams between the client application layer and the web page view kernel, in order to simulate the effect of network loading.

[0048] Figure 1 A schematic diagram illustrating an application scenario provided in this application, such as... Figure 1 As shown, there are numerous and varied file resource transfer scenarios in bank counter business processes. These scenarios rely on a file transfer system centered around gateways, file resource servers, and hybrid architecture clients. These scenarios mainly involve file uploading, file downloading, and resource loading, such as uploading ID documents, downloading business contracts, previewing electronic vouchers, and accessing image data. Figure 1Taking client-side file download as an example, JavaScript triggers a download request for the target file, which is then sent to the gateway by the client. Upon receiving the download request, the gateway forwards it to the file application service on the server, which then sends the file read instruction to the file resource server. The target file is stored entirely on the file resource server, not in segments. The file resource server parses the received download request, reads the corresponding file segment data from the stored target file, and sends the file segment data back to the client sequentially through the gateway. Figure 1 The ordered slices are 1 to n. After the client receives all the slice data of the target file through the gateway, it synthesizes them into the target file locally and generates a local path. Then, it returns the local path to the JS layer for use by other subsequent business processes.

[0049] However, the transfer of target files is highly dependent on the gateway as a single channel. If the gateway malfunctions due to equipment failure, network jitter, or overload, the client's request to the gateway will not be delivered, and the gateway will also be unable to transmit the data returned from the backend back to the client, resulting in the interruption of the entire file download link and the stagnation of the business process.

[0050] Both disaster recovery technologies, namely, traffic switching based on disaster recovery data centers and DNS (Domain Name System) redirection, involve server-side or network layer operations. Disaster recovery based on traffic switching covers the entire data center, resulting in high resource consumption and response latency, failing to meet the second-level recovery requirements of high-real-time services such as file transfers. This method cannot detect gateway anomalies between the client and server; when the gateway is faulty but the server is functioning normally, no switching action is triggered, causing critical service interruptions. DNS redirection technology suffers from significant latency, limited by DNS record caching and unable to take effect in real time. Its switching scope is the entire domain, making precise control over specific services or gateways impossible. Furthermore, it completely fails to detect and resolve gateway anomalies between the client and server, meaning that even if the address switch is successful, the transmission link may still be interrupted due to gateway anomalies, making it difficult to meet the high real-time, high continuity, and lossless user experience requirements of financial counter services.

[0051] Based on this, this application provides a file transfer disaster recovery method. When a file is being transferred through the link where the default gateway is located, or during the transfer process, if the client detects an interruption due to anomalies such as default gateway failure, overload, or maintenance, the client determines an available backup gateway and provides disaster recovery takeover capabilities through the backup gateway, thus ensuring the continuity of file transfer under single-point gateway failure. This method refines the process from traditional service-level or data center-level approaches down to individual file transfer links, significantly reducing switching latency and resource overhead, and effectively filling the business blind spots that existing backend disaster recovery technologies cannot cover due to client-side gateway failures. By enabling the client to autonomously switch gateway transfer links, the reliability of file transfer, system resilience, and user experience are ensured, providing core client-side protection capabilities for stable business operation under high availability requirements.

[0052] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0053] Figure 2 Flowchart of the file transfer disaster recovery method provided in this application Figure 1 ,like Figure 2 As shown, the file transfer disaster recovery method is applied to the client, which can be a user terminal, bank self-service equipment, counter equipment, etc.; the method includes:

[0054] Step S201: During the transmission of the target file through the default gateway, the running status of the default gateway is detected.

[0055] The target file refers to the file that needs to be transferred between the gateway and the server-side file resource server in the client's business process. This file can be an image, document, video, resource, etc. The operational status characterizes whether the default gateway has file transfer capabilities and can include network layer connectivity metrics, service response time, and performance metrics. A gateway is considered to be operating abnormally when it experiences connection failure, response timeout, returns a specific error code, or suffers severe performance degradation; conversely, if the gateway can stably establish a connection and promptly return a success response, it is considered to be operating normally.

[0056] During file transfer, the client continuously monitors the default gateway's response. If the default gateway returns a specific communication layer or application layer error code, such as connection refused, gateway timeout, or service unavailable, the client determines that the default gateway is malfunctioning. The client can also check the default gateway's status using probes. Specifically, the client sends lightweight probe requests to specific checkpoints on the default gateway during the transfer interval, evaluating response latency and success rate to determine if the default gateway is functioning correctly. If the latency exceeds a threshold or multiple probes fail consecutively, the default gateway is considered malfunctioning.

[0057] When any client determines that the default gateway is in an abnormal state, it can report this state to the server, which will then synchronize the default gateway's state to other clients.

[0058] For example, when a teller at a branch uploads a customer's ID card image via a financial client, the client continuously monitors the default gateway's response during the intervals between image fragment transmissions. If a gateway timeout error code is received, the client immediately determines that the default gateway is malfunctioning. Alternatively, a built-in probe in the client checks the default gateway's operational status every 30 seconds. If three consecutive probes fail or the average response latency exceeds 500 milliseconds, the client determines that the default gateway is malfunctioning. Furthermore, if the client receives a maintenance instruction for the branch's default gateway from the bank's head office operations and management platform, it determines that the default gateway is malfunctioning. After determining that the default gateway is malfunctioning through any of the aforementioned methods, the client immediately activates disaster recovery methods, implementing breakpoint resumption through subsequent steps to ensure uninterrupted ID card image upload services.

[0059] Step S202: When the default gateway is in an abnormal operating state and the target file has not been completely transferred, record the progress information of the transferred file data and determine the available backup gateway.

[0060] When the client detects an abnormal operation of the default gateway and the target file has not yet been transferred, it first accurately records the file transfer progress information, such as the file slice sequence number and byte offset of successfully uploaded or downloaded files. For files transferred in segments, it records the sequence number of the last successfully transferred slice and its complete status. For example, in a file upload scenario, if slices numbered 1-5 have received a successful confirmation from the server, the progress information is recorded as uploaded to slice 5. For files transferred by byte range, it records the cumulative byte offset of successfully transferred data, such as 10240 bytes transferred. This progress information is usually stored in the client's memory in a lightweight data format to ensure it is not lost during gateway switching.

[0061] While recording progress, the client performs the operation of determining available backup gateways in parallel. A default gateway can have one or more backup gateways. If there are multiple backup gateways, any available backup gateway can be selected for subsequent file transfers, i.e., any available backup gateway can be selected as the target backup gateway.

[0062] When determining the target backup gateway, you can also send lightweight probe requests to each of the multiple backup gateways corresponding to the default gateway, and obtain the request responses from each backup gateway to test the availability and response latency of each alternative gateway. First, receive responses containing the health status of each backup gateway within a set time. Then, record the time from sending the probe request to receiving the first byte of the successful response, and filter out the available backup gateways, which are the target backup gateways. For example, determine the available backup gateway with the lowest response latency as the target backup gateway.

[0063] For a backup gateway, if the request response returned by the backup gateway indicates a successful connection establishment, a successful status code, and a response latency below a preset threshold, then the backup gateway is determined to be available. If the request response indicates a connection failure, a connection timeout, an error status code, or excessive latency, then the backup gateway is determined to be unavailable. If multiple available backup gateways exist, the available backup gateway with the lowest response latency can be selected as the target backup gateway to continue file transfer.

[0064] Step S203: Based on the progress information, continue transmitting the remaining file data of the target file through the backup gateway.

[0065] The client uses the recorded progress information to resume file transfer from the point of interruption via a backup gateway.

[0066] In a file upload scenario, the client determines the remaining unuploaded slices based on the sequence number of the last successfully uploaded slice in the progress information. The client then organizes the remaining slices in sequence, performs protocol adaptation, and encapsulates them into upload request messages for the target backup gateway. Following a pre-set concurrency limit for the target backup gateway, the client concurrently uploads these request messages to the file resource server. The file resource server parses and receives this slice data, then reassembles it in sequence with previously received slices according to their sequence numbers, forming a complete file.

[0067] In a file download scenario, the client calculates the data range of the remaining undownloaded segments based on the byte offsets successfully received in the progress information. The client generates a download request with the byte range for each remaining segment, which, after protocol adaptation, is sent through the target backup gateway. After receiving the corresponding segment data from the file resource server, the client precisely appends it to the end of the downloaded segments, assembling a complete file locally.

[0068] In web view resource loading scenarios, the progress information records a list of intercepted but unprocessed Uniform Resource Locators (URLs). The client can intercept a download request for a single URL and send it to a backup gateway, or it can trigger batch processing by setting a queue length threshold and a short delay for the first request. If the number of URLs in the queue quickly reaches the preset threshold, or if the first request enters the queue and experiences a short waiting window, the client initiates batch download requests for URLs and retrieves the resource files through the backup gateway. After the files are downloaded, the client does not directly hand them over to the web view; instead, it segments the file data and writes it into the resource pipeline for the web view kernel to read and render.

[0069] In the scenario of loading resources using a browsing tool, the progress information records the file slices that have been downloaded through the backup gateway. The client continues to download the remaining part of the file through the backup gateway. All file slices are then synthesized locally on the client to generate a local file path, which is then passed to the browsing tool, which directly opens the local file.

[0070] The file transfer disaster recovery method provided in this application detects the status of the default gateway during file transfer and automatically switches to an available backup gateway when an anomaly is detected. It also records the progress information of the transferred files to enable breakpoint resumption. Furthermore, it dynamically controls the concurrency based on the file transfer scenario type to avoid network congestion, ensuring seamless automatic switching and recovery of services when the default gateway fails or the network fluctuates. This achieves continuity and integrity of file transfer, effectively solving key problems in existing technologies such as gateway failure leading to transmission interruption, inefficient and error-prone manual switching, and the impact of high-concurrency transmission on network stability. It significantly improves the success rate of file transfer and system availability in high-reliability scenarios such as finance.

[0071] Before continuing to transmit the remaining file data of the target file through the backup gateway based on the progress information, it is also necessary to determine the concurrency level based on the file transfer scenario type of the target file. This concurrency level is used to control the number of transmission requests sent by the client to the backup gateway.

[0072] In file upload scenarios, due to the significant write load and storage input / output pressure on the backup gateway, the initial concurrency is set to a low value, such as 1 or 2. After setting the initial concurrency, the client can dynamically adjust it based on the upload success rate of the slice, response time, and the overall load status of the backup gateway cluster. Specifically, an initial concurrency value is set for each file transfer scenario type, and this initial value is then dynamically adjusted based on the upload success rate and response time of the first slice under the same file transfer scenario type, combined with the memory load threshold of the backup gateway cluster for that file transfer scenario type. An upper limit for the concurrency corresponding to each file transfer scenario type can be preset, and both the initial and upper limits of the concurrency can be positively correlated with the number of physical nodes in the backup gateway cluster for that file transfer scenario type.

[0073] In file download scenarios, the client dynamically determines concurrency by monitoring the bandwidth utilization of the backup gateway in real time and aiming to maintain it within an efficient range of 60% to 80%. First, the quotient of the target total concurrency and the average throughput per connection is calculated, and this value is used as the initial concurrency level. Then, during transmission, the actual bandwidth utilization is continuously sampled. If the bandwidth utilization remains below 60%, the concurrency is appropriately increased; if the bandwidth utilization remains above 80%, the concurrency is decreased.

[0074] In webpage view resource loading scenarios, the client intercepts and merges multiple Uniform Resource Locators for batch download. At this time, the concurrency depends on the request processing throughput capacity of the backup gateway. For example, the concurrency is determined to be 10% to 20% of the request processing throughput, and the total size of the resources downloaded in parallel is estimated to not exceed the memory buffer threshold of the gateway node to prevent memory overflow.

[0075] In resource loading scenarios using browsing tools, the real-time requirements for file transfer are relatively low, but the success rate requirement is extremely high. Typically, the concurrency level is set to 1, i.e., pure serial download, to ensure that each slice can be successfully transferred in a stable environment, avoiding timeout failures due to concurrent contention, which would affect the complete availability of the final file.

[0076] Since different scenarios place varying pressures and demands on the backup gateway, determining the concurrency level based on the target file transmission scenario type ensures a balance between transmission rate and success rate while avoiding overloading the backup gateway. By adopting differentiated concurrency strategies for four scenarios, backup gateway resources are effectively utilized for file transmission, achieving an optimal balance between business performance and stability.

[0077] Figure 3 Flowchart of the file upload disaster recovery method provided for this application Figure 2 In this embodiment Figure 3 Based on the embodiments, the file upload disaster recovery method is described in detail, such as... Figure 3 As shown, step S203 may specifically include the following steps:

[0078] Step S301: If the file transfer scenario type is file upload, then the concurrency is determined to be the first concurrency.

[0079] Step S302: Based on the protocol specifications of the backup gateway, the remaining slices are encapsulated into request messages.

[0080] The client invokes the built-in backup gateway protocol adaptation module, which, according to the predefined backup gateway protocol specifications, uses each remaining file slice of the target file as the payload and encapsulates it in a standardized manner according to a specific structure. First, a dedicated protocol header defining the message type, version, and slice sequence number is added to the payload. A security token for authentication and a request timestamp are then injected. Finally, the payload is compressed or encrypted and encapsulated into an upload request conforming to the backup gateway message syntax.

[0081] Step S303: In accordance with the first concurrency level and slice sequence number, the request messages of a corresponding number of remaining slices are uploaded to the file resource server in parallel through the backup gateway.

[0082] The client, based on the predetermined concurrency level (e.g., 2) for the upload scenario, retrieves the corresponding number of slices (2 slices) from the remaining slice queue of the target file in sequence. The client encapsulates these two slices and sends the encapsulated request messages in parallel to the backup gateway. The backup gateway receives the encapsulated request messages and forwards them to the file resource server. During this process, each time a slice is uploaded, the next slice is immediately retrieved from the remaining slice queue in sequence for encapsulation and transmission, maintaining the number of concurrent upload requests consistent with the predetermined concurrency level until all remaining slices have been transmitted.

[0083] Step S304: Receive the file storage success confirmation information or the file identifier of the target file returned by the file resource server.

[0084] After the backup gateway successfully sends all remaining slice request messages, the client receives a response from the file resource server confirming that the file has been successfully uploaded. This response is returned via the original transmission link where the backup gateway is located. The response content indicates that the file resource server has fully received all slices of the target file and has combined all slices into a complete file. The response also includes a unique file identifier storing file attributes.

[0085] The file upload disaster recovery method provided in this application detects the operating status of the default gateway during the file upload process and seamlessly switches to the transmission link where the backup gateway is located when the status is abnormal. By determining the first concurrency level under the file upload scenario type, and encapsulating the remaining slices into request messages according to the backup gateway protocol specification in sequence, the method uploads them in parallel, maximizing the utilization of the gateway transmission bandwidth while ensuring the order of slices. The client receives the unique file identifier returned by the file resource server, thus completing the upload process of the target file. This process not only ensures the seamless continuity and data integrity of file uploads when the gateway is abnormal, but also sends the remaining file slices to the file resource server through the backup gateway according to the first concurrency level, realizing automatic disaster recovery and efficient resume of file uploads, effectively improving the reliability and integrity of file uploads.

[0086] Figure 4 A schematic diagram illustrating the scenario of the file upload disaster recovery method provided in this application, such as... Figure 4 As shown, JS triggers a file upload command and transmits the file from the local path to the client. The client divides the target file into n slices according to a preset slice size. The client checks the current running status of the default gateway. If the default gateway is running normally, the download command is transmitted through the link where the default gateway is located (…). Figure 4 The download command is transmitted via the link corresponding to the solid line in the middle; if the default gateway is malfunctioning, the download command is transmitted via the link of the backup gateway (the link corresponding to the solid line in the middle). Figure 4 The transmission occurs via the link corresponding to the dashed line. The client then converts the Hypertext Transfer Protocol (HTTP) into an upload request message usable by the gateway and uploads file slices to the file application service according to the first concurrent request. The file application service sends the slice storage instruction to the file resource server, which sequentially reassembles all slices into a complete file, generates a file identifier storing the complete file attributes, and an upload result, which is then sent back to the client via a backup gateway. The client receives the file identifier and upload result and sends them to the JS layer for use in subsequent business processes.

[0087] Figure 5 A flowchart illustrating a file download disaster recovery method provided in this application. Figure 4 In this embodiment Figure 5 Based on the embodiments, the file download disaster recovery method is described in detail, such as... Figure 5 As shown, step S203 may specifically include the following steps:

[0088] Step S401: If the file transfer scenario type is file download, then the concurrency level is determined to be the second concurrency level.

[0089] Step S402: Based on the offset of the downloaded bytes in the progress information, determine the remaining undownloaded slices.

[0090] The client uses quasi-recorded progress information, which includes the cumulative byte offset of successfully received and verified data. By comparing the total size of the target file in bytes with the size of the preset slice in bytes, the client calculates the range of bytes in the undownloaded target file and divides this range into one or more remaining slices.

[0091] For example, if the total file size is 1MB, the downloaded offset is 300KB, and the slice size is 200KB, then the client will determine the remaining undownloaded target file byte range of 300KB-499KB as the 3rd slice, and the byte range of 500KB-699KB as the 4th slice.

[0092] Step S403: For each remaining slice, the download request format is converted based on the protocol specification of the backup gateway.

[0093] Based on the identified remaining slices, the client performs format conversion on the remaining slice download requests according to the pre-defined backup gateway protocol specifications. This involves converting the Hypertext Transfer Protocol (HTTP) download request, which includes the slice index, into a protocol format usable by the backup gateway. Specifically, this includes mapping the HTTP header information to command words and fields of the backup gateway's available protocol, encoding and serializing the download request parameters, or embedding the authentication token and signature information required by the backup gateway. This generates a standardized download request message that conforms to the backup gateway interface requirements, ensuring that the client can successfully initiate and retrieve the remaining slice data of the target file through the backup gateway.

[0094] In step S404, according to the second concurrency and slice sequence number, a set of format-converted download requests of a corresponding number are sent to the backup gateway in parallel, so as to receive the remaining slices returned by the file resource server through the backup gateway.

[0095] The client retrieves the corresponding number of remaining slice download requests from the queue of remaining slices to be downloaded, according to the second concurrency level and the remaining slice sequence number. All these download requests have undergone format conversion. The client encapsulates the remaining slice download requests and sends them in parallel to the backup gateway via the transmission link where the backup gateway is located. The backup gateway sends the remaining slice download requests to the file resource server, which then returns the corresponding remaining slice data based on the byte range information in the download requests. The client receives the remaining slice data returned by the backup gateway. During this process, after receiving complete data for each slice, the client immediately initiates the next slice download request from the queue in sequence, always maintaining the number of download requests simultaneously consistent with the second concurrency level, until all remaining slices are downloaded. This process ensures the orderly download of each remaining slice while effectively utilizing network bandwidth to achieve efficient and reliable breakpoint resumption.

[0096] For example, a file is 1MB in size, using a fixed slice size of 200KB. The first 400KB of the file, i.e., slice 1 and slice 2, has been successfully downloaded. After the client detects an anomaly in the default gateway, it records the file download progress offset as 400KB, determining that the remaining undownloaded slices are slice 3 and slice 4, with byte ranges of 400KB to 599KB and 600KB to 799KB, respectively. Based on the slice sequence number, the client retrieves slice 3 and slice 4 from the remaining queue according to the second concurrency level of 2, and sends the download requests for the two slices that have completed protocol conversion to the backup gateway.

[0097] Step S405: Merge the received remaining slices with the downloaded data of the target file to obtain the target file.

[0098] The client receives the remaining slice data of the target file through a backup gateway. The remaining slice data is in binary format. Based on the data information returned by each remaining slice, such as the byte range, the client writes the remaining slice data to the corresponding position in the local cache of the partially downloaded target file.

[0099] For example, if the first 400KB of the target file's slice data has been downloaded, and the newly received remaining slices 3 and 4 have ranges of 400KB to 599KB and 600KB to 799KB respectively, then slices 3 and 4 will be written to offsets of 400KB and 600KB in the target file, respectively, to fill the missing slice data ranges. During the writing process, the client needs to perform integrity checks to ensure the slice data is error-free, such as performing MD5 checksum verification. After all the slices of the target file are synthesized in order, the client obtains the target file locally.

[0100] The file download disaster recovery method provided in this application determines the remaining slices based on byte offsets and transmits the slices according to a second concurrency level, achieving fine-grained control over resource transmission. By converting file download requests into a protocol format usable by the backup gateway, protocol interoperability of the disaster recovery link is ensured. The remaining slices are downloaded in parallel according to the second concurrency level, effectively utilizing network bandwidth to improve download efficiency. The target file is obtained by the client synthesizing slices of the target file locally and performing integrity verification. This method not only ensures seamless continuity and data integrity of target file downloads when the gateway fails, but also balances download efficiency and success rate through protocol conversion and concurrency.

[0101] Figure 6 A schematic diagram illustrating the scenario of the file download disaster recovery method provided in this application, such as... Figure 6 As shown, JS triggers a file download command and passes the storage address of the target file on the file resource server to the client. The client checks the current running status of the default gateway. If the default gateway is running normally, the download command is sent through the link where the default gateway is located (…). Figure 6 The download command is transmitted via the link corresponding to the solid line in the middle; if the default gateway is malfunctioning, the download command is transmitted via the link of the backup gateway (the link corresponding to the solid line in the middle). Figure 6 The link corresponding to the dashed line in the middle is used for transmission. The client generates a download request containing the target file slice index information based on the target file's storage address on the file resource server, and converts it into a download request message usable by the gateway. According to the second concurrency level, the converted download request message is sent to the file application service through the gateway. The file application service transmits the slice download instruction to the file resource server. The file resource server then locates the target file based on the target file address and index information in the download request message, reads the corresponding slice data, and outputs a slice data message, returning it to the client through the original gateway's transmission link. The client parses the received slice data message, obtains the slices of the target file, and sequentially synthesizes all the received target file slices into a complete file in its local memory, such as... Figure 6 The generated target file is passed to the JS layer via ordered slices 1 to n.

[0102] Figure 7 A flowchart illustrating the disaster recovery method for loading webpage view resources provided in this application. Figure 6 In this embodiment Figure 7 Based on the embodiments, the disaster recovery method for loading webpage view page resources is described in detail, such as... Figure 7 As shown, step S203 may specifically include the following steps:

[0103] Step S501: If the file transfer scenario type is webpage view page resource loading type, then the concurrency is determined to be the third concurrency.

[0104] In step S502, the Uniform Resource Locator (URL) corresponding to the target file is intercepted through the request interception callback function. At the same time, a timer of preset duration is started, the intercepted URLs are added to the buffer queue, and a corresponding resource pipeline is established for each intercepted URL. The web page view kernel is suspended and waits for a response.

[0105] When the web view kernel triggers a web resource loading request, the client activates the callback function `shouldInterceptRequest`, which then intercepts the corresponding Uniform Resource Locator (URL). Simultaneously, the client performs three initialization operations: starting a timer with a preset period of 1 second, adding the intercepted URLs to a buffer queue, and establishing a corresponding resource pipeline for each intercepted URL. The timer can batch-merge intercepted URLs, reducing the concurrent pressure on the backup gateway and the scheduling overhead on the client. If a network download request were immediately initiated for each intercepted URL, it would create a sudden surge of pressure on the backup gateway and the client, easily leading to download request timeouts, download queue congestion, or client lag. The buffer queue temporarily stores intercepted resource loading requests, ensuring that the resources to be loaded can be retrieved completely and orderly when the timer expires. The resource pipeline is a cross-thread data channel between the client and the web view kernel, enabling secure and efficient cross-process data transfer and simulating native network loading. After initialization, the web view kernel suspends its current rendering thread due to the interception of resource loading requests and waits for a response.

[0106] Step S503: When the timer expires, determine the remaining file data of each Uniform Resource Locator based on the progress information corresponding to each Uniform Resource Locator in the buffer queue, and clear the buffer queue.

[0107] When the preset timer expires, the client batch processes the Uniform Resource Locators (URLs) temporarily stored in the buffer queue. This process first reads and copies all accumulated URLs awaiting loading in the current buffer queue, forming a task list. Then, the original buffer queue is cleared to receive the next batch of resource loading requests. For each URL in the task list, the client queries the local resource database to determine the data to be loaded. If it is a brand new URL or there is no valid URL, the complete target file data needs to be downloaded. If there is a complete cached file data that has not expired, it is reused without downloading, and the progress information records the range of data already acquired, thus determining the range of remaining file bytes to be downloaded. If there is partial cache or expired cache corresponding to the URL, the range of remaining file bytes to be downloaded is calculated based on the recorded offset of the last successful byte. After this process is completed, the buffer queue is immediately cleared to release the memory occupied by the buffer queue. Simultaneously, the timer is reset for the next interception cycle, and the used resource pipelines are marked as scheduled to await the return of loaded resource data.

[0108] Step S504: Based on the protocol specifications of the backup gateway, perform format conversion on the download requests for the remaining file data of each Uniform Resource Locator.

[0109] For each Uniform Resource Locator (URL) and its corresponding remaining file data range in the task list, the client performs format conversion and encapsulation of the download request according to the protocol specifications available to the backup gateway. This protocol conversion process includes mapping the request method, URL, byte range, and other Hypertext Transfer Protocol (HTTP) parameters to command words and field structures of protocols available to the backup gateway, encoding and serializing resource download request parameters, or embedding authentication tokens and signature information required by the backup gateway. This generates a standardized download request message that conforms to the backup gateway interface requirements for each resource in the list, ensuring that all target file data can be obtained in batches through the backup gateway.

[0110] Step S505: The download request is transmitted in parallel to the backup gateway according to the third concurrency level, so as to receive the file slices corresponding to each Uniform Resource Locator returned by the file resource server through the backup gateway, and combine the slices into a complete file to obtain the target file corresponding to each Uniform Resource Locator.

[0111] The client sends the format-converted download requests in parallel to the backup gateway according to the third concurrency level. The backup gateway then forwards the download requests to the file resource server. The file resource server, based on the segment data corresponding to the byte range in the download request, sends it back to the client through the backup gateway. The client receives the segment data in parallel according to the third concurrency level and reassembles it in order, combining it into multiple target files in its local memory.

[0112] Step S506: Re-segment each target file according to the byte stream order, and write the data of each re-segmented slice to the write end of the corresponding resource pipeline in parallel.

[0113] The client re-shards each synthesized target file in byte-stream order with smaller, fixed-size segments, for example, 100KB. Then, a high-performance thread pool is enabled to write the re-sharded data in parallel to the write end of the resource pipeline corresponding to the Uniform Resource Locator (URL) according to a third concurrency level.

[0114] Step S507: Read slice data sequentially from the read end of each resource pipeline via the webpage view kernel, and render the read slice data as a network response to the page.

[0115] The suspended and waiting web view kernel reads the slice data one by one from the read end of each of its mounted resource pipelines, in the order in which the data arrives. The web view kernel assembles the read byte data into a continuous byte stream and constructs it as a network response, which is then handed over to the rendering engine for parsing and rendering. This process makes the web view kernel believe that the slice data was loaded normally from the Uniform Resource Locator, thus seamlessly rendering resources such as images and style sheets onto the page.

[0116] Step S508: After all the data corresponding to any Uniform Resource Locator has been read and rendered by the webpage view kernel, release the resource pipeline corresponding to the Uniform Resource Locator.

[0117] The client continuously monitors the status of each resource pipeline. When it detects that the web view kernel has completely read all slice data from the resource pipeline corresponding to the Uniform Resource Locator, and that the slice data has been rendered on the page, the client immediately performs a pipeline release operation, closing the file descriptors at both ends of the pipeline, releasing the associated memory buffers, and removing the pipeline record from the internal management table.

[0118] The webpage view page resource loading disaster recovery method provided in this application utilizes request interception, resource pipeline establishment, and timer setting to merge high-frequency and scattered resource requests into batch tasks, reducing the instantaneous pressure on the client and backup gateway. By establishing a dedicated pipeline for each resource and re-sharding it according to the byte stream and writing it in parallel according to a third concurrency level, the method improves transmission efficiency while ensuring data order. This method not only guarantees the continuity and smoothness of page resource loading when the gateway fails, but also effectively avoids page lag or blank screens, improving the rendering success rate of complex business pages and user experience.

[0119] Figure 8 A schematic diagram illustrating the scenario of the disaster recovery method for loading webpage view resources provided in this application, as shown below. Figure 8As shown, the client checks the current running status of the default gateway. If the default gateway is running normally, download commands are sent through the link where the default gateway is located (…). Figure 8 The download command is transmitted via the link corresponding to the solid line in the middle; if the default gateway is malfunctioning, the download command is transmitted via the link of the backup gateway (the link corresponding to the solid line in the middle). Figure 8 Transmission is performed via the link corresponding to the dashed line. When the default gateway fails, the client intercepts multiple Uniform Resource Locators (URLs) via the `shouldInterceptRequest` callback function, starts a timer, adds the URLs to a buffer queue, and establishes a resource pipeline for each URL. At this point, the web view kernel suspends and waits. When the timer expires, the client retrieves URLs from the queue in batches, determines the range of data to be downloaded based on their progress information, and converts the target file download requests according to the protocol specifications of the backup gateway. Subsequently, the client sends download requests in parallel to the backup gateway at a third concurrency level to obtain sliced ​​data, and synthesizes the received sliced ​​data into multiple target files locally. For the synthesized target files, the client further segments each file into byte streams and writes them in parallel to the corresponding resource pipeline read end using a thread pool, so that the web view kernel can sequentially read data from the pipeline write end and render it. After the resources are loaded and rendered, the client releases the corresponding resource pipeline, thus achieving seamless and smooth disaster recovery loading of page resources when the default gateway fails.

[0120] Figure 9 A flowchart illustrating the disaster recovery method for loading browsing tool resources provided in this application. Figure 8 In this embodiment Figure 9 Based on the embodiments, the disaster recovery method for loading browsing tool resources is described in detail, such as... Figure 9 As shown, step S203 may specifically include the following steps:

[0121] Step S601: If the file transfer scenario type is browsing tool resource loading type, then the concurrency is determined to be the fourth concurrency.

[0122] Step S602: Based on the offset of the downloaded bytes in the progress information, determine the remaining undownloaded slices.

[0123] Based on the recorded precise progress information, namely the cumulative byte offset of the target file that has been successfully downloaded and verified, the client calculates the range of data that has not yet been transmitted by comparing the total file size with the preset slice size, and divides this range into one or more logical remaining slices.

[0124] For example, if the total file size is 5MB, the slice size is 1MB, and the downloaded offset is 2.3MB, the client will determine the range of bytes for the remaining undownloaded portion. The third slice is 2MB to 2.999MB, of which the incomplete portion is 2.3MB to 2.999MB; the fourth and fifth slices are 3MB to 3.999MB and 4MB to 4.999MB, respectively.

[0125] Step S603: For each remaining slice, based on the protocol specifications of the backup gateway, the download requests corresponding to the remaining slices are formatted.

[0126] The client performs format conversion on the Hypertext Transfer Protocol (HTTP) download requests for each remaining slice according to the protocol specifications available to the backup gateway. This HTTP includes information such as methods, Uniform Resource Locators (URLs), and headers. Specifically, the client maps the HTTP to the command words and field structures of the protocols available to the backup gateway, encodes and serializes the download request parameters, or embeds the authentication tokens and signature information required by the backup gateway, thereby generating a standardized download request message that conforms to the backup gateway interface requirements.

[0127] Step S604: According to the fourth concurrency and slice order, a set of format-converted download requests of a corresponding number are sent to the backup gateway in parallel, so as to receive the remaining slices returned by the file resource server through the backup gateway.

[0128] The client, based on the fourth concurrency level determined by the resource loading scenario of the browsing tool, retrieves the corresponding number of slices from the remaining slice queue to be downloaded, in sequence according to their slice numbers. The client then sends the format-converted download request message to the backup gateway, which forwards the download request to the file resource server. The file resource server returns the corresponding slice data based on the byte range information in the download request, and then returns it to the client again through the backup gateway. During this process, whenever the client successfully receives and verifies the data of a slice, it immediately retrieves the next slice from the queue in sequence and initiates a new download request, always maintaining the number of concurrent download requests consistent with the fourth concurrency level, until all remaining slices have been transmitted.

[0129] Step S605: Merge the received remaining file slices with the downloaded data of the target file to obtain the target file, store it locally on the client, and generate a local file path.

[0130] The client successfully receives all remaining slice data through the backup gateway. Based on the byte range information returned for each slice, it writes all slice data to the corresponding position in the local cache of the partially downloaded target file. Newly received slice data then fills in subsequent byte gaps according to the offset. The client performs an MD5 check on the synthesized complete file for integrity verification. The client stores the verified complete file locally and generates a local file path.

[0131] Step S606: Pass the local file path to the browsing tool so that the browsing tool can load and render the corresponding resources based on the local path.

[0132] The client securely passes the generated local file path to the designated browsing tool, such as WPS or the system photo album, through the inter-application call mechanism provided by the operating system, such as Intent in Android or Document Interaction in Apple. After receiving this local path, the browsing tool does not attempt to initiate any network requests, but directly accesses the file pointed to by the path based on the local file system protocol, loads the file content, and performs parsing and rendering.

[0133] Step S607: After the browsing tool confirms that the resource has been fully loaded, release the local cached resources corresponding to the target file.

[0134] The client determines whether the browsing tool has been successfully opened and fully rendered by detecting callbacks from the browsing tool, file handle releases, or user-initiated closures. After ensuring file rendering is complete, the local cache is released. This release includes deleting the target file temporarily stored for this disaster recovery transfer, cleaning up temporary data for associated target file slices, and updating the local resource database to remove the cached record for that file.

[0135] The resource loading disaster recovery method for browsing tools provided in this application embodiment ensures that only missing data is continued and significantly improves transmission efficiency by pre-setting a fourth concurrency level and locating remaining slices based on precise byte offsets. By dynamically adapting the Hypertext Transfer Protocol request to a backup gateway protocol format, the interoperability of the disaster recovery link is guaranteed. Finally, the client generates a local path for the downloaded and synthesized file and passes it to the browsing tool, ensuring that local resources are loaded directly in unstable network environments, achieving seamless continuity of file viewing services in gateway anomaly scenarios. This method not only ensures business continuity and user experience but also maintains local memory through a timely cache cleanup mechanism.

[0136] Figure 10 A schematic diagram illustrating the scenario of the disaster recovery method for loading browsing tool resources provided in this application, such as... Figure 10 As shown, the client checks the current running status of the default gateway. If the default gateway is running normally, download commands are sent through the link where the default gateway is located (…). Figure 10 The download command is transmitted via the link corresponding to the solid line in the middle; if the default gateway is malfunctioning, the download command is transmitted via the link of the backup gateway (the link corresponding to the solid line in the middle). Figure 10 The client transmits data via the link corresponding to the dashed line in the progress information. The client determines the remaining slices based on the downloaded byte offset and converts the download request format according to the protocol specifications available to the backup gateway. Then, the client sends download requests in parallel to the backup gateway according to the fourth concurrency level to obtain the remaining slice data. The client receives the remaining slices returned by the backup gateway and merges them with the already downloaded partial slices into the target file, while simultaneously generating an accessible local file path. Finally, the client securely passes the local path to the designated browsing tool, which directly loads and renders the local file based on this path. Once the browsing tool confirms that the file loading is complete, the client clears the corresponding local cache resources and sends the browsing results to the JS layer.

[0137] In accordance with the file transfer disaster recovery method provided in the foregoing embodiments, this application also provides a file transfer disaster recovery device. Figure 11 A schematic diagram of the file transfer disaster recovery device provided in this application is shown below. Figure 11 As shown, the file transfer disaster recovery device provided in this embodiment includes:

[0138] The status detection module 1110 is used to detect the running status of the default gateway during the transmission of the target file through the default gateway; the exception handling module 1120 is used to record the progress information of the transmitted file data and determine the available backup gateway when the running status of the default gateway is abnormal and the target file has not been completely transmitted; the resume execution module 1140 is used to continue transmitting the remaining file data of the target file through the backup gateway based on the progress information.

[0139] In one possible implementation, the status detection module 1110 is specifically used for: collecting the response latency and connection success rate of the default gateway; receiving the status configuration of the default gateway issued by the server based on the user account dimension or the network node dimension; and determining the operating status of the default gateway based on the response latency and connection success rate of the default gateway and the status configuration of the default gateway.

[0140] In one possible implementation, the device further includes a concurrency determination module 1130, configured to: determine the concurrency based on the file transfer scenario type of the target file before continuing to transmit the remaining file data of the target file through the backup gateway based on the progress information, so as to continue transmitting the remaining file data of the target file through the backup gateway under concurrency control; the concurrency is used to control the number of transmission requests sent by the client to the backup gateway.

[0141] In one possible implementation, the resume execution module 1140 is specifically used for: if the file transfer scenario type is file upload, determining the remaining unuploaded slices based on the sequence number of the uploaded slices in the progress information; encapsulating the remaining slices into request messages based on the protocol specification of the backup gateway; and uploading a set of request messages for the corresponding number of remaining slices in parallel through the backup gateway according to the concurrency and slice sequence number, so that the file resource server can reassemble the parsed remaining slices into a complete file according to the slice sequence number; and receiving the file storage success confirmation information or the file identifier of the target file returned by the file resource server.

[0142] In one possible implementation, the resume execution module 1140 is specifically used for: if the file transfer scenario type is file download, determining the remaining undownloaded slices based on the offset of the downloaded bytes in the progress information; for each remaining slice, performing format conversion on the download requests of the remaining slices based on the protocol specifications of the backup gateway; sending a set of format-converted download requests of a corresponding number in parallel to the backup gateway according to the concurrency and slice sequence number, so as to receive the remaining slices returned by the file resource server through the backup gateway; and merging the received remaining slices with the downloaded data of the target file to obtain the target file.

[0143] In one possible implementation, the resume execution module 1140 is specifically used for: if the file transfer scenario type is a webpage view page resource loading type, then intercepting the Uniform Resource Locator (URI) corresponding to the target file through a request interception callback function, simultaneously starting a timer of preset duration, adding the intercepted URIs to a buffer queue, and establishing a corresponding resource pipeline for each intercepted URI; the webpage view kernel suspends and waits for a response; when the timer expires, determining the remaining file data for each URI based on the progress information corresponding to each URI in the buffer queue, and clearing the buffer queue; based on the protocol specifications of the backup gateway, downloading the remaining file data for each URI... The process involves: format conversion; parallel transmission of download requests to a backup gateway based on concurrency; receiving file slices corresponding to each Uniform Resource Locator (URI) returned by the file resource server through the backup gateway; merging the slices into a complete file to obtain the target file corresponding to each URI; re-fragmenting each target file according to the byte stream order; writing the re-fragmented slice data in parallel to the write end of the corresponding resource pipeline; sequentially reading the slice data from the read end of each resource pipeline via the web view kernel; rendering the read slice data as a network response to the page; and releasing the resource pipeline corresponding to any URI after all data has been read and rendered by the web view kernel.

[0144] In one possible implementation, the resume execution module 1140 is specifically used for: if the file transfer scenario type is a browsing tool resource loading type, determining the remaining undownloaded slices based on the offset of the downloaded bytes in the progress information; for each remaining slice, performing format conversion on the download requests corresponding to the remaining slices based on the protocol specifications of the backup gateway; sending a set of format-converted download requests of a corresponding number in parallel to the backup gateway according to the concurrency and slice order, so as to receive the remaining slices returned by the file resource server through the backup gateway; merging the received remaining file slices with the downloaded data of the target file to obtain the target file, storing it locally on the client and generating a local file path; passing the local file path to the browsing tool so that the browsing tool can load and render the corresponding resources based on the local path; and releasing the local cached resources corresponding to the target file after the browsing tool confirms that the resources have been fully loaded.

[0145] The file transfer disaster recovery device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0146] Figure 12 A schematic diagram of the file transfer disaster recovery device provided in this application. Figure 12 As shown, the electronic device 120 provided in this embodiment includes at least one processor 1201 and a memory 1202. Optionally, the device 120 further includes a communication component 1203. The processor 1201, the memory 1202, and the communication component 1203 are connected via a bus 1204.

[0147] In a specific implementation, at least one processor 1201 executes computer execution instructions stored in memory 1202, causing at least one processor 1201 to perform the above-described method.

[0148] The specific implementation process of processor 1201 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0149] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0150] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0151] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0152] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0153] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0154] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0155] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0156] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0157] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0158] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0159] If a function is implemented as 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 this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0160] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0161] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A file transfer disaster recovery method, characterized in that, Applied to a client, the method includes: During the transmission of the target file through the default gateway, the running status of the default gateway is detected; If the default gateway is in an abnormal operating state and the target file has not been completely transmitted, record the progress information of the transmitted file data and determine the available backup gateway. Based on the progress information, the remaining file data of the target file continues to be transmitted through the backup gateway.

2. The method according to claim 1, characterized in that, Before continuing to transmit the remaining file data of the target file through the backup gateway based on the progress information, the method further includes: Determine the concurrency level based on the file transfer scenario type of the target file; The step of continuing to transmit the remaining file data of the target file through the backup gateway based on the progress information includes: Based on the progress information and under the concurrency control, the remaining file data of the target file continues to be transmitted through the backup gateway.

3. The method according to claim 2, characterized in that, The file transfer scenario type is a file upload type. The step of continuing to transfer the remaining file data of the target file through the backup gateway based on the progress information under the concurrency control includes: Based on the sequence number of the uploaded slice in the progress information, the remaining slices that have not been uploaded are determined; Based on the protocol specifications of the backup gateway, the remaining slices are encapsulated into request messages; According to the concurrency and slice sequence number, a set of request messages for the remaining slices of a corresponding number are uploaded to the file resource server through the backup gateway in parallel, so that the file resource server can reassemble the parsed remaining slices into a complete file according to the slice sequence number. Receive a file storage success confirmation message or the file identifier of the target file returned by the file resource server.

4. The method according to claim 2, characterized in that, The file transfer scenario type is a file download type. The step of continuing to transfer the remaining file data of the target file through the backup gateway based on the progress information under the concurrency control includes: Based on the offset of the downloaded bytes in the progress information, determine the remaining undownloaded slices; For each remaining slice, the download request for the remaining slice is format-converted based on the protocol specification of the backup gateway; According to the concurrency and slice sequence number, a corresponding number of format-converted download requests are sent in parallel to the backup gateway so as to receive the remaining slices returned by the file resource server through the backup gateway. The received remaining slices are merged with the downloaded data of the target file to obtain the target file.

5. The method according to claim 2, characterized in that, The file transfer scenario type is a webpage view page resource loading type. The step of continuing to transfer the remaining file data of the target file through the backup gateway based on the progress information under the concurrency control includes: The system intercepts the Uniform Resource Locator (URL) corresponding to the target file by requesting the interception callback function. At the same time, it starts a timer of preset duration, adds the intercepted URLs to the buffer queue, and establishes a corresponding resource pipeline for each intercepted URL. The web page view kernel is suspended and waits for a response. When the timer expires, the remaining file data of each Uniform Resource Locator is determined according to the progress information corresponding to each Uniform Resource Locator in the buffer queue, and the buffer queue is cleared. Based on the protocol specifications of the backup gateway, the download requests for the remaining file data of each Uniform Resource Locator are format-converted; The download requests are transmitted in parallel to the backup gateway according to the concurrency level, so as to receive the file slices corresponding to each of the Uniform Resource Locators returned by the file resource server through the backup gateway, and combine the slices into a complete file to obtain the target file corresponding to each of the Uniform Resource Locators; Each target file is re-sharded according to the byte stream order, and the data of each re-sharded slice is written in parallel to the write end of the corresponding resource pipeline. The slice data is read sequentially from the read end of each resource pipeline via the webpage view kernel, and the read slice data is rendered to the page as a network response; Once all data corresponding to any of the Uniform Resource Locators has been read and rendered by the webpage view kernel, the resource pipeline corresponding to the Uniform Resource Locator is released.

6. The method according to claim 2, characterized in that, The file transfer scenario type is a browsing tool resource loading type. The step of continuing to transfer the remaining file data of the target file through the backup gateway based on the progress information under the concurrency control includes: Based on the offset of the downloaded bytes in the progress information, determine the remaining undownloaded slices; For each remaining slice, the download request corresponding to the remaining slice is format-converted based on the protocol specification of the backup gateway; According to the concurrency and slice order, a corresponding number of format-converted download requests are sent in parallel to the backup gateway so as to receive the remaining slices returned by the file resource server through the backup gateway; The received remaining file slices are merged with the downloaded data of the target file to obtain the target file, which is then stored locally on the client and a local file path is generated. The local file path is passed to the browsing tool so that the browsing tool can load and render the corresponding resources based on the local file path; Once the browsing tool confirms that the resource has been fully loaded, it releases the local cached resources corresponding to the target file.

7. The method according to any one of claims 1-6, characterized in that, The detection of the operating status of the default gateway includes: Collect the response latency and connection success rate of the default gateway; The receiving server issues the status configuration of the default gateway based on the user account or the branch office. The operating status of the default gateway is determined based on its response latency and connection success rate, as well as its status configuration.

8. A file transfer disaster recovery device, characterized in that, include: The status detection module is used to detect the running status of the default gateway during the transmission of the target file through the default gateway; An exception handling module is used to record the progress information of the transmitted file data and determine the available backup gateway when the default gateway is in an abnormal operating state and the target file has not been completely transmitted. The resume transmission module is used to continue transmitting the remaining file data of the target file through the backup gateway based on the progress information.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

Images