UDP file serialization in one-way delivery system

Abstract

Examples of the present disclosure describe systems and methods for UDP file serialization. In an example, a file received at a first device in an OWT system is separated into a plurality of data blocks. Each data block is further separated into a plurality of data segments. Metadata associated with the file is inserted into each of the data blocks and each of the data segments. Comprising the data segments and the constituent data blocks are transmitted to a second device in the OWT system. The second device uses the metadata in the data blocks and the data segments to reconstruct the file. In some examples, a data loss mitigation policy is implemented to mitigate data packet loss and data packet corruption during processing and transmission.

Description

Background Technology

[0001] User Datagram Protocol (UDP) is used to transmit messages between endpoints in an Internet Protocol (IP) network. In One-Way Transmission (OWT) systems, UDP must be used to construct file-based content and transmit it to endpoints communicating at the boundary of the OWT system. However, there is currently no standard protocol for transmitting files via UDP in OWT systems.

[0002] It is with regard to these and other general considerations that various aspects have been disclosed herein. Moreover, although relatively specific problems may be described, it should be understood that these examples should not be limited to solving the specific problems identified in the context of this disclosure or elsewhere. Summary of the Invention

[0003] This disclosure describes examples of systems and methods for UDP file serialization. In the examples, a file received at a first device in an OWT system is split into multiple data blocks. Each data block is further split into multiple data segments. Metadata associated with the file is inserted into each data block and each data segment. The data packets, including the data segments and the data blocks, are transmitted to a second device in the OWT system. The second device uses the metadata in the data blocks and data segments to reconstruct the file. In some examples, data loss mitigation strategies are implemented to mitigate data packet loss and corruption during processing and transmission.

[0004] This summary is provided to introduce, in a simplified form, the selection of concepts that will be further described in the detailed description below. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Additional aspects, features, and / or advantages of the examples will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this disclosure. Attached Figure Description

[0005] Refer to the following figures for an example description.

[0006] Figure 1A and 1B The illustration shows an example system that implements UDP file serialization in the OWT system.

[0007] Figure 2 The illustration shows an example file segmented into data blocks and data segments according to the UDP file serialization technique described in this article.

[0008] Figure 3 The illustration shows an example method for UDP file serialization in the OWT system.

[0009] Figure 4 The illustration shows an example method for UDP file serialization in the first computing environment of the OWT system.

[0010] Figure 5 The illustration shows an example method for UDP file serialization in the second computing environment of the OWT system.

[0011] Figure 6 This is a block diagram illustrating example physical components of a computing device used to implement various aspects of the present disclosure.

[0012] Figure 7 This is a simplified block diagram of an example distributed computing system used to practice various aspects of this disclosure. Detailed Implementation

[0013] A One-Way Transmission (OWT) system refers to a computing system where one or more endpoints are data diodes (or separate from them), configured to ensure that data packets can only be transmitted unidirectionally through the computing system. In examples, the data diodes ensure unidirectional data packet transmission through hardware and / or software components such as a transmit-only network interface card (NIC). The transmit-only NIC transmits data to the endpoints, but cannot receive data from the endpoints due to the physical disconnection of the receive pins on the transmit-only NIC's network controller chip. In some examples, the transmit-only NIC also includes firmware that sets the NIC's link state to always "up" (e.g., enabled and / or active).

[0014] In many cases, OWT systems are used to protect networks or endpoints from outbound data transmission, malicious inbound data transmission (e.g., viruses and malware), and network attacks. As an example, OWT systems facilitate data transfer between computing environments with the same or different security levels (e.g., high security or low security), where at least one computing environment is considered low-trusted relative to another. For instance, a first computing environment that is highly trusted relative to a device in a first computing environment and / or relative to one or more other computing environments can receive data from a second computing environment that is considered low-trusted by the first computing environment.

[0015] In the examples, a high-trust environment refers to a system or network where devices, applications, and users are considered trustworthy, and security measures are deployed to establish and maintain that trust. In this type of environment, the devices and / or stakeholders involved (such as devices, software, and users) are typically authenticated, authorized, and / or comply with established security policies and best practices. High-trust environments typically have strict access controls, encryption, and monitoring to ensure trust is maintained and to minimize the risk of unauthorized access, data breaches, or other security incidents. Based on the security technologies implemented by the high-trust environment (e.g., unique encryption keys, key credentials, or other cryptographic techniques), devices within the high-trust environment can be authorized to access or accessed by other devices. For example, based on a high-trust environment (or its devices) included in a permitted list (e.g., a list of approved devices and / or computing environments), communications transmitted by a high-trust environment can be considered trustworthy by other computing environments or devices. Alternatively, communications transmitted by a high-trust environment can be considered trustworthy based on the cryptographic or credential provided by the communication. In some examples, devices in a high-trust environment do not require authentication to access or be accessed by other devices. High-trust environments generally do not expose security technologies implemented by the high-trust environment to other computing environments, which may be considered low-trust or untrusted environments by the high-trust environment.

[0016] In contrast, a low-trust or untrusted environment refers to a system or network where devices, applications, and / or users are not implicitly trusted or where there is a high risk of unauthorized access or malicious activity. A low-trust or untrusted environment may have limited or no appropriate security measures, or may include or be connected to one or more external or unmanaged devices. Alternatively or additionally, a low-trust or untrusted environment refers to an environment where devices are not considered secure or trustworthy by other devices within and / or outside the low-trust or untrusted environment. Because the security technologies implemented by the high-trust environment are not exposed to the low-trust or untrusted environment, the low-trust or untrusted environment may not be able to access or communicate with the high-trust environment without performing various authorization and / or authentication steps that are not required to be performed by devices in the high-trust environment. In the example, the OWT system may span or include multiple computing environments separated by one or more boundaries between computing environments.

[0017] Therefore, protocols requiring handshakes between endpoints cannot be used in such an OWT system. Instead, connectionless communication protocols (such as the User Datagram Protocol) must be used. The User Datagram Protocol (UDP) is a computer networking communication protocol used to transmit (enclosed in data packets) data between source and destination endpoints (e.g., physical computing devices or virtualized computing components) in an Internet Protocol (IP) network. UDP uses a connectionless communication model, where data can be transmitted between endpoints without first ensuring that the destination endpoint is available to receive data. Because the connectionless communication model is inconvenient for handshake protocols (e.g., automated processes for establishing parameters for communication between endpoints), UDP does not provide guarantees for packet delivery, packet ordering, or packet duplication protection.

[0018] Because of the unidirectional data transmission in the OWT system, UDP (or a similar protocol using connectionless communication) must be used to construct file-based content and transmit it to endpoints communicating across the OWT system boundary. However, there is currently no standard communication protocol for transferring files via UDP in the OWT system.

