Method and device for uploading software package to target server, equipment and medium

Abstract

The invention discloses a method, a device, equipment and a medium for uploading a software package to a target server, and is applied to the technical field of software engineering and operation and maintenance, the method is applied to a client, the client has Internet access authority, and the target server is deployed in a secure network area which cannot directly access the Internet. Comprising the following steps: acquiring a network resource address of a software package from a software package source website; downloading a data stream of the software package in a stream mode according to the network resource address; in the transmission process of the data stream, the data stream is divided into a plurality of continuous data blocks, and each data block is stored as a temporary file; in response to the detected temporary file, uploading the temporary file to a target server; and controlling the target server to merge the plurality of temporary files into a software package in response to the fact that all the data blocks of the data stream are downloaded and the temporary files corresponding to all the data blocks are uploaded to the target server. The efficiency of deploying the software package to the target server can be improved.

Description

TECHNICAL FIELD

[0001] The present application belongs to the field of software engineering and operation and maintenance technology, and particularly relates to a method and device for uploading a software package to a target server, equipment and a medium. BACKGROUND

[0002] In the life cycle of software development and operation and maintenance, it is a routine operation to frequently download a software package and deploy it to a target server such as a test or production server. The most ideal way is to directly download on the target server, but network isolation, security policies and authentication barriers in the production environment usually make the target server unable to directly access external repositories.

[0003] Therefore, a compromise serial solution is currently widely used: first, download the software package completely on a local client with access permission, and then upload the entire file to the target server. Although this solution avoids access restrictions, its inherent serial blocking mode results in long overall transmission time, and the local needs to cache a complete file copy, consuming a large amount of storage resources.

[0004] In summary, the current method of deploying a software package to a server has the problems of low efficiency and occupying storage resources. SUMMARY

[0005] The embodiments of the present application provide a method, device, equipment and computer storage medium for uploading a software package to a target server, which can upload the software package to the target server while downloading the software package, reduce the waiting time, and improve the efficiency of deploying the software package to the target server.

[0006] In a first aspect, the embodiments of the present application provide a method for uploading a software package to a target server, applied to a client, the client has internet access permission, and the target server is deployed in a secure network area that cannot directly access the internet, and the method comprises: obtaining a network resource address of a software package from a software package source website; downloading a data stream of the software package in a streaming mode according to the network resource address; In the transmission process of the data stream, the data stream is divided into a plurality of continuous data blocks, and each data block is stored as a temporary file; In response to detecting the temporary file, the temporary file is uploaded to the target server; In response to all data blocks of the data stream being downloaded and all temporary files corresponding to the data blocks being uploaded to the target server, the target server is controlled to merge a plurality of temporary files into the software package.

[0007] In a second aspect, the embodiments of the present application provide a device for uploading a software package to a target server, applied to a client, the client having an internet access right, and the target server being deployed in a secure network area which cannot directly access a software package source website, the device comprising: an acquisition module, configured to acquire a network resource address of the software package from the software package source website; a download module, configured to download a data stream of the software package in a streaming mode according to the network resource address; a splitting module, configured to split the data stream into a plurality of continuous data blocks during transmission of the data stream, and store each data block as a temporary file; an upload module, configured to upload the temporary file to the target server in response to detecting the temporary file; a control module, configured to control the target server to combine the plurality of temporary files into the software package in response to all data blocks of the data stream being downloaded and all temporary files corresponding to the data blocks being uploaded to the target server.

[0008] In a third aspect, the embodiments of the present application provide an electronic device, comprising a processor and a memory storing computer program instructions; the processor implements the method for uploading a software package to a target server according to any one of the above aspects when executing the computer program instructions.

[0009] a processor and a memory storing computer program instructions; the processor implements the method for uploading a software package to a target server according to any one of the above aspects when executing the computer program instructions.

[0010] In a fourth aspect, the embodiments of the present application provide a computer storage medium, the computer readable storage medium storing computer program instructions, the computer program instructions being executed by a processor to implement the method for uploading a software package to a target server according to any one of the above aspects.

[0011] In a fifth aspect, the embodiments of the present application provide a computer program product, the instructions in the computer program product being executed by a processor of an electronic device to enable the electronic device to execute the method for uploading a software package to a target server according to any one of the above aspects.

[0012] The method, device, equipment and medium for uploading a software package to a target server provided by the embodiments of the present application can download a data stream of the software package in a streaming mode according to the network resource address, split the data stream into a plurality of continuous data blocks during the transmission of the data stream, and store each data block as a temporary file; in response to detecting the temporary file, the temporary file is uploaded to the target server, which can upload the software package to the target server while downloading the software package, reduces the waiting time, and improves the efficiency of deploying the software package to the target server. BRIEF DESCRIPTION OF DRAWINGS

[0013] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required to be used in the embodiments of the present application will be briefly introduced below. Those skilled in the art can also obtain other drawings according to these drawings without creative labor.

[0014] Figure 1 is a network architecture schematic diagram of an application scenario of the method for uploading a software package to a target server provided by the embodiments of the present application; Figure 2 is a flowchart of the method for uploading a software package to a target server provided by an embodiment of the present application; Figure 3 is a structural schematic diagram of the device for uploading a software package to a target server provided by another embodiment of the present application; Figure 4 is a structural schematic diagram of an electronic device provided by another embodiment of the present application. DETAILED DESCRIPTION

[0015] The features and exemplary embodiments of various aspects of the present application will be described in detail below, in order to make the purposes, technical solutions and advantages of the present application more clear and apparent, the present application will be further described in detail below in combination with the drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present application, but not to limit the present application. The present application can be implemented without some of these specific details by those skilled in the art. The following description of the embodiments is only to provide a better understanding of the present application by showing examples of the present application.

[0016] It is to be noted that, in the present document, relational terms such as first and second and the like can be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises", "comprising", or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises... a" does not, without more constraints, exclude the presence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0017] It should be noted that the acquisition, storage, use and processing of data in the embodiments of the present application comply with the relevant provisions of national laws and regulations.

[0018] It should be noted that in the embodiments of the present application, some software, components, models and other industry existing solutions may be mentioned, which should be considered as exemplary, and the purpose is only to illustrate the feasibility of the implementation of the technical solutions of the present application, but it does not mean that the applicant has or will necessarily use the solution.

[0019] First, the background technology involved in the present application is introduced.

[0020] In the life cycle of software development and operation, it is a basic and frequent operation to frequently download software packages such as container engine Docker image, Python.whl file, Java.jar package, NPM module, system dependency package, and deploy them to the target server such as test or production. The most ideal deployment method is to directly execute the download command on the target server, thereby avoiding unnecessary data transfer. However, due to the complex enterprise network architecture and security policy, this ideal solution is not feasible in most production environments, and the specific reasons are as follows.

[0021] First, the test or production server is usually located in the isolated network area behind the firewall, such as DMZ or internal subnet, and cannot directly access the Internet or specific external resource library. Conversely, the jump machine or development machine that can access the external network does not have a production environment for deploying software.

[0022] Second, downloading some software packages needs to carry authentication information bound to a specific user session, such as small data fragments Cookies and Tokens. These authentication information exists in the browser environment of the developer, and it is difficult to safely and reliably migrate to the remote production server.