[0019] This disclosure provides a solution for implementing UDP file serialization in an OWT system. In embodiments of this disclosure, a file provided from a first computing environment is processed at a first device in the OWT system. The first device serializes the file by splitting it into multiple data blocks. In an example, the size of the multiple data blocks is based on the file size (e.g., the file is split into a large number of data blocks, where each data block is the same size) or a predetermined size limit (e.g., the file is split into 2-megabyte data blocks, where the last data block may be less than 2 megabytes). Metadata is inserted into each of the multiple data blocks to facilitate the processing of the multiple data blocks. Examples of data block metadata include a file identifier, file type, content or section identifier, transaction identifier, data block number, data block hash value, data block size or length, and data block offset.

[0020] The first device further serializes the file by separating multiple data blocks into multiple data segments. Each of the multiple data segments may correspond to a specific data packet type (or include data from it), such as a start file data packet, a start block data packet, a data stream data packet, an end block data packet, or an end file data packet. In the example, the size of the multiple data segments is based on the Maximum Transmission Unit (MTU) of a specific data packet protocol (e.g., UDP). For example, if the MTU of a UDP data packet is “N” bytes, each data segment will be created with a size of approximately (but not greater than) “N” bytes. Metadata is inserted into each of the multiple data segments to facilitate the processing of the multiple data segments. Examples of data segment metadata include a file identifier, file type, content or section identifier, transaction identifier, file source indicator (e.g., the identifier of the first device), data segment number, data segment hash value, data segment size or length, and data segment offset.

[0021] In some embodiments of this disclosure, the first device applies error correction techniques at the data block level and / or the data segment level. As an example, erasure coding can be applied to each data block. As used herein, erasure coding refers to a data protection method in which data is segmented, expanded, encoded with redundant data, and stored in multiple locations. In this example, applying erasure coding to a data block can cause data segments (or portions of data segments) within the data block to be encoded with redundant data and copied to one or more other data segments and / or data blocks.

[0022] Data packets, including data segments that make up data blocks, are transmitted to a second device in a second computing environment of the OWT system. In the example, the second device is separated from the first device by at least one boundary of the OWT system. The second device uses metadata from the received data blocks and data segments to reconstruct the file. In some examples, the second device verifies the integrity of the reconstructed file based on the metadata. If the second device determines that a data block or data segment of the file cannot be verified (e.g., due to data loss or corruption), error correction techniques are applied to reconstruct or retrieve the lost or corrupted data. As an example, Reed-Solomon codes can be used to reconstruct data lost from data segments. Reed-Solomon codes refer to a mathematical formula that enables the regeneration of lost data from fragments of known data (checksum blocks).

[0023] After reconstructing the file, the second device transmits the reconstructed file to the third computing environment of the OWT system. In this example, the third computing environment is separated from the first and second computing environments by at least one boundary of the OWT system. The metadata of the reconstructed file is used to transmit the reconstructed file to the destination endpoint.

[0024] Thus, this disclosure provides several technical benefits and improvements over previous OWT data transmission solutions. These technical benefits and improvements include: creating and implementing a UDP-based protocol for OWT systems; applying error correction techniques at the block level and / or segment level to files transmitted using OWT systems; segmenting and reconstructing files transmitted in OWT systems so that data within the files is not exposed outside of OWT systems; and providing more resilient data delivery and improved data integrity in a secure environment without compromising data security.

[0025] Figure 1A and 1B The diagram illustrates a system implementing UDP file serialization within an OWT system. As presented, system 100 is a combination of interdependent components that interact to form an integrated whole. The components of system 100 can be hardware or software components (e.g., application programming interfaces (APIs), modules, runtime libraries) implemented on and / or executed by hardware components of system 100. In one example, the components of system 100 are distributed across multiple processing devices or computing systems.

[0026] exist Figure 1A and 1B In this example, system 100 represents an OWT system for transferring files between different computing environments. System 100 includes computing environments 102, 104, and 106. In this example, computing environments 102, 104, and 106 are implemented in a cloud computing environment or another type of distributed computing environment, and depend on one or more distributed computing models / services (e.g., Infrastructure as a Service (IaaS), Platform as a Service (PSSS), Software as a Service (SaaS), Functionality as a Service (FaaS)). Although Figure 1A and 1B It is described as a specific combination of computing environments and devices, but the size and structure of the devices and computing environments described herein can vary, and may include additional or more... Figure 1A and 1B The fewer components described herein. Furthermore, although file transfer between the OWT system and at least one computing environment is described in the case of another computing environment considering it a low-trust computing environment. Figure 1A , Figure 1B And the examples in the following figures, but these examples can also be used for other types of data transfer between non-OWT systems and computing environments of various (or similar) types, trust levels, and security levels. For example, these examples can be applied to data transfer between computing environments where devices running in one or more computing environments are trusted by devices running in other computing environments (e.g., the computing environments have a high degree of trust in each other).

[0027] In the example, computing environment 102 represents a low-trust computing environment, wherein devices executing within computing environment 102 are not trusted by devices executing within computing environments 104 or 106. In this example, computing environment 102 may be physically separated from computing environments 104 and 106, such that computing environment 102 is located in a first physical location (e.g., area, building, room, or rack), while computing environments 104 or 106 are located in different second physical locations. Alternatively, computing environment 102 and computing environments 104 and / or 106 may share the same physical location.

[0028] about Figure 1A The computing environment 102 includes a computing device 108. Examples of computing devices 108 include data diodes and server devices (such as web servers, file servers, application servers, and database servers). The computing device 108 receives and / or processes input data (such as file 110) from within or accessible to a user or computing device in the computing environment 102. File 110 may include one or more types of data (such as audio data, touch data, text-based data, gesture data, and / or image data). The computing device 108 serializes file 110 by breaking it into one or more data blocks using a file segmentation service or utility. The file segmentation service or utility is implemented locally on the computing device 108 or remotely accessed by the computing device 108.

[0029] In one example, the size of the data blocks created from file 110 is based on the size of file 110. In this example, computing device 108 splits file 110 into a predetermined number of data blocks (e.g., one, two, four, or ten), such that each data block stores the maximum amount of data that can be stored by the data block. For example, if the predetermined number of data blocks is set to four, file 110 with a size of 5 megabytes is split into four data blocks, each with the same size of approximately 1.25 megabytes. In another example, the size of the data blocks created from file 110 is based on a predetermined size limit. In this example, computing device 108 splits file 110 into data blocks of a predetermined size (e.g., 512 kilobytes or 2 megabytes), such that one or more data blocks (e.g., the last data block to be created) can store data blocks smaller than the predetermined size. For example, if the predetermined size of the data blocks is set to 2 megabytes, file 110 with a size of 5 megabytes is split into two 2-megabyte data blocks and one 1-megabyte data block.

[0030] Computing device 108 further serializes file 110 by splitting data blocks into data segments using a file segmentation service or utility. In the example, the size of the data segment is based on one or more attributes of the data packets used to transmit data through system 100 (such as MTU, data packet type / protocol, source and / or destination address, type of error detection / correction applied, and payload content type). For example, if the MTU of a UDP data packet is 1500 bytes, and each UDP data packet has 1472 available bytes (of which 28 bytes are used or reserved for the UDP data packet header or other data fields), then a data segment will be created with a size of 1472 bytes. However, at least one data segment (corresponding to the end of the file) can be created with a size less than 1472 bytes.

[0031] Computing device 108 inserts metadata into data blocks and data segments. In the example, metadata is used to facilitate the processing of data blocks and data segments in the correct order and to enable the verification of data blocks and / or data segments. Examples of metadata inserted into data blocks include file identifiers (e.g., filenames or file links), file formats or types (e.g., text files, audio files, .doc files, .pdf files), content or section identifiers (e.g., characters or symbols indicating the beginning or end of content or content sections), transaction identifiers (e.g., unique identifiers used for file transfer requests), data block numbers (e.g., values ​​assigned to data blocks), data block hash values ​​(e.g., strings representing the attributes and / or content of data blocks), data block sizes (e.g., values ​​indicating the amount of data stored in a data block), data block lengths (e.g., values ​​indicating the number of characters, lines, or entries in a data block), and data block offsets (e.g., values ​​indicating the sequence order of the created data blocks). Examples of metadata inserted into a data segment include file identifiers, file types, content or section identifiers, transaction identifiers, file source indicators (e.g., an identifier for computing device 108), data segment numbers (e.g., values ​​assigned to the data segment), data segment hash values ​​(e.g., strings representing the attributes and / or content of the data segment), data segment sizes (e.g., values ​​indicating the amount of data stored in the data segment), data segment lengths (e.g., values ​​indicating the number of characters, lines, or entries in the data segment), and data segment offsets (e.g., values ​​indicating the sequence order of the created data segments). In at least one example, the metadata inserted into the data block and / or data segment does not include or identify the destination endpoint for file 110.

[0032] In some examples, computing device 108 applies error correction techniques at the data block level and / or at the data segment level. Error correction techniques mitigate data packet loss and data corruption within data packets. In one example, computing device 108 implements erasure coding to segment file 110 into data blocks and data segments, encodes data blocks and / or data segments using redundant data, and copies portions of data blocks and / or data segments to other data blocks and / or data segments.

[0033] Computing device 108 transmits data packets, including data segments that make up data blocks, to computing environment 104. In this example, computing environment 104 represents a high-trust computing environment that considers computing environment 102 to be a low-trust environment. Computing environment 104 includes computing device 112. Examples of computing device 112 include those devices described above with respect to computing device 108. In some examples, computing device 112 is located near computing device 108 (e.g., in the same building or room). For example, computing device 112 and computing device 108 may be located in the same room of a data center, such that computing device 108 is located in a first data rack (e.g., a server rack or data cabinet), while computing device 112 is located in a second data rack or a different rack of the first data rack. In such examples, computing device 112 and computing device 108 may be directly connected via point-to-point cables. In other examples, computing device 112 is located away from computing device 108 (e.g., in a different building or room).

[0034] Computing device 112 receives data packets associated with file 110 from computing device 108. Computing device 112 reconstructs file 110 from the data packets based on metadata added to data blocks and / or data segments. For example, data segment offset values ​​inserted into data segments are used to determine the sequence order of data segments within data blocks, data block offset values ​​inserted into data blocks are used to determine the sequence order of data blocks within file 110, and transaction identifiers in data blocks and data segments are used to associate data blocks and data segments with file 110.

[0035] In some examples, before or during the reconstruction of file 110, computing device 112 determines whether the necessary number (e.g., all or at least a threshold percentage) of data segments associated with file 110 have been received from computing device 108. Computing device 112 also verifies data blocks and / or data segments for file 110. If it is determined that at least a portion of one or more data segments has not been received or that one or more data blocks and / or data segments cannot be verified, computing device 112 performs error correction to reconstruct or retrieve the lost data. For example, computing device 112 may use forward error techniques (such as erasure coding) to reconstruct data blocks or data segments. Alternatively, computing device 112 may retrieve data blocks or data segments including the lost data from another device (e.g., computing device 108 or an alternative device in computing environment 104).

[0036] After reconstructing file 110 from the received data packets, computing device 112 transmits the reconstructed file 120 to computing environment 106. In some examples, computing environment 106 considers computing environments 102 and / or 104 to be low-trust. In other examples, computing environment 106 refers to a computing environment with the same or lower security level as computing environments 102 and / or 104. Computing environment 106 includes data storage device 114. Examples of data storage device 114 include directly attached storage devices (e.g., hard disk drives, solid-state drives, and optical disk drives), network-based storage devices (e.g., storage area network (SAN) devices and network-attached storage (NAS) devices), and other types of storage devices. Data storage device 114 receives and stores the reconstructed file 120. In some examples, data storage 114 provides the reconstructed file 120 to a destination endpoint or to another device facilitating the delivery of the reconstructed file 120 to the destination endpoint.

[0037] about Figure 1B ,and Figure 1A Similarly, computing environment 102 includes computing device 108. For example... Figure 1A As described, computing device 108 processes file 110, separates file 110 into data blocks and corresponding data segments, applies error correction techniques, and transmits data packets for file 110 to computing environment 104.

[0038] exist Figure 1B In the computing environment 104, computing devices 112A and 112B and temporary data storage devices 116A and 116B are included. Examples of computing devices 112A and 112B include those related to... Figure 1AThe devices described in computing device 112 are as follows. In some examples, computing device 112A is located near computing device 112B (e.g., in the same room or data rack). Additionally, computing devices 112A and / or 112B may be located near computing device 108. For example, computing devices 108, 112A, and 112B may each be stored in separate data racks within the same room of a data center, such that computing device 108 is directly connected to computing devices 112A and 112B via point-to-point cables.

[0039] In the example, computing devices 112A and 112B provide data redundancy for data transmitted across system 100. For example, one of the computing devices 112A and 112B is designated as the primary device, while the other computing devices in 112A and 112B are designated as secondary devices. The primary device is used to transmit reconstructed files to a collection point (such as data storage device 114), and the secondary devices are used to provide redundancy support to the primary device. Thus, each computing device in 112A and 112B receives data packets associated with file 110 from computing device 108. In some examples, at least one computing device (e.g., the primary device) of computing devices 112A and 112B determines whether it has received the necessary number of data segments associated with file 110. If a computing device determines that it has not received the necessary number of data segments associated with file 110, the computing device attempts to retrieve the lost data segments from another device (e.g., computing device 108 or the secondary device).

[0040] For example, in some examples, computing devices 112A and 112B periodically transmit heartbeat messages 118 to each other. Heartbeat messages 118 include transmission information for one or more time periods (such as the time between the current heartbeat message and a previous heartbeat message). Examples of transmission information include the number of files transmitted during that time period, a list of data blocks and / or data segments transmitted in each file, a transaction identifier for each file transmitted, file transmission metrics (e.g., average or maximum time to transmit files or average or maximum file size), the number of data packets lost during transmission, the number of files for which error correction was performed, the success rate of the error correction performed, and the role of the computing device (e.g., a master device or a secondary device). In this example, the master device of computing devices 112A and 112B evaluates heartbeat messages 118 received from the secondary devices of computing devices 112A and 112B to determine whether the secondary device has received a lost data segment. If it is determined that the secondary device has received a lost data segment, the master device requests the lost data segment from the secondary device.