[0023] Third, many software source sites use anti-crawler mechanisms or generate download links dynamically through JavaScript, which makes it extremely difficult or even impossible to download directly on the server side through simple command-line tools such as wget or curl.

[0024] Due to the above three reasons, the currently commonly used solution is to download the target software package completely on the local client with access permission, and then upload the complete software package to the target server again through file transfer tools such as SCP, SFTP, etc. for deployment after the download task is completed. Although this solution bypasses the network and authentication barriers, it has the following two problems. First, the overall transmission time is long, and the complete software package needs to be downloaded to the local client and then uploaded to the target server. Second, during the transmission process, the local client needs to store the complete copy of the entire software package, which consumes a large amount of storage resources for large software packages or edge devices with limited storage space.

[0025] To solve the above technical problems, the embodiments of the present application provide a method, device, equipment and medium for uploading a software package to a target server.

[0026] The network architecture of the method for uploading a software package to a target server provided by the embodiments of the present application is introduced as follows.

[0027] Figure 1 is a network architecture diagram of an application scenario of the method for uploading a software package to a target server provided by the embodiments of the present application. As shown in Figure 1 In an application scenario of the method for uploading a software package to a target server provided by the embodiments of the present application, it includes a client 11, a target server 12 and a software package source website 13. Among them, the client 11 has Internet 14 access permission, and the target server 12 is deployed in a secure network area 15 that cannot directly access the Internet 14. The secure network area 15 only allows connections from specific IP segments, such as the client's IP. The client 11 can upload data to the target server 12 or control the target server 12 by initiating a connection to the target server 12's preset port. The software package source website 13 is located in the Internet 14, so the target server 12 cannot directly access the software package source website 13.

[0028] The client 11 obtains the network resource address of the software package from the software package source website 13.

[0029] The client 11 downloads the data stream of the software package in a streaming mode according to the network resource address.

[0030] The client 11 divides the data stream into multiple continuous data blocks during the transmission process of the data stream, and stores each data block as a temporary file.

[0031] The client 11 uploads the temporary files to the target server 12 in response to detecting the temporary files.

[0032] The client 11 controls the target server 12 to merge the plurality of temporary files into the software package in response to all data blocks of the data stream being downloaded and all temporary files corresponding to the data blocks being uploaded to the target server 12.

[0033] The method for uploading the software package to the target server provided by the embodiment of the present application is described below.

[0034] Figure 2 is a flow diagram of the method for uploading the software package to the target server provided by an embodiment of the present application. As shown in Figure 2 The method for uploading the software package to the target server provided by the embodiment of the present application is applied to a client, the client has an internet access right, the target server is deployed in a secure network area that cannot directly access the internet, and the method for uploading the software package to the target server provided by the embodiment of the present application can include steps 201 to 205.

[0035] Step 201, obtaining a network resource address of the software package from a software package source website.

[0036] The network resource address refers to a uniform resource locator (URL) that can directly trigger the download of the binary data of the software package. The network resource address can be a URL generated dynamically by a source server where the software package is located after a user initiates a download request, and the URL contains a one-time authentication token or a session identifier.

[0037] In some embodiments, if the network resource address of the software package is directly displayed in the webpage corresponding to the software package source website, the client can directly obtain the network resource address of the software package from the webpage corresponding to the software package source website.

[0038] In some embodiments, the client can use a preset browser automation program, such as a script based on the DrissionPage library, to simulate user click operations in the webpage of the software package source website and initiate a software package download request to the source server corresponding to the software package source website. Subsequently, the browser automation program can intercept the response of the source server to the software package download request and parse the network resource address of the software package from the response information, such as the HTTP redirection header or the response body. After obtaining the network resource address of the software package, the browser automation program can cancel the download of the software package by the browser.

[0039] Step 202, downloading a data stream of the software package in a streaming mode according to the network resource address.

[0040] The stream mode is a network data transmission mode. In the stream mode, after the client establishes a connection with the source server where the software package is located, the source server continuously sends data of the software package, and the client can process the received data fragments without waiting for the data transmission to be completed.

[0041] A preset download management program, such as a download thread written based on the Python-based requests library, can be used in the client. The download management program uses the network resource address of the software package obtained in step 201 as a target, and initiates an HTTP GET request to the source server corresponding to the software package source website. By setting the stream mode parameter for the request, the download management program establishes and maintains a transmission session between the client and the source server, thereby starting to continuously receive the data stream containing the content of the software package from the source server.

[0042] In step 203, the data stream is divided into a plurality of continuous data blocks during the transmission of the data stream, and each data block is stored as a temporary file.

[0043] The data block refers to an independent data unit logically or physically divided from the continuous data stream. For example, a 100 MB data stream is divided according to a size of 4 MB, and 25 data blocks of 4 MB can be obtained.

[0044] The temporary file refers to a short-term storage file created on the local file system of the client for storing a single data block.

[0045] The client can use a block processing program to store the arriving byte data in the memory buffer for accumulation while receiving the data stream. When the amount of accumulated byte data reaches the predefined data block size, the block processing program can write all byte data in the current buffer as a complete data block to the file system of the operating system of the client, and store it as an independent temporary file. This process is repeated, thereby converting the complete data stream into a series of sequentially generated data block files stored locally during transmission. The block processing program can be the same thread as the download management program in step 202.

[0046] In step 204, in response to detecting the temporary file, the temporary file is uploaded to the target server.

[0047] The client can employ an independent upload monitoring program, such as a background thread dedicated to monitoring the file system, to continuously detect the temporary files generated by step 203. Whenever the upload monitoring program detects a new, complete temporary file, it invokes a file transfer client tool, such as the command line program of WinSCP, to upload the temporary file to the specified storage path of the target server via a secure file transfer protocol. In some embodiments, the upload monitoring program can delete the temporary file locally after the temporary file is successfully uploaded and verified.

[0048] Step 205, in response to all data chunks of the data stream being downloaded and all temporary files corresponding to the data chunks being uploaded to the target server, the target server is controlled to merge the multiple temporary files into a software package.

[0049] When all data chunks corresponding to the software package are completed to be downloaded, and all temporary files corresponding to the data chunks are uploaded to the target server via step 204, the client can employ a preset process control program, such as a control program based on the Paramiko library, to connect to the target server via a secure shell protocol (SSH) and send a preset merging command to the target server. The merging command can control the target server to sequentially splice and merge all temporary files corresponding to the data chunks in the file system of the target server, and finally restore a complete software package consistent with the source file.

[0050] In some embodiments, after the client controls the target server to sequentially splice and merge all temporary files corresponding to the data chunks into a software package, the client can further control the target server to delete the temporary files corresponding to the data chunks, thereby reducing the consumption of storage resources of the target server.

[0051] The method for uploading a software package to a target server provided by the embodiments of the present application can download a data stream of the software package in a streaming mode according to a network resource address, split the data stream into multiple continuous data chunks during the transmission of the data stream, and store each data chunk as a temporary file; in response to detecting the temporary file, the temporary file is uploaded to the target server, which can upload the software package to the target server at the same time as downloading the software package, reduce the waiting time, and improve the efficiency of deploying the software package to the target server.

[0052] In some embodiments, in order to quickly obtain the network resource address of the software package, step 201 further includes steps 301 to 302.

[0053] Step 301, simulating a user operation of triggering a software package download request in a webpage corresponding to a software package source website.

[0054] At step 302, the software package download response sent by the source server corresponding to the software package source website is received, and the network resource address is obtained from the software package download response.

[0055] In some embodiments, the browser automation program of the client simulates the software package download interaction behavior of a real human user in the webpage of the software package source website by executing code instructions, such as clicking the download button or link on the webpage, thereby triggering the complete process of the software package source website backend generating and issuing the software package download response.

[0056] The software package download response refers to the HTTP response returned by the source server corresponding to the software package source website after the browser automation program simulates user operation. This response is usually not the software package file itself, but a message containing instructions or information on how to obtain the file. The core form is usually an HTTP 302 or HTTP 307 redirection response, or JSON / HTML data containing dynamically generated download links in the response body.

[0057] The client can receive the software package download response sent by the source server corresponding to the software package source website, and then obtain the network resource address of the software package from the software package download response.

[0058] The method for uploading the software package to the target server provided by the embodiments of the present application can quickly and accurately obtain the network resource address of the software package by simulating the user operation of triggering the software package download request in the webpage corresponding to the software package source website, receiving the software package download response sent by the source server corresponding to the software package source website, and obtaining the network resource address from the software package download response. In addition, for the case of needing to download multiple software packages, the network resource addresses of the multiple software packages can also be quickly obtained.

[0059] In some embodiments, in order to stably and quickly upload the software package to the target server, step 203 is refined to include steps 401 to 402.

[0060] At step 401, real-time network status parameters are obtained, including at least one of the following: network delay, data packet loss rate, and bandwidth.

[0061] The real-time network status parameters are a set of quantitative indicators that measure and reflect the quality and performance of the current network communication link in real time during the software package download and upload process of the client. The network delay can be the uplink network delay, that is, the time required for the data packet to be sent from the client to the target server and returned, usually in milliseconds.

[0062] The data packet loss rate can be an uplink data packet loss rate, i.e., a percentage of data packets lost in a data transmission process between the client and the target server to a total number of sent packets, which is a key indicator for measuring network stability and reliability.

[0063] The bandwidth can be an uplink bandwidth, i.e., an actual available data transmission rate of an upload link from the client to the target server. The bandwidth determines a potential maximum throughput of data transmission, and a unit is usually megabits per second.

[0064] The client can periodically or triggeredly perform a probing task by using a preset network state monitoring program to obtain real-time network state parameters. The network state monitoring program can send an ICMP Ping packet or a specific TCP probe packet to the target server, obtain a delay by calculating a round-trip time of the data packet, and obtain a packet loss rate by counting a loss proportion of the probe packet. The network state monitoring program uploads a test data block with a known size to the target server, and obtains the uplink bandwidth by measuring a time consumption.

[0065] Step 402: dynamically adjusting a size of each data block according to the real-time network state parameters.

[0066] The client can dynamically calculate a size of a next data block by using a preset adaptive block decision program according to the real-time network state parameters obtained in step 401. Exemplarily, the preset adaptive block decision program can be configured with a preset data block size range. The preset adaptive block decision program can calculate a real-time network quality score according to the network delay, the data packet loss rate, and the bandwidth. The real-time network quality score is negatively correlated with the network delay and the data packet loss rate, and is positively correlated with the bandwidth. Then, the preset adaptive block decision program can determine the size of the next data block from the preset data block size range according to the real-time network quality score. For example, the size b of the next data block can be represented as: b = R L +(R H -R L )×(Q T / Q0), where b represents the size of the next data block, R L represents a lower limit of the preset data block size range, R H represents an upper limit of the preset data block size range, Q T represents the real-time network quality score, and Q0 represents a preset network quality score.

[0067] Exemplarily, assuming that the client downloads a software package from a source server corresponding to a software package source website and uploads the software package to a target server, the initial block size is 4MB, after a period of transmission, the network state monitoring program measures that the uplink bandwidth to the target server decreases from 50Mbps to 5Mbps, the network delay increases from 30ms to 200ms, and the packet loss rate increases to 0.5%, then the size of the next data block can be determined as 1.5MB according to the bandwidth, the network delay and the packet loss rate, so as to complete the single uploading task faster, reduce the amount of retransmitted data caused by failure when the network is unstable, and improve the overall reliability.

[0068] The method for uploading a software package to a target server provided by the embodiments of the present application can continuously perceive the change of the network state and dynamically adjust the size of the data block according to the real-time network state parameter, so as to automatically increase the block size to reduce the protocol interaction overhead and maximize the use of available bandwidth when the network condition is good, and automatically reduce the block size to reduce the risk of single transmission failure and the retransmission cost when the network condition is poor, so as to maintain a stable and reliable transmission rate, and balance the transmission rate and the transmission reliability.

[0069] In some embodiments, in order to further improve the uploading efficiency, the step 402 is refined to include steps 501 to 503.

[0070] The step 501 comprises calculating a real-time network quality score according to the real-time network state parameter; the real-time network quality score is negatively correlated with the network delay and the data packet loss rate, and is positively correlated with the bandwidth.

[0071] The step 502 comprises, in response to the network quality score being greater than a first preset score threshold, gradually increasing the size of each subsequent data block by a first preset data amount until the size of the data block reaches a preset upper limit, the network quality score is less than the first preset score threshold or a data block uploading failure is detected.

[0072] The step 503 comprises, in response to the network quality score being less than a second preset score threshold, gradually reducing the size of each subsequent data block by a second preset data amount until the size of the data block reaches a preset lower limit, the network quality score is greater than the second preset score threshold; the second preset score threshold is less than the first preset score threshold.

[0073] The first preset score threshold and the second preset score threshold are two preset key score boundary values, the second preset score threshold is less than the first preset score threshold, and the continuous network quality is divided into three decision intervals as follows: less than the second preset score threshold, from the second preset score threshold to the first preset score threshold, and greater than the first preset score threshold. Greater than the first preset score threshold represents excellent network quality, and less than the second preset score threshold represents poor network quality. The interval from the second preset score threshold to the first preset score threshold represents an ordinary or acceptable stable zone of network quality.

[0074] The preset upper limit refers to a maximum allowed value of a preset single data block size in a transmission process, for example, 10 MB, 16 MB, etc. Regardless of how high the network quality score is, the size of the finally generated data block should not exceed this value.

[0075] The preset lower limit refers to a minimum allowed value of a preset single data block size in a transmission process, for example, 256 KB, 512 KB. Regardless of how low the network quality score is, the size of the finally generated data block should not be lower than this value.

[0076] The step-by-step increase refers to an incremental increase by a first preset data amount each time.

[0077] The step-by-step decrease refers to a step-by-step decrease by a second preset data amount each time.