[0041] In one alternative example, the master device may provide data segments received by the master device to the secondary device. For example, if it is determined that the secondary device has received more data segments for file 110 than the master device has received, the master device may provide the secondary device with any data segments received by the master device but not by the secondary device. In such an example, transferring data segments from the master device to the secondary device (as opposed to transferring data segments from the secondary device to the master device) reduces the bandwidth and CPU processing required to transfer data segments. In another alternative example, if it is determined that the secondary device has received more data segments for file 110 than the master device has received, the master device may designate the secondary device as the master device (and thus designate itself as the secondary device) at least for the purpose of transferring file 110. In such an example, after file 110 has been processed and transferred through system 100, the secondary device may continue to be designated as the master device, or the secondary device may be redesignated as the secondary device.

[0042] In the example, in response to determining that at least one computing device of computing devices 112A and 112B has received or accessed the necessary number of data segments for file 110, the master device (and / or the secondary device) verifies the data blocks and / or data segments received for file 110. Alternatively, at least one computing device of computing devices 112A and 112B verifies the data blocks and / or data segments for file 110 before determining that computing devices 112A and / or 112B have received the necessary number of data segments, or verifies the data blocks and / or data segments for file 110 without determining that computing devices 112A and / or 112B have received the necessary number of data segments. Verifying data blocks and / or data segments may include evaluating the hash values ​​of the data blocks and / or data segments for file 110. As an example, the master device may use a hash function or a similar utility to generate the hash values ​​of the data blocks received for file 110. A hash function refers to a mathematical function used to map data of arbitrary size to values ​​of fixed size. The hash function can be the same as or similar to the hash function used by computing device 108 to create hash values ​​inserted into data blocks and / or data segments. The master device compares two hash values ​​for a data block (e.g., a hash value created by the master device and a hash value created by computing device 108) to determine if the two hash values ​​match. If the comparison indicates that the two hash values ​​match, the data block is considered valid. If the comparison indicates that the two hash values ​​do not match, the master device performs an error correction process to attempt to reconstruct the data block. In some examples, the error correction process includes performing erasure coding (e.g., Reed-Solomon codes, Parchive codes, or any other anti-erasure maximum distance separation (MDS) codes) to recreate the data block and / or data segment.

[0043] After determining that the necessary number of data segments and / or verification data blocks and / or data segments for file 110 have been received, at least one of the computing devices 112A and 112B reconstructs file 120 from the data groups based on metadata added to the data blocks and / or data segments. For example, data segment offset values ​​inserted into data segments are used to determine the sequence order of data segments within data blocks, data block offset values ​​inserted into data blocks are used to determine the sequence order of data blocks within file 110, and transaction identifiers in data blocks and data segments are used to associate data blocks and data segments with file 110.

[0044] While a file is being reconstructed, computing devices 112A and 112B store the reconstructed portion of file 110 in their respective temporary data storage devices 116A and 116B. Examples of temporary data storage devices 116A and 116B include random access memory and cache. If the master device successfully reconstructs the reconstructed file 120, it transmits the reconstructed file 120 to data storage device 114 and notifies the secondary device (e.g., via heartbeat message 118) that the reconstructed file 120 has been successfully delivered. Computing devices 112A and 112B then remove the reconstructed portion of file 110 (or the reconstructed file 120) from their respective data storage devices 116A and 116B. However, if the master device fails to successfully reconstruct the reconstructed file 120 or does not notify the secondary device that the reconstructed file 120 has been successfully delivered within the expected time period, the secondary device transmits the reconstructed file 120 to data storage device 114. The secondary device then notifies the primary device that the reconstructed file 120 has been successfully transmitted, and the computing devices 112A and 112B remove the reconstructed portion (or reconstructed file 120) of file 110 from their respective data storage devices 116A and 116B.

[0045] and Figure 1A Similarly, computing environment 106 includes data storage device 114. Data storage device 114 receives reconstructed file 120 and can provide reconstructed file 120 to a destination endpoint or, for example... Figure 1A Another device described in the text.

[0046] Figure 2 The illustration shows an example file segmented into data blocks and data segments according to the UDP file serialization technique described in this article. Figure 2In this example, file 110 is segmented into data blocks 202 and 204, which together constitute the entire content of file 110. Data block 202 includes data block 1 metadata, data segment 1, data segment 2, and data segment 3. Data block 1 metadata includes, for example, a file identifier (e.g., "file 1"), a transaction identifier (e.g., "transaction 215"), a data block number (e.g., 1), a data block hash value (e.g., "MNUHK3TLNBQXG2BR"), a data block size (e.g., 5000 bytes), and a data block offset (e.g., 0). In this example, the metadata of data blocks 202 and 204 is stored in the data fields of the header of the respective data blocks.

[0047] Each of data segments 1, 2, and 3 includes metadata and one or more data entries. For example, data segment 1 includes data segment 1 metadata, data entry 1, data entry 2, and data entry 3. The metadata for data segment 1 includes, for example, a file identifier (e.g., "file 1"), a transaction identifier (e.g., "transaction 215"), a file source indicator (e.g., computing device 112A), a data segment number (e.g., 1), a data segment hash (e.g., "ONSWO3LFNZ2GQYLTNAYQ===="), a data segment size (e.g., 1500 bytes), and a data segment offset (e.g., 0). In the example, the metadata for data segments 1, 2, 3, 4, and 5 is stored in the data fields of the header of the respective data segment. Examples of data entries include text, numeric values, column data, image data, and audio data.

[0048] Data block 204 includes data block 2 metadata, data segment 4, and data segment 5. The data block 2 metadata includes, for example, a file identifier (e.g., "file 1"), a transaction identifier (e.g., "transaction 215"), a data block number (e.g., 2), a data block hash (e.g., "MNUHK3TLNBQXG2BS"), a data block size (e.g., 7000 bytes), and a data block offset (e.g., 1). In some examples, each data block is created with a static size, so that if a data block includes fewer than the maximum number of data segments that can be included in a data block, the size of the data block is not affected. For example, when a data block includes fewer than three data segments, the size of a data block that can include up to three data segments remains unchanged. Instead, as depicted in data block 204, the data block will include empty (e.g., unused) space. In other examples, each data block is created with a dynamic size that does not exceed the maximum size set for the data block. For example, when a data block includes fewer than three data segments, the size of a data block that can include up to three data segments is reduced from the maximum size of the data block.

[0049] Systems that can be employed by the embodiments disclosed herein have been described; methods that can be performed by such systems are now provided. Although in Figure 1A and Figure 1B Methods 300-500 are described in the case of system 100, but the execution of methods 300-500 is not limited to such examples.