[0078] In some embodiments, the client can periodically obtain the latest real-time network state parameters by using a network quality evaluation program, and substitute them into a score function. For example, the evaluation function can be in the form of: Q t = w1B - w2τ - w3ε, where Q t represents a real-time network quality score, w1, w2, and w3 represent positive weights preset according to experience, for balancing the influence of each real-time network state on the real-time network quality score, B represents bandwidth, τ represents network delay, and ε represents network packet loss rate.

[0079] When the real-time network quality score is greater than the first preset score threshold, it indicates that the network quality is continuously good and has the potential to carry larger data chunks to reduce the protocol overhead. At this time, the size of the next data chunk to be generated is increased by a first preset data amount based on the size of the previous data chunk, such as 256 KB, 512 KB, or 1 MB. This process continues, and the size of the data chunk is increased step by step until the network quality score drops below the first threshold, or a temporary file upload corresponding to a certain increased data chunk fails, indicating that the size of the current data chunk may reach the boundary of the current network stability. Therefore, the size of the next data chunk to be generated is no longer increased. In addition, when a temporary file upload corresponding to a certain increased data chunk fails, the size of the next data chunk to be generated can also be reduced by a first preset data amount to ensure transmission stability.

[0080] When the real-time network quality score is less than the second preset score threshold, it indicates that the network quality is poor or unstable. At this time, the size of the next data chunk is reduced by a second preset data amount based on the size of the previous data chunk, such as 256 KB, 512 KB, or 1 MB. This process continues, and the size of the data chunk is decreased step by step until the network quality score rises above the second threshold to ensure transmission stability.

[0081] When the real-time network quality score is between the second preset score threshold and the first preset score threshold, the current chunk size is maintained to ensure transmission stability.

[0082] Exemplarily, the first preset score threshold is 80 points, the second preset score threshold is 40 points, the first preset data amount is 256 KB, the second preset data amount is 512 KB, and the current chunk size is 2 MB.

[0083] Firstly, when the real-time network quality score is detected to be 65 points, which is between the second preset score threshold and the first preset score threshold, the size of the next data chunk is still 2 MB.

[0084] Secondly, when the real-time network quality score is detected to be 85 points, which is greater than the first preset score threshold, indicating that the network state is good, the size of the next data chunk is adjusted to 2 MB + 256 KB = 2.25 MB. If the real-time network quality score continues to be higher than 80 points, the size of the subsequent data chunk will continue to increase to 2.5 MB, 2.75 MB, …, until the size of the data chunk reaches a preset upper limit, the real-time network quality score is less than the first preset score threshold, or a data chunk upload fails.

[0085] In the third case, when the real-time network quality score is detected as 35, which is less than the second preset score threshold, indicating that the network state is poor, the size of the next data chunk is adjusted to 2MB - 512KB = 1.5MB, and if the real-time network quality score continues to be less than 40, the size of the subsequent data chunk will continue to decrease to 1MB, 512KB, …, until the size of the data chunk reaches the preset lower limit, and the real-time network quality score is greater than the second preset score threshold.

[0086] The method for uploading the software package to the target server provided by the embodiments of the present application can increase the size of the data chunk when the network state is good by increasing the size of each subsequent data chunk by the first preset data amount step by step in response to the network quality score being greater than the first preset score threshold, thereby increasing the size of the temporary file corresponding to the data chunk, improving the efficiency of uploading the software package to the target server, and can reduce the size of the data chunk when the network state is poor by reducing the size of each subsequent data chunk by the second preset data amount step by step in response to the network quality score being less than the second preset score threshold, thereby reducing the size of the temporary file corresponding to the data chunk, avoiding the data packet from being stuck or failing to transmit during the transmission process, improving the stability of the data transmission, and enabling the software package to be efficiently and reliably uploaded to the target server.

[0087] In some embodiments, in order to further save the storage resources of the client, step 204 further includes: determining whether to delete the temporary file after the temporary file is uploaded to the target server.

[0088] After the temporary file is uploaded to the target server, the client can receive a successful confirmation from the target server or a file transmission protocol such as SFTP / SCP, for example, a successful status code or a verification response, and thus the client can determine whether the temporary file is uploaded to the target server.

[0089] After the client calls the upload command, such as the put command of WinSCP, the client can synchronously or asynchronously wait and check the return state of the command, and when the return state explicitly indicates success, for example, the process exit code is 0, or a successful confirmation is parsed from the protocol response, it is determined that the temporary file is uploaded to the target server. Further, the client can call the file deletion API provided by the programming language, such as using os.remove(file_path) in Python, and input the complete path of the temporary file to perform a deletion operation to delete the temporary file stored in the client, thereby saving the storage resources of the client.

[0090] The method for uploading the software package to the target server provided by the embodiments of the present application can reduce the storage resource consumption of the client by deleting the temporary file after determining that the temporary file is uploaded to the target server, thereby improving the overall throughput and resource utilization of the software package deployment.

[0091] In some embodiments, in order to ensure that the software package can be deployed on the target server, after step 205, steps 701 to 705 are further included.

[0092] Step 701: obtaining a first integrity check code of the software package from a software package source website.

[0093] Step 702: obtaining a second integrity check code of the software package combined by the plurality of data blocks from the target server.

[0094] Step 703: determining whether the second integrity check code is the same as the first integrity check code.

[0095] Step 704: if it is determined that the second integrity check code is the same as the first integrity check code, determining that the software package is complete.

[0096] Step 705: if it is determined that the second integrity check code is different from the first integrity check code, determining that the software package is incomplete.

[0097] The first integrity check code refers to a digital fingerprint directly associated with the original software package file provided by the software package source website without any transmission, which represents the standard state of the software package. The first integrity check code can be a cryptographic hash value, such as SHA-256, MD5.

[0098] The second integrity check code refers to a digital fingerprint calculated by the same hash algorithm from the file generated by combining all the uploaded data blocks on the target server, which represents the actual state of the software package on the target server after the download, block, upload, and combination processes.

[0099] The client can obtain the first integrity check code at the same time of obtaining the network resource address of the software package.

[0100] After the target server combines the plurality of temporary files into the software package, the client can send a command for calculating the second integrity check code of the software package to the target server through the SSH connection, so that the target server calculates the second integrity check code from the software package synthesized by the plurality of temporary files and sends it to the client. After receiving the second integrity check code sent by the target server, the client compares the second integrity check code with the first integrity check code, for example, compares whether the two integrity check codes are the same bit by bit.

[0101] If it is determined that the second integrity check code is the same as the first integrity check code, it indicates that no data error is introduced in the entire transmission process, and the merged software package is an accurate copy of the source file provided by the software package source website, and the software package can be deployed on the target server.

[0102] If it is determined that the second integrity check code is different from the first integrity check code, it indicates that there is at least one bit error in the entire transmission process, and the merged software package is damaged or inconsistent with the source file provided by the software package source website, and the software package cannot be deployed on the target server. At this time, the software package can be downloaded from the software package source website again and uploaded to the target server.

[0103] The target server has more computing power than the client. Calculating the second integrity check code on the target server does not require the use of the client's computing resources, and the second integrity check code of the software package can be quickly calculated.