[0050] Figure 3 The illustration depicts a method 300 for UDP file serialization in an OWT system. In this example, the OWT system includes multiple computing environments that utilize application-layer protocols built on UDP to transmit data through the system. One or more computing environments may differ in trust level, security level, or physical location. For example, in some embodiments, one computing environment is a low-security environment, while another computing environment is a high-security environment. In some embodiments, the OWT system is configured such that the source endpoint and / or destination endpoint of the data transmitted via OWT is unknown to one or more computing environments.

[0051] Method 300 begins at optional operation 302, where a file (such as file 110) is received at a first device (such as computing device 108). In the example, the first device is a data diode and / or a first computing environment (such as computing environment 102) located in the OWT system. The file originates from a source endpoint within the first computing environment, or the file is provided to the first computing environment from an external source endpoint. As an example, file 110 may be a video file generated by a video capture device implemented in the first computing environment. The video capture device may transmit the video file to the first device as part of a secure data transfer request from the operator of the video capture device.

[0052] At operation 304, the first device serializes the file by splitting it into one or more data blocks. Splitting the file into data blocks involves applying a file segmentation service or utility implemented on or remotely accessible by the first device to the file. In some examples, the number and / or size of the data blocks created from the file is based on the file's size. For example, a set of rules or other decision logic may instruct each file within a specific file size range (e.g., less than 2 megabytes, between 2 and 20 megabytes, greater than 20 megabytes) to be split into at least (or no more than) a specific number of data blocks or to be split into data blocks of a specific size. In other examples, the number and / or size of the data blocks created from the file is based on predetermined values. For example, a set of rules or decision logic may instruct each file (regardless of size) to be split into "N" data blocks (e.g., two data blocks) or data blocks of "N" size (e.g., two megabytes).

[0053] Metadata is inserted into data blocks to facilitate file reconstruction. Examples of metadata inserted into data blocks include file identifiers for files, file format or type for files, content or section identifiers for files, transaction identifiers for requests to transfer files through the OWT system, data block numbers for data blocks, data block hashes for data blocks, data block sizes for data blocks, data block lengths for data blocks, and data block offsets for data blocks. Metadata can be inserted into the header of a data block, inserted into the body of a data block, provided with the data block, or some combination thereof. In the example, a predetermined data size is reserved in the data block for metadata, and the remaining data block size is reserved for other data, such as data segments and / or error correction data.

[0054] At operation 306, the first device further serializes the file by splitting the data block into one or more data segments. Splitting the file into data segments includes applying a file segmentation service or utility to the file. In some examples, the size of the data segment created for the data block is based on one or more attributes of the data packets used to transmit data through the OWT system (e.g., MTU, data packet type or protocol, or applied error correction). For example, the size of the data segment may be based on the MTU of a protocol data unit (e.g., a UDP data packet). In other examples, the size of the data segment created for the data block is based on a predetermined value (e.g., 5000 bytes or 1 megabyte).

[0055] Metadata is inserted into data segments to facilitate file reconstruction. Examples of metadata inserted into data segments include file identifiers for files, file format or type for files, content or section identifiers for files, transaction identifiers for requests to transfer files through the OWT system, file source indicators for files, data segment numbers for data segments, data segment hashes for data segments, data segment sizes for data segments, data segment lengths for data segments, and data segment offsets for data segments. Metadata can be inserted into the header of a data segment, inserted into the body of a data segment, provided with the data segment, or a combination thereof. In the example, a predetermined data size is reserved in the data segment for metadata, and the remaining data segment size is reserved for other data, such as data entries from files and / or error correction data.

[0056] At operation 308, the first device applies error correction to the file. In the example, error correction is applied at the data block level and / or the data segment level to mitigate data packet loss and data corruption within data blocks and segments. For example, erasure coding can be applied to the file to encode data blocks and / or data segments with redundant data, and portions of the data blocks and / or data segments can be copied to other data blocks and / or data segments.

[0057] At operation 310, the first device transfers data blocks and data segments of a file to the second device. In the example, the second device (such as computing device 112) is located in a second computing environment (such as computing environment 104) of the OWT system. Although the second computing environment may be logically distinct from the first computing environment, the second device may be physically located near the first device. For example, the first and second devices may be located in the same building, the same room, or the same data rack. Alternatively, the second device may be physically located away from the first device (e.g., in a different area or building).

[0058] At decision operation 312, the second device determines whether error correction should be performed on the received data blocks and data segments of the file. In some examples, determining whether to perform error correction includes determining whether the necessary number of data segments associated with the file have been received from the first device. The necessary number may correspond to a percentage (e.g., 98%) of the data segments for the file. Alternatively, the necessary number may indicate that no more than a certain number of consecutive data segments (e.g., three data segments) are not received from the first device. In such examples, the certain number of consecutive data segments may be based on the error correction type applied to the file. If it is determined that error correction does not need to be performed on the received data blocks and data segments of the file, method 300 proceeds to operation 316. However, if it is determined that error correction needs to be performed on the received data blocks and data segments of the file, method 300 proceeds to operation 314.

[0059] At operation 314, the second device performs error correction. For example, if it is determined that the necessary number of data segments associated with the file have not been received, the second device attempts to retrieve the lost data segments (i.e., the data segments that were not received) from the first device. Alternatively, the second device attempts to retrieve the lost data segments from another device in the second computing environment. For example, if the second device is positioned in a data redundancy scenario, where the second device is acting as the primary device (such as computing device 112A) and the third device is acting as the secondary device (such as computing device 112B), then the second device and the third device receive data blocks and data segments of the file from the first device, respectively. In this scenario, the second device attempts to retrieve the lost data segments from the third device.

[0060] In response to (or instead of) determining that the necessary number of data segments associated with the file have been received, a second (or third) device verifies the data blocks and / or data segments received for the file. Verifying the data blocks and / or data segments may include evaluating the metadata inserted into the data blocks and / or data segments. As an example, the second device generates a hash value for the received data block and compares the generated hash value with a hash value stored in the metadata for the data block. If the two hash values ​​for the data block match, the received data block is considered valid. If the two hash values ​​for the data block do not match, the second device performs an error correction process to reconstruct the data block. In some examples, the error correction process includes performing erasure coding to recreate the data block and / or data segment.

[0061] At operation 316, the second device reconstructs the file from its data segments and data blocks. Reconstructing the file involves using metadata added to the data blocks and / or data segments to determine the order of reconstruction. For example, data segment offset values ​​inserted into data segments are used to determine the sequence order of data segments within data blocks, data block offset values ​​inserted into data blocks are used to determine the sequence order of data blocks within the file, and transaction identifiers in the data blocks and data segments are used to associate the data blocks and data segments with the file.

[0062] At operation 318, the second device transmits the reconstructed file to a data storage device (such as data storage device 114). In the example, the data storage device is located in a third computing environment (such as computing environment 106) of the OWT system. The data storage device can serve as a collection point for one or more devices inside or outside the OWT system. In at least one example, before transmitting the reconstructed file to the data storage device, the second device removes metadata inserted by the first device into data blocks and / or data segments. Thus, the original state of the file (e.g., the state of the file received by the first device) is preserved, and no information related to processing the file in the first or second computing environment is exposed to the third computing environment or entities outside the OWT system.

[0063] Figure 4 The illustration depicts a method 400 for implementing UDP file serialization in a first computing environment of an OWT system. Method 400 begins with an optional operation 402, where a file (such as file 110) is received at a first device (such as computing device 108). In this example, the first device is located in a first computing environment (such as computing environment 102) of the OWT system. The file originates from a source endpoint within the first computing environment, or the file is provided to the first computing environment from an external source endpoint.

[0064] At operation 404, the first device splits the file into one or more data blocks. Splitting the file into data blocks involves applying a file segmentation service or utility implemented on or remotely accessible by the first device to the file. In some examples, the number and / or size of the data blocks created from the file is based on the file's size. For example, a set of rules or other decision logic may instruct each file within a specific file size range (e.g., less than 2 megabytes, between 2 and 20 megabytes, greater than 20 megabytes) to be split into at least (or no more than) a specific number of data blocks or to be split into data blocks of a specific size. In other examples, the number and / or size of the data blocks created from the file is based on predetermined values. For example, a set of rules or decision logic may instruct each file (regardless of size) to be split into "N" data blocks (e.g., two data blocks) or data blocks of "N" size (e.g., two megabytes).

[0065] At operation 406, the first device inserts metadata into the data block. Inserting metadata into the data block facilitates file reconstruction and / or file transfer to the destination endpoint. Examples of metadata inserted into the data block include file identifiers for files, file format or type for files, content or section identifiers for files, transaction identifiers for requests to transfer files via the OWT system, file source indicators for files, data block numbers for data blocks, data block hashes for data blocks, data block sizes for data blocks, data block lengths for data blocks, and data block offsets for data blocks. Metadata can be inserted into the header of the data block, inserted into the body of the data block, provided with the data block, or some combination thereof. In this example, a predetermined data size is reserved in the data block for metadata, and the remaining data block size is reserved for other data, such as data entries from files and / or error correction data.

[0066] At operation 408, the first device segments the data block into one or more data segments. Segmenting a file into data segments involves applying a file segmentation service or utility to the file. In some examples, the size of the data segment created for the data block is based on one or more attributes of the data packets used to transmit data through the OWT system (e.g., MTU, data packet type or protocol, or applied error correction). For example, the size of the data segment may be based on the MTU of a Protocol Data Unit (e.g., a UDP data packet). In other examples, the size of the data segment created for the data block is based on a predetermined value (e.g., 5000 bytes or 1 megabyte).

[0067] At operation 410, the first device inserts metadata into the data segment. Inserting metadata into the data segment further facilitates file reconstruction and / or file transfer to the destination endpoint. Examples of metadata inserted into the data segment include file identifiers for files, file format or type for files, content or section identifiers for files, transaction identifiers for requests to transfer files through the OWT system, file source indicators for files, data segment numbers for data segments, data segment hashes for data segments, data segment sizes for data segments, data segment lengths for data segments, and data segment offsets for data segments. Metadata can be inserted into the header of the data segment, inserted into the body of the data segment, provided with the data segment, or some combination thereof. In this example, a predetermined data size is reserved in the data segment for metadata, and the remaining data segment size is reserved for other data, such as data entries from files and / or error correction data.

[0068] At operation 412, the first device applies error correction coding to the file. In the example, error correction coding is applied at the data block level and / or the data segment level to mitigate data packet loss and data corruption within data blocks and segments. For example, erasure coding can be applied to a file to encode data blocks and / or data segments with redundant data. Erasure coding can also partially copy data blocks and / or data segments to other data blocks and / or data segments.

[0069] At operation 414, the first device transfers data blocks and data segments of a file to the second device. In the example, the second device (such as computing device 112) is located in a second computing environment (such as computing environment 104) of the OWT system. Although the second computing environment may be logically distinct from the first computing environment, the second device may be physically located near the first device. For example, the first and second devices may be located in the same building, the same room, or the same data rack. Alternatively, the second device may be physically located away from the first device (e.g., in a different area or building).

[0070] Figure 5The illustration depicts a method 500 for implementing UDP file serialization in a second computing environment of an OWT system. Method 500 begins with an optional operation 502, where data blocks and data segments of a file (such as file 110) are received at a second device (such as computing device 112). In the example, the second device is located in a second computing environment (such as computing environment 104) of the OWT system. Data blocks and data segments are received from a first device (such as computing device 108) implemented in a first computing environment (such as computing environment 102) of the OWT system. In some examples, the data blocks and data segments respectively include data and / or metadata that facilitate the reconstruction of the file (e.g., reassembling the data blocks and data segments into a file or into a file corresponding to the reconstruction of the file).

[0071] At decision operation 504, the second device determines whether error correction should be performed on the data blocks and data segments of the file. In some examples, determining whether to perform error correction includes determining whether the necessary number of data segments associated with the file have been received from the first device. The necessary number may correspond to a percentage (e.g., 98%) of the data segments for the file. Alternatively, the necessary number may indicate that no more than a specific number of consecutive data segments (e.g., three data segments) are not received from the first device. In such examples, the specific number of consecutive data segments may be based on the error correction type applied to the file. If it is determined that error correction does not need to be performed on the received data blocks and data segments of the file, method 500 proceeds to operation 508. However, if it is determined that error correction needs to be performed on the data blocks and data segments of the file, method 500 proceeds to operation 506.

[0072] At operation 506, the second device performs error correction. For example, if it is determined that the necessary number of data segments associated with the file have not been received, the second device attempts to retrieve the lost data segments (i.e., the data segments that were not received) from the first device. Alternatively, the second device attempts to retrieve the lost data segments from another device in the second computing environment. For example, if the second device is positioned in a data redundancy scenario, where the second device is acting as the primary device (such as computing device 112A) and the third device is acting as the secondary device (such as computing device 112B), then the second device and the third device receive data blocks and data segments of the file from the first device, respectively. In this scenario, the second device attempts to retrieve the lost data segments from the third device.

[0073] In response to (or instead of) determining that the necessary number of data segments associated with the file have been received, a second (or third) device verifies the data blocks and / or data segments received for the file. Verifying the data blocks and / or data segments may include evaluating the metadata inserted into the data blocks and / or data segments. As an example, the second device generates a hash value for the received data block and compares the generated hash value with a hash value stored in the metadata for the data block. If the two hash values ​​for the data block match, the received data block is considered valid. If the two hash values ​​for the data block do not match, the second device performs an error correction process to reconstruct the data block. In some examples, the error correction process includes performing erasure coding to recreate the data block and / or data segment.