[0104] The method for uploading the software package to the target server provided by the embodiments of the present application can determine whether the software package uploaded to the target server is consistent with the source file published by the software package source website by determining whether the second integrity check code is the same as the first integrity check code, ensuring that the correct software package is deployed on the target server, and avoiding problems such as deploying damaged software on the target server, resulting in inconsistent services and data.

[0105] In some embodiments, the client establishes a secure connection with the target server by calling a command line tool or an SSH library. The client uploads the temporary file to the target server through the file transfer protocol SFTP or SCP.

[0106] In some embodiments, during the transmission of the data stream, the client can record the download state and the upload state of each data block; when the transmission of the data stream is restarted after interruption, the client can skip the data blocks with successful upload states and continue to perform download and upload from the next data block with an unfinished upload state.

[0107] In some embodiments, in order to improve the reliability and automatic processing capability of the file transmission process, after step 204, steps 801 to 803 are further included.

[0108] Step 801: Monitor the transmission state of each data block during the transmission process.

[0109] Step 802: In response to monitoring that the transmission state of the data block is abnormal, performing abnormal type identification according to the real-time transmission state parameter to determine the current abnormal type corresponding to the data block.

[0110] Step 803, determining a target recovery operation matching the current abnormal type from a plurality of preset recovery operations, and executing the target recovery operation.

[0111] This embodiment takes a software package transmission task with a size of 1 GB as an example for illustration. The software package is split into 10 continuous data blocks for transmission. The client continuously monitors the transmission status of each data block during the transmission of each data block. Specifically, the monitoring program of the client polls the generation progress of the temporary file corresponding to each data block and the status code returned after uploading each temporary file by calling the file transmission tool. For example, the monitoring program monitors the uploading process of the temporary file corresponding to the 5th data block. When the file transmission tool does not return a successful status code within the preset 30 seconds, the monitoring program determines that the transmission status of the 5th data block is abnormal.

[0112] When the monitoring program detects that the transmission status of a certain data block is abnormal, the abnormality recognition program of the client starts immediately. The abnormality recognition program first collects the current real-time transmission status parameters, which include but are not limited to: the serial number of the data block where the abnormality occurs, the percentage progress of the data block that has been transmitted, such as 100%, indicating that the download is completed but the upload fails, the current network delay between the client and the target server, such as 350 milliseconds, and the current processor load of the target server, such as 70%.

[0113] Then, the abnormality recognition program inputs these real-time transmission status parameters into a preset trained abnormal type recognition model. The trained abnormal type recognition model is obtained by using a large number of historical abnormal state types and their corresponding historical transmission status parameters as training samples through machine learning algorithm training. After analyzing the input parameters, the model outputs a recognition result, i.e. the current abnormal type of the data block. For example, the model may output that the current abnormal type is "single data block upload timeout".

[0114] After determining the current abnormal type, the strategy execution program of the client starts to work. The strategy execution program maintains a strategy library containing a plurality of preset recovery operations, each recovery operation being associated with one or more abnormal types. According to the determined current abnormal type "single data block upload timeout", the strategy execution program performs matching in the strategy library to determine the target recovery operation corresponding thereto. For example, the matched target recovery operation is "performing retry upload on the abnormal data block". Then, the strategy execution program executes the target recovery operation, i.e. re-calling the file transmission tool to attempt to upload the local temporary file corresponding to the 5th data block to the target server again without interrupting the transmission process of other data blocks.

[0115] The method for uploading a software package to a target server provided by the embodiments of the present application can automatically and accurately handle partial failures occurring in a transmission process, and can refine the problem handling granularity from an entire file to a single data block, thereby avoiding resource waste caused by restarting of a whole large file transmission task due to transient failure of a certain data block, and significantly improving robustness, success rate and overall efficiency of the transmission task.

[0116] In some embodiments, in order to accurately identify the abnormal type, step 802 comprises: inputting the real-time transmission state parameter into a preset trained abnormal type identification model, and outputting the current abnormal type by using the trained abnormal type identification model, wherein the trained abnormal type identification model is obtained by training a historical abnormal state type and a corresponding historical transmission state parameter.

[0117] Specifically, the client collects various abnormal events encountered in the file transmission process in the history and the environment information at that time, and arranges each abnormal event and the environment information thereof as a structured record. The environment information, referred to as a feature in the embodiment, includes but is not limited to: a serial number of a data block being processed at the time of the abnormal event, a transmission progress of the data block, a network delay between the local and the target server, a processor load of the target server, and a type of the client operating system. A result label is manually annotated for each record, which contains two parts of information: the first part is a specific abnormal event type, for example, "single data block upload timeout"; and the second part is an influence range of the abnormal event, for example, "single data block abnormality" or "continuous multiple data block abnormality".

[0118] Next, the client can train a preset abnormal type identification model by using the feature information in all records as input and the result label annotated in the record as expected output, to obtain a trained abnormal type identification model. The trained abnormal type identification model can predict the abnormal type and the influence range according to real-time features. The preset abnormal type identification model can be a decision tree model.

[0119] When the formal file transmission task is started, the client loads the trained abnormal type identification model and the preset recovery operation corresponding to different abnormal types into the memory. When each data block is transmitted, the client monitors the download and upload process of the data block. Once it is monitored that the transmission progress of a certain data block stagnates for more than a predetermined time, or an error status code returned by the file transmission tool is received, it is determined that an abnormal event is triggered. After the abnormal event is triggered, the client collects various feature information at the current time, such as a serial number of a data block involved in the current abnormality, a percentage of the data block that has been transmitted, a currently measured network delay value, and the like.

[0120] Then, the collected feature information is input into the trained abnormal type recognition model, the trained abnormal type recognition model is used to analyze and calculate the feature information, and an abnormal type of the current abnormal event and an influence range thereof are output, for example, an output conclusion is "abnormal type: data block uploading timeout; influence range: single data block abnormality".

[0121] Subsequently, the client can find a recovery operation corresponding to the current abnormal type in preset recovery operations corresponding to different abnormal types, and execute the recovery operation.

[0122] For example, if the current abnormal type is "single data block uploading timeout", a recovery operation that can be executed is that a re-uploading request is initiated to the target server only for the current data block that fails to upload, without affecting other data blocks that have been successfully uploaded or are being transmitted.

[0123] For another example, if the current abnormal type is "continuous multiple data block uploading timeout" and the influence range is determined to be "continuous multiple data block abnormality", a recovery operation that can be executed is to automatically switch the uploading target of subsequent data blocks to a backup target server to bypass possible current server or network link problems.

[0124] When the client executes the specified recovery operation, whether the operation is successful or not, a complete processing flow of the current abnormal event, including the features when the abnormal event is triggered, the abnormal type, the executed recovery operation and the final result, can be recorded in a detailed log file. The log file can be used for subsequent analysis of the stability of the transmission state. If the recovery operation successfully solves the problem, the file transmission task will continue to be executed from the interrupted data block, realizing seamless resuming. If the recovery operation fails to solve the problem, for example, the same data block fails more than three times, the recovery operation can be upgraded according to a preset strategy, for example, the entire transmission task is suspended and a system administrator is notified for manual intervention.

[0125] The method for uploading a software package to a target server provided by the embodiment of the present application can accurately identify the abnormal type of the data block with abnormal transmission state by training the preset abnormal type recognition model using the historical abnormal state type and the corresponding historical transmission state parameter.

[0126] In some embodiments, the typical exception types in the file transfer scenario can be first identified as the "labels" for model training. Combined with the characteristics of shard transfer, a new "shard transfer exception" category is added, which is subdivided into single shard download timeout, shard upload failure, shard file damage, shard sequence number conflict, temporary file read-write conflict, etc. Subtypes, and the original "upload timeout, permission error" and other exceptions are integrated into ten categories. Through enumeration, the classification standard is unified to avoid manual annotation confusion. At the same time, for the characteristics of shards, "shard association labels" are supplemented to distinguish whether the exception is a "single shard problem" or a "common problem for all shards", providing a basis for accurate self-healing. At the same time, 12 lightweight core features are designed, supplemented by shard-specific features on the basis of the original, taking into account information integrity and extraction efficiency, covering key dimensions related to exceptions, and the feature details are as follows: exception_type: enumerated value, corresponding to the above six exception types, manually mapped and labeled by the developer according to the captured exception information; server_ip: string, representing the IP address of the target remote server, which can be directly read from the configuration file of the transfer task; file_size: numerical value, unit: MB, representing the size of the file to be transferred, which can be calculated by reading the local file attributes, and 0 if the file does not exist; network_delay: numerical value, unit: ms, representing the network delay between the client and the target server, which can be calculated by executing the ping command and taking the average value; server_load: numerical value, unit: %, representing the CPU load of the target server, which can be obtained by remotely executing the "top-b -n1" command and parsing the results; os_type: numerical value, representing the client operating system type, which can be automatically identified by system interface; retry_count: numerical value, representing the number of retries of the previous task, which can be recorded in real time by the built-in counter of the program; error_code: numerical value, representing the error status code returned by WinSCP or requests library, which can be directly extracted from the exception information, and 0 if there is no specific code value; shard_index: numerical value, representing the current processing of small temporary file sequence number, such as 3 for the 3rd piece, which can be automatically generated and marked by the shard management module; shard_size: numerical value, unit: MB, representing the fixed size of a single temporary file, such as 100MB, which can be read from the task configuration; shard_progress: numerical value, unit %, represents the download / upload progress of the current shard, such as 50% for downloading 50%, which can be calculated by the number of bytes streamed; temp_file_status: numerical value, represents the status of the small temporary file, such as 0 = downloading, 1 = downloading completed and uploading, 2 = uploading, 3 = uploading completed, which can be synchronized in real time by the file system status.

[0127] In the shard download phase, the progress is monitored in real time by counting the number of bytes streamed, and if the download progress of a certain shard stagnates for more than a threshold value, such as 10 seconds without growth, an exception is triggered; in the shard upload phase, WinSCP returns a status code for the upload result of a single shard, based on which the upload exception is captured. After the exception is triggered, the feature extraction process is immediately started: in addition to the original 8 types of features, additional information such as shard number, progress, and temporary file status is collected, and all features and exception descriptions, such as "the 5th shard upload timeout, current progress 100%", are integrated into a JSON format structured log.

[0128] In addition to the original timestamp, exception type and other information, the log content adds fields such as "shard index" "temporary file path" "number of completed shards / total number of shards", and is output to the local log file and console at the same time. For example, when the 3rd shard has a download timeout and the progress is only 30%, the system will record "exception_type=shard download timeout" "shard_index=3" "shard_progress=30" "network_delay=350ms" and other information, clearly presenting the shard-level context of the exception, providing data support for the model to learn the rules of exception types.

[0129] First, use data processing tools such as Python's pandas library to read the structured log file and convert JSON format data into a data table DataFrame; then select 10 numerical features, including new features such as shard number and shard progress, as model input, and use exception type and shard association label as joint output, where "shard association label" is divided into "single shard exception", "continuous shard exception" and "all shard exception", which are used to distinguish the scope of the exception. For missing values in the data, such as shard progress not recorded, use the "same class mean filling" strategy, such as filling with the average progress of other shards in the same task, which is more realistic than simply filling with 0. Finally, divide the processed data set into training set and test set in the ratio of 8:2, the training set is used for model learning, and the test set is used for evaluating the performance of the model, the division process uses random sampling method to avoid data distribution bias affecting the model effect.

[0130] The decision tree is selected as the core model because its reasoning process is transparent and the computing overhead is small. The reasoning time for a single data is controllable within 10 ms, which fully adapts to the real-time transmission scenario. During training, the "shard feature weight" is optimized. By adjusting the priority of the decision tree split node, the shard number, shard progress, and temporary file status are given higher weights, and the model is trained to learn the rules of "frequent abnormalities in a certain shard number" and "low progress shards prone to timeout". At the same time, the depth of the decision tree is limited to 5 to avoid overfitting, and the random seed is fixed to ensure the reproducibility of the training results.

[0131] After the model training is completed, the "accuracy + abnormal influence range identification accuracy" double indicators are used for evaluation, requiring the basic abnormal type accuracy to be ≥90% and the shard association label identification accuracy to be ≥95%. If the standard is not met, additional "shard transmission abnormality" special samples are used for optimization, such as simulating different shard number timeout scenarios, refining feature dimensions, and adding "shard download time" features. The model after reaching the standard is saved in file format, such as.pkl, for easy loading and calling in real-time abnormal type identification.

[0132] When the file transmission task starts, the saved decision tree model and shard configuration parameters, such as shard size and total shard number, are loaded into memory, and the "shard state manager" is initialized to record the download / upload status of each shard. During the transmission process, the abnormal capture mechanism is sunk to the shard level, and each small temporary file's download phase, i.e., the streaming write phase, and upload phase, i.e., the WinSCP call phase, are monitored separately. Once an abnormality is triggered in a shard, the "original core features + shard-specific features" are extracted to build a feature matrix, which is input into the model to output "abnormal type + shard association label" double results, such as "abnormal type = shard upload timeout, shard association label = single shard abnormality".

[0133] To improve diagnostic accuracy, the feature extraction logic is completely aligned with the training phase. For example, "shard_progress" is calculated in real-time by the number of bytes written to the temporary file and the total size of the shard, and "temp_file_status" is obtained by detecting the file suffix (such as ".tmp" for downloading and ".ready" for uploading). At the same time, "shard abnormality association analysis" is added: if the current shard is abnormal, the system automatically queries the historical shard abnormality records under the same task, and if more than 3 consecutive shards have the same type of abnormality, the "continuous shard marker" is added as an additional feature to the diagnostic process to help the model correct the judgment. For example, from "single shard abnormality" to "continuous shard abnormality".

[0134] The following will introduce the recovery operations for different abnormal types.