[0074] At operation 508, the second device reconstructs the file from its data segments and data blocks. Reconstructing the file involves using metadata added to the data blocks and / or data segments to determine the order of reconstruction. For example, data segment offset values ​​inserted into data segments are used to determine the sequence order of data segments within data blocks, data block offset values ​​inserted into data blocks are used to determine the sequence order of data blocks within the file, and transaction identifiers in the data blocks and data segments are used to associate the data blocks and data segments with the file.

[0075] In operation 510, the second device transmits the reconstructed file to the data storage device. In the example, the data storage device (such as data storage device 114) is located in a third computing environment (such as computing environment 106) of the OWT system. The data storage device can serve as a collection point for one or more devices inside or outside the OWT system. In at least one example, before transmitting the reconstructed file to the data storage device, the second device removes metadata inserted by the first device into data blocks and / or data segments. Thus, the original state of the file (e.g., the state of the file received by the first device) is preserved, and no information related to processing the file in the second computing environment is exposed to the third computing environment or entities outside the OWT system.

[0076] Figures 6-7 The associated description provides a discussion of various operating environments in which the aspects of this disclosure can be practiced. However, regarding Figures 6-7 The devices and systems illustrated and discussed are for illustrative purposes, and it is understood that a wide range of computing device configurations can be utilized to practice the aspects of this disclosure described herein.

[0077] Figure 6This is a block diagram illustrating the physical components (e.g., hardware) of a computing device 600 that can be used to practice various aspects of this disclosure. The computing device components described below can be applied to the computing devices and systems described above. In a basic configuration, computing device 600 includes a processing system 602, which includes at least one processing system and a system memory 604. Depending on the configuration and type of computing device, system memory 604 may include volatile storage devices (e.g., random access memory (RAM)), non-volatile storage devices (e.g., read-only memory (ROM)), flash memory, or any combination of such memories.

[0078] System memory 604 includes an operating system 605 suitable for running software application 620 and one or more program modules 606 (such as one or more components supported by the system described herein). For example, operating system 605 may be used to control the operation of computing device 600.

[0079] Furthermore, embodiments of the present invention can be practiced in conjunction with graphics libraries, other operating systems, or any other applications, and are not limited to any particular application or system. This basic configuration is... Figure 6 The components within the dashed line 608 are illustrated. The computing device 600 may have additional features or functions. For example, the computing device 600 may also include additional data storage devices (removable and / or non-removable), such as a disk or optical disk. Such additional storage devices... Figure 6 The diagram shows a removable storage device 607 and a non-removable storage device 610.

[0080] As described above, multiple program modules and data files can be stored in system memory 604. When executed on a processing system 602 including one or more processors, program module 606 (e.g., application 620) can perform processes including the aspects described herein. Other program modules that can be used according to aspects of this disclosure may include email and contact applications, word processing applications, spreadsheet applications, database applications, PowerPoint presentation applications, drawing or computer-aided applications, etc.

[0081] Furthermore, embodiments of this disclosure can be practiced in electronic circuits including discrete electronic components, packaged or integrated electronic chips containing logic gates, circuits utilizing microprocessors, or on a single chip containing electronic components or a microprocessor. For example, embodiments of this disclosure can be practiced via a system-on-a-chip (SOC), wherein... Figure 6Each or many of the components illustrated herein can be integrated onto a single integrated circuit. Such a SoC device may include one or more processing systems / units, graphics units, communication units, system virtualization units, and various application functions, all of which are integrated (or “programmed”) onto a chip substrate as a single integrated circuit. When operating via the SoC, the functionality described herein regarding the client switching protocol can be operated via application-specific logic integrated on a single integrated circuit (chip) along with other components of the computing device 600. Embodiments of this disclosure can also be practiced using other techniques capable of performing logical operations (such as, for example, AND, OR, and NOT) including mechanical, optical, fluid, and quantum technologies. Furthermore, embodiments of this disclosure can be practiced within a general-purpose computer or in any other circuit or system.

[0082] The computing device 600 may also have one or more input devices 612, such as a keyboard, mouse, pen, voice or speech input device, touch or swipe input device, etc. It may also include output devices(s) 614, such as a display, speaker, printer, etc. The above devices are examples and other devices may be used. The computing device 600 may include one or more communication connections 616 that allow communication with other computing devices 640. Examples of suitable communication connections 616 include radio frequency (RF) transmitters, receivers, and / or transceiver circuitry; universal serial bus (USB); parallel and / or serial ports.