[0135] For the exception type of single slice download / upload timeout, the task can be resumed without interruption, and the retry is performed only for the slice. For example, if the download timeout occurs, the slice is resumed from the breakpoint, and if the upload timeout occurs, the WinSCP upload of the downloaded temporary file is re-invoked. The slice number and exception time are recorded, and if the retry of the same slice number fails more than twice, it is marked as a "high-risk slice" and the network delay detection is triggered to confirm whether it is a local network problem. For the exception type of continuous slice, such as slices 5-7, it can be determined that it is caused by high load of the target server or network link fluctuation. Therefore, "slice-level server switching" can be performed, that is, starting from the next unprocessed slice, the backup server is switched to upload, and the successfully uploaded slices do not need to be repeated. The slice number of the exception period is recorded in the "risk slice log" to provide a basis for subsequent optimization of slice transmission order. For the exception type of slice file damage, such as hash inconsistency, the temporary file corresponding to the slice can be directly deleted, and the "directed re-downloading" mechanism is triggered to re-download only the damaged slice instead of the entire file. After the download is completed, the integrity is confirmed by MD5 check, and then the upload is performed. For the exception type of temporary file read-write conflict, such as multiple threads operating on the same slice, the "slice lock mechanism" can be started to add exclusive lock to the temporary file of the currently operated slice, and other threads wait for the lock to be released before execution. At the same time, the temporary file naming rule is optimized, such as "file name_slice number_timestamp.tmp", to avoid conflicts from the source. For the exception type of all slice initialization failures, it can be determined that it is caused by core configuration or server basic problems. Therefore, the overall strategy is executed, that is, the slice size configuration is checked for reasonableness, the connectivity test is performed on the primary and backup servers, and the problem is repaired to restart the slice generation and transmission process of the entire task. For the unknown exception type, the bottom-up mechanism is started, that is, the current slice transmission is immediately suspended, the temporary file and slice state data are preserved, and the alarm notification is triggered for manual intervention to avoid resource waste caused by invalid self-healing.

[0136] The recovery operation of different exception types supports dynamic expansion, and the corresponding recovery operation can be added according to the newly added exception type, such as "slice merging failure".

[0137] In some embodiments, when the exception type matches multiple recovery operations at the same time, the recovery operations can be executed in order according to the priority of different recovery operations, such as in the order of "slice-level repair→task-level adjustment→manual intervention", to ensure that resources are used for local problem repair first.

[0138] In some embodiments, after the transmission task is started, the large file data stream is first split into multiple small shards according to a preset shard size, each shard is assigned a unique serial number and a temporary file is generated; then the shard download is started in sequence according to the serial number, and after the completion of each shard download, it is immediately marked as "to be uploaded" and triggers WinSCP upload, while the download of the next shard is started in parallel. If an exception occurs in a shard, such as download timeout, the system will trigger abnormal data collection, abnormal type identification, and perform corresponding recovery actions, such as retrying the shard, and after the completion of the recovery action, the subsequent transmission process continues from the shard. The successfully completed shards do not need to be processed repeatedly. A "shard retry counter" can be built into the client, with a maximum of 3 retries per shard, and a "overall task timeout threshold". If multiple self-healing failures occur in a single shard or the overall task times out, detailed logs are recorded and the task is terminated to ensure that resources are not occupied indefinitely.

[0139] For example, a 1GB large file is split into 10 100MB shards for transmission, and the 4th shard is uploaded to 192.168.1.100, which times out. The system will automatically collect features such as "shard_index=4" "shard_progress=100%" "network_delay=400ms", identify the abnormal type as "single shard upload timeout", and then only retry the upload of the 4th shard. If the retry fails, switch to the backup server 192.168.1.101 to upload the shard, and the 1-3 and 5-10 shards completed are not affected, and the overall task does not need to be interrupted, greatly improving the transmission efficiency.

[0140] The method provided by the embodiments of the present application has short model reasoning time and low resource occupation, and can be deployed on various terminals or servers without the support of high-performance hardware such as GPU; the abnormal type and recovery action are both supported for extension, which can quickly adapt to new transmission scenarios, such as adding FTP protocol transmission, and the shard characteristics make it more suitable for large file scenarios; it has traceability, because the whole process is logged, including abnormal features, abnormal type identification results, recovery operations, and other information, and the shard-level log can accurately locate the problem node; shard-level exception handling avoids "all stop for one mistake", and single shard self-healing does not affect the overall task, and the resource utilization rate is improved by more than 40%; the shard-specific features and model optimization improve the accuracy of abnormal diagnosis, especially for local abnormal identification in large file transmission.

[0141] Based on the method of uploading a software package to a target server provided in the above embodiments, the present application also provides a specific implementation mode of an apparatus for uploading a software package to a target server. Please refer to the following embodiments.

[0142] Figure 3 is a structural schematic diagram of an apparatus for uploading a software package to a target server provided by another embodiment of the present application. Please refer to Figure 3The device 30 for uploading a software package to a target server provided by the embodiments of the present application is applied to a client, the client has internet access permission, the target server is deployed in a secure network area which cannot directly access a software package source website, and the device 30 for uploading a software package to a target server comprises: an acquisition module 31 configured to acquire a network resource address of the software package from the software package source website; a download module 32 configured to download a data stream of the software package in a streaming mode according to the network resource address; a segmentation module 33 configured to segment the data stream into a plurality of continuous data blocks during transmission of the data stream, and store each data block as a temporary file; an upload module 34 configured to upload the temporary file to the target server in response to detection of the temporary file; a control module 35 configured to control the target server to combine the plurality of temporary files into the software package in response to all data blocks of the data stream being downloaded and all temporary files corresponding to the data blocks being uploaded to the target server.

[0143] In some possible implementation manners, the acquisition module 31 is specifically configured to: simulate a user operation of triggering a software package download request in a webpage corresponding to the software package source website; receive a software package download response sent by a source server corresponding to the software package source website, and acquire the network resource address from the software package download response.

[0144] In some possible implementation manners, the segmentation module 33 is specifically configured to: acquire real-time network state parameters, the real-time network state parameters comprising at least one of the following: network delay, data packet loss rate, bandwidth; dynamically adjust the size of each data block according to the real-time network state parameters.

[0145] In some possible implementation manners, the segmentation module 33 is specifically further configured to: calculate a real-time network quality score according to the real-time network state parameters; the real-time network quality score is negatively correlated with the network delay and the data packet loss rate, and is positively correlated with the bandwidth; in response to the network quality score being greater than a first preset score threshold, gradually increase the size of each subsequent data block by a first preset data amount until the size of the data block reaches a preset upper limit, the network quality score is less than the first preset score threshold, or detection of a data block upload failure; In response to the network quality score being less than a second preset score threshold, the size of each subsequent data block is gradually reduced according to a second preset data amount until the size of the data block reaches a preset lower limit or the network quality score is greater than the second preset score threshold; the second preset score threshold is less than the first preset score threshold.

[0146] In some possible implementation manners, the apparatus 30 for uploading the software package to the target server further comprises a deletion module configured to: delete the temporary file after the temporary file is uploaded to the target server.

[0147] In some possible implementation manners, the apparatus 30 for uploading the software package to the target server further comprises a verification module configured to: obtain a first integrity verification code of the software package from the software package source website; obtain a second integrity verification code of the software package combined by the plurality of data blocks from the target server; determine whether the second integrity verification code is identical to the first integrity verification code; if it is determined that the second integrity verification code is identical to the first integrity verification code, it is determined that the software package is complete; if it is determined that the second integrity verification code is different from the first integrity verification code, it is determined that the software package is incomplete.

[0148] In some possible implementation manners, the apparatus 30 for uploading the software package to the target server further comprises a monitoring module, and the data recovery module is configured to: monitor a transmission state of each data block during the transmission process; in response to monitoring that the transmission state of the data block is abnormal, performing abnormal type identification according to a real-time transmission state parameter to determine a current abnormal type corresponding to the data block; determining a target recovery operation matched with the current abnormal type from a plurality of preset recovery operations, and performing the target recovery operation.

[0149] In some possible implementation manners, the data recovery module is specifically configured to: input the real-time transmission state parameter into a preset trained abnormal type identification model, and output the current abnormal type by using the trained abnormal type identification model, wherein the trained abnormal type identification model is obtained by training a historical abnormal state type and a corresponding historical transmission state parameter.

[0150] The various modules of the apparatus for uploading the software package to the target server provided in the embodiments of the present application can achieve Figure 2 The various steps of the method for uploading the software package to the target server are provided with functions and can achieve corresponding technical effects. For brevity, the functions and technical effects will not be described herein.

[0151] Figure 4 This is a schematic diagram of the structure of an electronic device provided in another embodiment of this application. See also... Figure 4 The method of uploading software packages to a target server in the above embodiments can be implemented by an electronic device 40, which includes a processor 41 and a memory 42 storing computer program instructions; when the processor 41 executes the computer program instructions, it implements any of the methods of uploading software packages to a target server in the above embodiments.

[0152] The method for uploading software packages to a target server in the above embodiments can be implemented using a computer storage medium. This computer storage medium stores computer program instructions; when these instructions are executed by a processor, they implement any of the methods for uploading software packages to a target server described in the above embodiments.

[0153] This application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the methods described above for uploading a software package to a target server.

[0154] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0155] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0156] The above is merely a specific implementation of the present application. As can be clearly understood by a person skilled in the art from the above description, for the convenience and brevity of description, the specific working process of the system, module and unit described above can refer to the corresponding process in the foregoing method embodiments, which will not be described herein again. It should be understood that the protection scope of the present application is not limited in this way, and any person skilled in the art can easily think of various equivalent modifications or replacements within the technical range disclosed in the present application, and these modifications or replacements should be covered in the protection scope of the present application.

Claims

1. A method of uploading a software package to a target server, characterized by, The method is applied to a client with internet access, and a target server is deployed in a secure network area which cannot directly access the internet, and the method comprises the following steps: Obtaining a network resource address of a software package from a software package source website; Downloading a data stream of the software package in a streaming mode according to the network resource address; In the process of transmitting the data stream, the data stream is divided into a plurality of continuous data blocks, and each data block is stored as a temporary file; In response to detecting the temporary file, the temporary file is uploaded to the target server; In response to all data blocks of the data stream being downloaded and all temporary files corresponding to the data blocks being uploaded to the target server, the target server is controlled to combine the plurality of temporary files into the software package.

2. The method of claim 1, wherein, The method comprises the following steps: In the webpage corresponding to the software package source website, a user operation of triggering a software package download request is simulated; A software package download response sent by a source server corresponding to the software package source website is received, and the network resource address is obtained from the software package download response.

3. The method of claim 1, wherein, The data stream is divided into a plurality of continuous data blocks, which comprises the following steps: Obtaining real-time network state parameters, the real-time network state parameters comprising at least one of the following: network delay, data packet loss rate, bandwidth; The size of each data block is dynamically adjusted according to the real-time network state parameters.

4. The method of claim 3, wherein, The size of each data block is dynamically adjusted according to the real-time network state parameters, which comprises the following steps: The real-time network quality score is calculated according to the real-time network state parameters; the real-time network quality score is negatively correlated with the network delay and the data packet loss rate, and is positively correlated with the bandwidth; In response to the network quality score being greater than a first preset score threshold, the size of each subsequent data block is gradually increased by a first preset data amount until the size of the data block reaches a preset upper limit, the network quality score is less than the first preset score threshold, or the data block upload fails is detected; In response to the network quality score being less than a second preset score threshold, the size of each subsequent data block is gradually reduced by a second preset data amount until the size of the data block reaches a preset lower limit or the network quality score is greater than the second preset score threshold; the second preset score threshold is less than the first preset score threshold.

5. The method of claim 1, wherein, After the temporary file is uploaded to the target server in response to detecting the temporary file, the method further comprises the following steps: After the temporary file is uploaded to the target server, the temporary file is deleted.

6. The method of claim 1, wherein, After the target server is controlled to combine the plurality of temporary files into the software package, the method further comprises the following steps: A first integrity check code of the software package is obtained from the software package source website; A second integrity check code of the software package combined by the plurality of data blocks is obtained from the target server; It is determined whether the second integrity check code is the same as the first integrity check code; If it is determined that the second integrity check code is the same as the first integrity check code, it is determined that the software package is complete. If it is determined that the second integrity check code is different from the first integrity check code, it is determined that the software package is not complete.

7. The method of claim 1, wherein, After detecting the temporary file, the temporary file is uploaded to the target server. During transmission, the transmission state of each data block is monitored. In response to monitoring that the transmission state of the data block is abnormal, an abnormal type is identified according to a real-time transmission state parameter, and a current abnormal type corresponding to the data block is determined. A target recovery operation matching the current abnormal type is determined from a plurality of preset recovery operations, and the target recovery operation is executed.

8. The method of claim 7, wherein, The abnormal type is identified according to the real-time transmission state parameter, and the current abnormal type corresponding to the data block is determined. The real-time transmission state parameter is input into a preset trained abnormal type identification model, and the current abnormal type is output by the trained abnormal type identification model, wherein the trained abnormal type identification model is trained by using a historical abnormal state type and a corresponding historical transmission state parameter.

9. An apparatus for uploading a software package to a target server, the apparatus comprising: The device is applied to a client, the client has internet access authority, the target server is deployed in a secure network area that cannot directly access a software package source website, and the device comprises: An acquisition module is configured to acquire a network resource address of a software package from a software package source website. A download module is configured to download a data stream of the software package in a streaming mode according to the network resource address. A segmentation module is configured to segment the data stream into a plurality of continuous data blocks during transmission of the data stream, and store each data block as a temporary file. An upload module is configured to upload the temporary file to a target server in response to detecting the temporary file. A control module is configured to control the target server to combine a plurality of temporary files into the software package in response to all data blocks of the data stream being downloaded and all temporary files corresponding to the data blocks being uploaded to the target server.

10. An electronic device, comprising: The device comprises a processor and a memory storing computer program instructions; the processor executes the computer program instructions to implement the method for uploading a software package to a target server according to any one of claims 1-8.

11. A computer readable storage medium, characterized in that, The computer readable storage medium stores computer program instructions, and the computer program instructions are executed by the processor to implement the method for uploading a software package to a target server according to any one of claims 1-8.

12. A computer program product, characterised in that, The instructions in the computer program product are executed by the processor of the electronic device, so that the electronic device can execute the method for uploading a software package to a target server according to any one of claims 1-8.

Images