[0083] As used herein, the term computer-readable medium may include computer storage media. Computer storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable instructions, data structures, or program modules. System memory 604, removable storage device 607, and non-removable storage device 610 are all examples of computer storage media (e.g., memory storage). Computer storage media include RAM, ROM, electrically erasable ROM (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical storage, magnetic tape cassettes, magnetic tape, disk storage or other magnetic storage devices, or any other article of manufacture that can be used to store information and can be accessed by computing device 600. Any such computer storage medium may be part of computing device 600. Computer storage media does not include carrier waves or other propagated or modulated data signals.

[0084] Communication media can be implemented by computer-readable instructions, data structures, program modules, or other data (such as carrier waves or other transport mechanisms) in modulated data signals, and include any information transmission medium. The term "modulated data signal" can describe a signal having one or more characteristics set or altered in such a manner as to information encoded in the signal. By way of example, communication media can include wired media (such as wired networks or direct wired connections) and wireless media (such as acoustic, RF, infrared, and other wireless media).

[0085] Figure 7 The illustration depicts one aspect of the architecture of a system for processing data received at a computing system from remote sources, such as a personal computer 704, a tablet computing device 706, or a mobile computing device 708 as described above. The computing system refers to the computing environments discussed above (such as computing environments 102, 104, and 106). For example, remote sources 704, 706, and 708 may be implemented in the first computing environment of the OWT system, or may be implemented outside the first computing environment of the OWT system. In either scenario, remote sources 704, 706, and 708 provide files and other data to the first computing environment and / or receive files and other data from one or more computing environments of the OWT system. Content displayed at server device 702 may be stored in different communication channels or other storage types. For example, various files and documents may be stored using a directory service 722, a web portal 724, an email service 726, an instant messaging storage 728, or a social networking site 730.

[0086] Input evaluation service 720 may be adopted by a client communicating with server device 702, and / or input evaluation service 720 may be adopted by server device 702. Server device 702 may provide data to and from client computing devices (such as personal computer 704, tablet computing device 706, and / or mobile computing device 708 (e.g., smartphone)) via network 715. By way of example, the computer system described above may be implemented in personal computer 704, tablet computing device 706, and / or mobile computing device 708 (e.g., smartphone). In addition to receiving graphics data that can be preprocessed at the graphics generation system or post-processed at the receiving computing system, any of these embodiments of the computing device may be obtained from repository 716.

[0087] As will be understood from this disclosure, one example of the technology discussed herein relates to a system comprising: a processing system; and a memory coupled to the processing system, the memory including computer-executable instructions that, when executed, perform the following actions: at a first device in a one-way delivery (OWT) system, separating a file into multiple data blocks; separating each of the multiple data blocks into multiple data segments; providing the multiple data blocks and multiple data segments to a second device in the OWT system; and applying error correction coding to the data blocks in the multiple data blocks or the data segments in the multiple data segments.

[0088] In another example, the technology discussed herein relates to a system comprising: a processing system; and a memory coupled to the processing system, the memory including computer-executable instructions that, when executed, perform operations including: performing error correction on data segments of a file that have been separated into multiple data segments, the data segments being included in the multiple data segments, at a first device in a one-way transfer (OWT) system; reconstructing the multiple data segments into a reconstructed file based on metadata inserted into the multiple data segments; and transmitting the reconstructed file to a second device in the OWT system.

[0089] In another example, the technology discussed herein relates to a method comprising: receiving data at a first device in a One-Way Transmission (OWT) system; separating the data into one or more data blocks; separating the one or more data blocks into data segments; inserting metadata for reconstructing the data into the one or more data blocks and data segments, the metadata including a transaction identifier associated with the data and a corresponding hash value for the one or more data blocks and data segments; transmitting the one or more data blocks and data segments to be reconstructed to a second device in the OWT system; reconstructing the one or more data blocks and data segments into a reconstructed file at the second device based on the metadata; and providing the reconstructed file to a third device in the OWT system.

[0090] For example, aspects of this disclosure have been described above with reference to block diagrams and / or operating instructions of methods, systems, and computer program products according to various aspects of this disclosure. Functions / actions indicated in a block may not occur in the order shown in any flowchart. For example, depending on the function / action involved, two consecutively shown blocks may actually be executed substantially simultaneously, or sometimes the blocks may be executed in reverse order.

[0091] The descriptions and illustrations of one or more aspects provided in this application are not intended to limit or restrict the scope of the claimed disclosure in any way. The aspects, examples, and details provided in this application are considered sufficient to convey ownership and enable others to make and use the best mode of the claimed disclosure. The claimed disclosure should not be construed as limited to any aspect, example, or detail provided in this application. Various features (structural and methodological) are intended to be selectively included or omitted, whether shown and described in combination or separately, to produce embodiments with a particular set of features. Having provided the descriptions and illustrations of this application, those skilled in the art can contemplate variations, modifications, and substitutions falling within the spirit of the broader aspects of the general inventive concept embodied in this application without departing from the broader scope of the claimed disclosure.

Claims

1. A system (100) comprising: Processing system (602); as well as A memory (604) coupled to the processing system (602) includes computer-executable instructions that, when executed, perform operations including: At the first device in the One-Way Transfer (OWT) system, the file is split (304) into multiple data blocks; Each of the plurality of data blocks is separated (306) into a plurality of data segments; Provide (310) the plurality of data blocks and the plurality of data segments to the second device in the OWT system; and Error correction coding (312) is applied to data blocks in the plurality of data blocks or data segments in the plurality of data segments.

2. The system (100) according to claim 1, wherein the first device is located in a first computing environment of the OWT system, and the second device is located in a second computing environment of the OWT system, wherein the first computing environment is different from the second computing environment.

3. The system (100) according to claim 2, wherein the first computing environment is a low-trust environment, and wherein devices in the first computing environment are not trusted by devices in the second computing environment.

4. The system (100) according to claim 1, wherein the first device provides the plurality of data blocks and the plurality of data segments to the second device using the User Datagram Protocol (UDP).

5. The system (100) according to claim 1, wherein the first device and the second device are located in the same physical location.

6. The system (100) of claim 1, wherein the number of the plurality of data blocks or the size of the plurality of data blocks is based on the size of the file.

7. The system (100) of claim 1, wherein the size of the plurality of data segments is based on the maximum transmission unit (MTU) of the protocol data unit used to transmit data through the OWT system.

8. The system (100) of claim 1, wherein separating the file into the plurality of data blocks includes inserting metadata for reconstructing the file into the plurality of data blocks.

9. The system (100) of claim 8, wherein the metadata includes: A transaction identifier for a request to transfer the file through the OWT system; as well as The data block number for each of the plurality of data blocks.

10. The system (100) of claim 9, wherein the metadata further comprises at least one of the following: The file identifier for the file in question; The file format or file type of the file; or For the content or section identifier of the file.

11. The system (100) of claim 1, wherein applying the error correction includes applying erasure coding to at least one of the plurality of data blocks or the plurality of data segments.

12. A system (100) comprising: Processing system (602); as well as A memory (604) coupled to the processing system (602) includes computer-executable instructions that, when executed, perform operations including: At the first device in the One-Way Transmission (OWT) system, error correction (314) is performed on the data segments of a file that has been separated into multiple data segments, the data segments being included in the multiple data segments; The plurality of data segments are reconstructed (316) into a reconstructed file based on the metadata inserted into the plurality of data segments; and The reconstructed file (318) is transmitted to the second device in the OWT system.

13. The system (100) of claim 12, wherein the plurality of data segments of the file are transmitted to the first device using User Datagram Protocol (UDP).

14. The system (100) according to claim 12, further comprising: Before performing the error correction on the data segment, it is determined that the necessary number of the plurality of data segments have not yet been received by the first device; as well as The data segment is identified as one of the plurality of data segments that have not yet been received by the first device.

15. The system (100) according to claim 14, wherein the necessary quantity is: Corresponding to the percentage of the plurality of data segments; or It indicates that no more than a certain number of consecutive data segments have not been received by the first device.

16. The system (100) of claim 12, wherein performing the error correction (314) on the data segment comprises: The data segment is retrieved from the third computing device, which then transmits the plurality of data segments to the first device. or The data segment is retrieved from a fourth device, which is implemented in the computing environment of the first device as part of a data redundancy scheme.

17. The system (100) of claim 12, wherein performing the error correction (314) on the data segment comprises: The data segments are recreated based on redundant information in one or more of the plurality of data segments received by the first device.

18. The system (100) of claim 12, wherein the metadata inserted into the plurality of data segments includes data segment offset values ​​used to determine the sequence order of the plurality of data segments.

19. The system (100) of claim 12, wherein reconstructing (316) the plurality of data segments into the reconstructed file includes removing the metadata from the plurality of data segments.

20. A method (400) comprising: Receive (402) data at the first device in the One-Way Transmission (OWT) system; The data is separated (404) into one or more data blocks; Separate the one or more data blocks (408) into data segments; Metadata for reconstructing the data is inserted (406, 410) into the one or more data blocks and the data segment, the metadata including a transaction identifier associated with the data and a corresponding hash value for the one or more data blocks and the data segment; Transmit (414) the one or more data blocks to be reconstructed and the data segments to the second device in the OWT system; Based on the metadata, the one or more data blocks and the data segments are reconstructed (316) into a reconstructed file at the second device; as well as Provide the reconstructed file (318) to a third device in the OWT system.

Images