Multiple protocol data transport

Methods, media and systems are disclosed in which data is transferred from a data source apparatus to an application of a data receiving apparatus using both a first protocol and a second protocol. The data receiving apparatus identifies data received via the second protocol that has not been received via the first protocol, and delivers the identified data received via the second protocol to the application.

BACKGROUND

Time-sensitive or real-time data such as video data, audio data, accelerometry data, sensor data (e.g. electrocardiogram data), etc. is typically streamed using an unreliable networking protocol. Unreliable networking protocols assume that error checking and correction are either not necessary or are performed by another layer of the software stack such as the application receiving the data. Thus, data sent via an unreliable networking protocol may arrive out of order, appear duplicated, or go missing without notice. Time-sensitive or real-time applications often use unreliable networking protocols because in such applications data that is lost, missing or discarded is preferable to using data that has arrived late or otherwise delayed. In other applications (e.g. downloading a file) receiving delayed data is preferable to lost, missing or discarded data. As a result, such applications tend to use a reliable networking protocol to ensure data delivery despite incurring additional latency and overhead.

DETAILED DESCRIPTION OF THE DRAWINGS

In the following description, numerous specific details such as logic implementations, opcodes, means to specify operands, resource partitioning/sharing/duplication implementations, types and interrelationships of system components, and logic partitioning/integration choices are set forth in order to provide a more thorough understanding of disclosed embodiments. However, additional embodiments may be practiced without such specific details of the disclosed embodiments. In other instances, control structures, gate level circuits and full software instruction sequences have not been shown in detail in order not to obscure other aspects of the disclosed embodiments.

Disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. Disclosed embodiments may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by one or more processors. A machine-readable medium may include any mechanism for storing information in a form readable by a machine (e.g., a computing device). For example, a machine-readable medium may include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; and other data storage devices.

Referring now toFIG. 1, an embodiment of a system100is shown that includes a data source apparatus110coupled to a data receiving apparatus130via a network150. In one embodiment, the data source apparatus110transmits data over the network150to the data receiving apparatus130using both an unreliable protocol151and a reliable protocol152. Thus, the data receiving apparatus130receives data from the data source apparatus110over the network150via both the unreliable protocol151and the reliable protocol152.

By transferring data via the reliable protocol152, the data source apparatus110and/or the data receiving apparatus130in one embodiment ensures reliable transport of data between the data source apparatus110and the data receiving apparatus130. In particular, reliable transport of data refers to the notion that data transmitted via the reliable protocol152eventually arrives at its destination intact or if by chance data is unable to be delivered to the destination the transmitting device is informed that the data was not delivered. For example, data may fail to reach the data receiving apparatus130if the data transmitting apparatus110, the data receiving apparatus130, or an intermediary link of the network150loses connectivity. Other causes may also prevent delivery such as power outages, denial of service attacks, network congestion, etc. However, in properly maintained environments such causes should be exceptional and to the extent such causes prevent delivery of the data, the data source apparatus110via the reliable protocol152is made aware that the transfer of data has failed.

Per the reliable protocol152, the data source apparatus110and the data receiving apparatus130may take various actions in order to maintain reliability, integrity, and ordering of the data being transferred via the reliable protocol152. For example, the data receiving apparatus130may acknowledge successful receipt of data and/or may request retransmission of data not received via the reliable protocol152. The data source apparatus110may generate and transmit checksums and/or error correction codes for data transmitted via the reliable protocol152. The data receiving apparatus130may use such checksums and/or error correction codes to verify and/or correct data received via the reliable protocol152. In particular, the data receiving apparatus130may correct the data using error correction codes if a correctable error is detected. Conversely, the data receiving apparatus130may request retransmission of data having a detected uncorrectable error.

Per the reliable protocol152, the data source apparatus110and the data receiving apparatus130may further ensure data is delivered to an application of the data receiving apparatus130in a specified order such as the order in which the data was transmitted by the data source apparatus110. In particular, the data source apparatus110may transmit data items with associated metadata that identifies a specified order for the data items such as the order in which the data items were transmitted. The data receiving apparatus130based upon the received metadata may identify data items that have been received before earlier data items of the specified order. In response to such data items received out of order, the data receiving apparatus130per the reliable protocol152may store such data items until earlier data items are received and the data items can be delivered to the application in the order specified by the data source apparatus110. In some embodiments, the data receiving apparatus130may discard data items received out of order and request the data source apparatus110resend such data items. By requesting retransmission of such data items, the data receiving apparatus130may reduce or eliminate storage requirements for out of order data items awaiting receipt of earlier data items before they can be delivered to the application in the specified order.

In one embodiment, the reliable protocol152is implemented using the Transmission Control Protocol (TCP) of the Internet Protocol (IP) Suite. In another embodiment, the reliable protocol152is implemented using a database replication protocol such as the database replication protocol used by the Microsoft® SQL Server® 2008. However, it should be appreciated that other reliable transport protocols may be used to implement the reliable protocol152.

While the data source apparatus110and data receiving apparatus130perform various actions to ensure reliability, integrity and order of data transferred via the reliable protocol152, the data source apparatus110and data receiving apparatus130forego such actions when transferring data via the unreliable protocol151. As such, transferring data items via unreliable protocol151may result in the data receiving apparatus130receiving data items out of order, receiving duplicates of the same data item, failing to receive some data items transmitted by the data source apparatus110, and receiving data items having errors. Moreover, per the unreliable protocol151, the data receiving apparatus130may simply discard data received with errors without informing the data source apparatus110and without requesting retransmission of such data items. Further, the data receiving apparatus130per the unreliable protocol151may successfully receive data items without informing the data source apparatus110or otherwise acknowledging the receipt of such data items. Accordingly, the data source apparatus110per the unreliable protocol151in one embodiment is unable to determine whether a particular data item transferred via the unreliable protocol151in fact was received by the data receiving apparatus130. In one embodiment, the data source apparatus110and the data receiving apparatus130use the User Datagram Protocol (UDP) of the IP Suite for the unreliable protocol151. However, other unreliable protocols may be used by some embodiments.

An advantage of the unreliable protocol151is that it typically incurs lower processing overhead, lower network traffic and lower latency than the reliable protocol152, but at the expense of some data items not reaching their destination intact or not reaching their destination at all. While data loss may be undesirable or unacceptable for some applications, data loss or missing data may be permissible or even preferable for other applications such as time-sensitive applications and/or real-time applications. For example, a real-time audio/video teleconferencing application has little need for audio and/or video data that arrives late. A real-time audio/video teleconferencing application basically presents audio and video data to users at a receiving end in real time and preferable with minimal delay from when such audio and video data was captured at the transmitting end. A teleconferencing application generally does not wait for data items to be retransmitted or for data items that have been delayed as such waiting generally introduces undesirable lag between transmitting and receiving ends. Moreover, a teleconferencing application generally does not present delayed audio or video data since presentation of such delayed data generally results in a more perceptible glitch in the audio and/or video presentation than simply dropping such delayed data. Thus, applications that can accept lost or missing data items, such as real-time applications and/or time sensitive applications, commonly use an unreliable protocol in order to enjoy lower latency, lower processing overhead, and better network efficiency provided by such protocols in comparison to reliable protocols.

While reliable protocols are desirable for certain applications and unreliable protocols are desirable for other applications, there are still applications for which transmitting data items solely via an unreliable protocol or solely via a reliable protocol is not ideal. For example, applications in which a reliable, low latency protocol is required or desired may not be adequately addressed solely with a reliable protocol or an unreliable protocol. For example, in the realm of telemedicine, the data source apparatus110may obtain electrocardiograph signals of a patient and may transfer such electrocardiograph signals to the data receiving apparatus130for real-time display at a remote location. In such a telemedicine application, a doctor at the remote site may desire both a real-time display of the electrocardiograph signals and the ability to review the electrocardiograph in more detail at a later time. In order to support such desires, the data source apparatus110in one embodiment transmits data items to the data receiving apparatus130using both the unreliable protocol151and the reliable protocol152. Transmitting via the unreliable protocol151permits real-time, low latency display of the data items at the data receiving apparatus130. Transmitting via the reliable protocol152ensures that the data receiving apparatus130receives all the data items representing the electrocardiograph even if one or more data items are delayed. Thus, data items dropped by the unreliable protocol151may be replaced by corresponding data items of the reliable protocol152to permit a more detailed analysis of the electrocardiograph in a non-real time fashion.

While a telemedicine example has been presented above, the parallel or pseudo parallel transfer of data via the unreliable protocol151and the reliable protocol152may be useful for a wide range of applications. As such, the data source apparatus110and the data receiving apparatus130may in practice be implemented by a wide range of network enabled devices. For example, the data source apparatus110and data receiving apparatus130may correspond to netbook, laptop, desktop, server, or other types of computing platforms. The data source apparatus110may also correspond to various types of monitoring equipment such as various types of medical equipment, networking equipment, diagnostic equipment, etc. Similarly, the data receiving apparatus130may correspond to various types of presentation equipment such as medical display monitors, diagnostic display monitors, personal data assistants, mobile telephones, etc. which are capable of receiving data via the unreliable protocol151and the reliable protocol152.

Referring further toFIG. 1, hardware aspects of an embodiment of the data source apparatus110and the data receiving apparatus130are shown. In particular, the data source apparatus110may include a processor112, storage114, data sources116, network interface118and other I/O devices120. The processor112may be a general purpose processor such as a Core® 2 processor manufactured by Intel Corporation that is capable of executing instructions and controlling operation of the data source apparatus110based upon the execution of such instructions. In other embodiments, the processor112may comprise other types of processors such as application specific processors and micro-controllers that are operable to control operation of the data source apparatus110.

The storage114may store data and instructions to be processed by the processor112. Depending upon a given platform, the storage114may include various types of storage devices. In particular, the storage114may include volatile memory devices such as Synchronous Dynamic Random Access Memory (SDRAM) devices, Dynamic Random Access Memory (DRAM) devices, RAMBUS Dynamic Random Access Memory (RDRAM) devices, and/or other volatile memory devices. Further, the storage114may include non-volatile memory devices such as, for example, flash memory devices, read only memory (ROM) devices, Electrical Erasable Programmable ROM (EEPROM) devices, battery backed RAM devices, and/or other non-volatile memory devices. The storage114may also include mass storage devices such as floppy disk drives, hard drive disks, compact disk drives, and digital versatile disk (DVD) drives to store data and/or instructions in a non-volatile manner.

The data source apparatus110further includes one or more data sources116that generate or otherwise provide data items. The data sources116may comprise one or more application-specific sources of data and may include software sensing components and/or hardware sensing components. For example, the data sources116may include audio libraries, video libraries, audio capture devices such as a microphone, video capture devices such as a camera, and/or various types of sensors that sense or otherwise measure characteristics of their surrounds. For example, the sensors may include various types of biosensors that obtain measurements of biological features of a patient.

Besides providing and/or otherwise generating data items, the data sources116in one embodiment may also provide or otherwise associate with each data item metadata that uniquely identifies that data item in a data set. Such metadata may include a session identifier (ID) that identifies a session associated with the sensed data items, a source identifier (ID) that identifies a person, place or thing being sensed, a sensor identifier (ID) that identifies a sensor of the data sources116from which the data item originated, a channel identifier (ID) that identifies a channel via which the data item was sensed, a data type, and/or a timestamp that indicates a time at which the data item was sensed.

The network interface118operatively couples the data source apparatus110to the network150. As such, the network interface118may include one or more network interface controllers, transceivers, and/or antennas that permit transmitting and receiving data over one or more wired and/or wireless links between the data source apparatus110and the network150. In one embodiment, the network interface118is coupled to the network150via a single wired link such as a CAT 5 networking cable over which the network interface118transmits data using the unreliable protocol151and the reliable protocol152. However, in other embodiments, the network interface118may be coupled to the network150using multiple wired and/or wireless links. Furthermore, the data source apparatus110may configure the network interface118such that data transmitted via the unreliable protocol151uses different links to and/or across the network150than data transmitted via the reliable protocol152.

While depicted as a single entity inFIG. 1, the network150may include one or more interconnected and/or separate networks. In particular, the network150may implement a heterogeneous network that includes two or more local area networks, wide area networks, cellular networks, or other communication networks. For example, the network150may comprise IEEE 802.3 (Ethernet) networks, IEEE 802.11 (Wi-Fi) networks, IEEE 802.16 (WiMAX) networks, Universal Mobile Telecommunications System (UMTS) networks, and/or Global System for Mobile communications (GSM) networks. Due to being comprised of multiple networks, the network150in one embodiment may provide multi-path redundancy for the transfer of data items across the network150. In particular, the network150may ensure that data items transferred via the unreliable protocol151are routed across a different path of the network150than data items transferred via and reliable protocol152.

Finally, the data source apparatus110may include various other I/O devices120via which information may be entered into the data source apparatus110and/or output from the data source apparatus110. Such I/O devices120may include keyboards, keypads, mice, touch screens, cameras, microphones, video displays, light emitting diodes, printers, etc. While not depicted, the data source apparatus110may further include various I/O controllers such as, for example, Parallel AT Attachment (ATA) interface controllers, Serial ATA interface controllers, Small Computer System Interface (SCSI) controllers, graphics controllers, Universal Serial Bus (USB) controllers, Peripheral Component Interconnection (PCI) Express controllers, audio controllers, keyboard controllers and the like in order to controller corresponding devices of the storage114, data sources116, network interface118, and other I/O devices120.

As shown inFIG. 1, the data receiving apparatus130may be implemented in a manner similar to the data source apparatus110. In particular, the data receiving apparatus130may include a processor132, storage134, network interface138, and other I/O device140. In one embodiment, the processor132, storage134, network interface138and other I/O devices140may be implemented in a manner similar to corresponding components of the data source apparatus110.

Referring now toFIG. 2, a software and data flow diagram of an embodiment of the system100is shown. As shown, the data receiving apparatus110may include a source application212, a data collector214, a data writer216, an unreliable sender218, data set store220, and a reliable sender222. In one embodiment, the source application212, the data collector214, the data writer216, the unreliable sender218, and the reliable sender222are implemented via firmware and/or software executed by the data source apparatus110. However, it should be appreciated that one or more of the illustrated blocks ofFIG. 2may be implemented and/or partially implemented using various hardware components.

As shown, the data receiving apparatus130may include a receiving application262, a data reader266, an unreliable receiver268, a data and metadata store270, and a reliable receiver272. In one embodiment, the receiving application262, the data reader266, the unreliable receiver268, and the reliable receiver272are implemented via firmware and/or software executed by the data receiving apparatus130. However, it should be appreciated that one or more of the illustrated blocks ofFIG. 2may be implemented and/or partially implemented using various hardware components.

The source application212provides a server or service that is responsible for handling data received by the data collector214and potentially presenting such data locally via an I/O device120of the data source application110. For example, if the data source apparatus110implements an electrocardiograph machine, then the source application212may permit a technician to control or otherwise calibrate the electrocardiograph machine via a user interface of the I/O devices120. Further, the source application212may generate and display electrocardiograph data on a video monitor of the I/O device120. Besides the local handling of the data items230, the source application212may further control the data writer216, unreliable sender218, and reliable sender222in order to control the transfer of the collected data to the receiving application262of the data receiving apparatus130.

In support of such functions, the data collector214receives data items230and associated metadata232from data sources116. The data collector214further provides the collected data items230and associated metadata232to the source application212and the data writer216. The data writer216receives the data items230and associated metadata232from the data collector214. The data writer216stores the received data items230and associated metadata232in a data set store220of the data source apparatus110. In one embodiment, the data source apparatus110implements the data set store220as one or more data structures in memory devices of the storage114. As such, the data writer216updates such data structures to account for the received data items230and associated metadata232. In another embodiment, the data source apparatus110implements the data set store220as one or more database tables in a database storage device of the storage114. In such an embodiment, the data writer216updates such database tables to account for the data items230and associated metadata232.

The data writer216further provides the data items230and associated metadata232to the unreliable sender218in the order in which the data items230were generated by the data sources116shown inFIG. 1. In one embodiment, the data sources116provide generated data items230with metadata232that includes a timestamp that identifies the time at which an associated data item230was generated. As such, the data writer216may use such timestamps in order to present the data items230to the unreliable sender218in the order in which they were generated.

The unreliable sender218in turn transfers the data items230and associated metadata232to the unreliable receiver268of the data receiving apparatus130via the unreliable protocol151. Moreover, the reliable sender222transfers data items230and associated metadata232to the reliable receiver272via the reliable protocol152. In one embodiment, the reliable sender222uses the timestamps associated with the data items230to transfer the data items230via the reliable protocol152in the order in which the data items230were generated.

The unreliable receiver268of the data receiving apparatus130receives data items230and associated metadata232from the unreliable sender218via the unreliable protocol151. Moreover, the unreliable receiver268of the data receiving apparatus130provides the data reader266with successfully received data items230and their associated metadata232. As explained above in regard to unreliable protocols, the unreliable receiver268per the unreliable protocol151foregoes actions of the reliable protocol152associated with ensuring reliability, integrity and order. As a result, the unreliable receiver268may receive data items230in an order that differs from the order in which the data items230were generated by the data sources116and may transfer the data items230and associated metadata232to the data reader266in the order in which the data items230and the associated metadata232were received by the unreliable receiver268.

The reliable receiver272of the data receiving apparatus130similarly receives data items230and associated metadata232from the reliable sender222via the reliable protocol152. In one embodiment, the data receiving apparatus130implements the data and metadata store270as one or more data structures stored in memory devices of the storage134. Accordingly, the reliable receiver272in such an embodiment updates the data structures of the data and metadata store270to account for the data items230and associated metadata232received via the reliable protocol152. In another embodiment, the data and metadata store270are implemented as one or more database tables of a database storage device of the storage134. The reliable receiver272in such an embodiment updates the tables of the database storage device to account for the received data items230and associated metadata232.

As explained above in regard to reliable protocols, the reliable receiver272per the reliable protocol152performs actions that ensure reliability, integrity and order. As a result, while the reliable receiver272may receive data items230in an order that differs from the order in which the data items230were generated by the data sources116, the reliable receiver272ensures that the data items230and associated metadata232are transferred to data and metadata store270in the order in which the data items230were generated by the data sources116.

The data reader266may receive data items230and associated metadata232from the unreliable receiver268and transfer such received data items230and associated metadata232to the receiving application262. The data reader266may further update the data structures of the data and metadata store270to account for the data items230and associated metadata232received via the unreliable protocol151. As explained in more detail below in regard toFIGS. 3 and 4, the data reader266may further deliver data items230and associated metadata232to the receiving application262that were received via the reliable receiver272but have not been received by the unreliable receiver268.

In one embodiment, data received via the unreliable receiver268may be delivered to the receiving application262out of order. Accordingly, the receiving application262in one embodiment is implemented to handle receipt of data items230out of order. For example, in an embodiment in which the receiving application262is a monitoring application, the receiving application262may provide a scrolling display of incoming data items230. The receiving application262may further generate the display such that gaps appear whenever data is lost or otherwise discarded by the unreliable protocol151. The receiving application262may then fill in these gaps with data items230that are eventually received via the reliable protocol152. In some embodiments, the application may be unaware of whether data items230and associated metadata232were received via the reliable protocol152or unreliable protocol151.

Referring now toFIG. 3, additional details regarding a method for receiving data using both reliable and unreliable protocols is depicted. In one embodiment, the method is implemented with an unreliable receiving process or thread and a separate reliable receiving process or thread. Such an implementation enables the data receiving apparatus130to process incoming messages via the unreliable protocol151and incoming messages via the reliable protocol152in a parallel or pseudo parallel manner. Despite the parallel nature of the unreliable and reliable receiving of messages, the following first describes the operation of the unreliable receiving process and then the reliable receiving process in order to simplify the description.

As shown, the data receiving apparatus130at block310may start the unreliable receiving process. In one embodiment, the unreliable receiving process implements the unreliable receiver268and a portion of the data reader266. However, it should be appreciated that in other embodiments the unreliable receiver268and the data reader266may be implemented as separate processes. At block312, the unreliable receiver268may determine whether a message has been received via the unreliable protocol151. If a message has not been received, then the unreliable receiving process at block322may determine whether to stop processing incoming messages. For example, the receiving application262or an underlying operating system of the data receiving apparatus130may request the unreliable receiving process to shutdown or otherwise terminate execution. If the unreliable receiving process determines not to shutdown, then the unreliable receiving process may return to block312to permit the unreliable receiver268to check for a message from the network150. Otherwise, the unreliable receiving process proceeds with the shutdown.

If at block312, the unreliable receiver268determines that a message has been received via the unreliable protocol151, then the unreliable receiver268presents the data items230and associated metadata232to the data reader266. At block314, the data reader266determines whether the message includes data items230that have not been previously received. In one embodiment, the data reader266determines whether data items230of the message are new data items by analyzing metadata232associated with the data items230and metadata232of the data and metadata store270which records metadata232of previously received data items230. If the data reader266determines that the data items230of the message are not new, then the unreliable receiving process proceeds to block322to determine whether to shutdown.

If the data reader266determines that the data items230of the message have not been previously received, then the data reader266at block316records the data items230and associated metadata232in the data and metadata store. In particular, the data reader266may update data structures of the data and metadata store270to account for the newly received data items230and associated metadata232. At block320, the data reader266further provides the newly received data items230and associated metadata232to the receiving application262. The unreliable receiving process may again determine at block322whether to shutdown. If the unreliable receiving process determines not to shutdown, then the unreliable receiving process may return to block312in order to permit the unreliable receiver268to receive additional messages via the unreliable protocol151.

The reliable receiving process operates in a similar manner as the unreliable receiving process. In particular, the data receiving apparatus130at block350may start the reliable receiving process. In one embodiment, the reliable receiving process implements the reliable receiver272and a portion of the data reader266. However, it should be appreciated that in other embodiments the reliable receiver272and the data reader266may be implemented as separate processes. At block352, the reliable receiver272may determine whether a message has been received via the reliable protocol152. If a message has not been received, then the reliable receiver272at block362may determine whether to stop processing incoming messages. If the reliable receiver272determines not to shutdown, then the reliable receiver272may return to block352and check for a message from the network150. Otherwise, the reliable receiver272proceeds with the shutdown.

If at block352, the reliable receiver272determines that a message has been received via the reliable protocol152, then the reliable receiver272determines at block354whether the message includes data items230that have not been previously received. In one embodiment, the reliable receiver272determines whether data items230of the message are new data items by analyzing metadata232associated with the data items230and metadata232of the data and metadata store270which records metadata232of previously received data items230. If the reliable receiver272determines that the data items230of the message are not new, then the reliable receiving process proceeds to block362to determine whether to shutdown.

If the reliable receiver272determines that the data items230of the message have not been previously received, then the reliable receiver272at block356records the data items230and associated metadata232in the data and metadata store270. In particular, the reliable receiver272may update data structures of the data and metadata store270to account for the newly received data items230and associated metadata232. At block360, the data reader266may identify the newly received data items230of the data and metadata store270and may provide such newly received data items230and associated metadata232to the receiving application262. The reliable receiving process again determines at block362whether to shutdown. If the reliable receiving process determines not to shutdown, then the reliable receiving process may return to block352in order to permit the reliable receiver272to receive additional messages via the reliable protocol152.

Referring now toFIG. 4, details regarding another method for receiving data using both reliable and unreliable protocols is depicted. Aspects of the method ofFIG. 4are similar to aspects of the method ofFIG. 3. However, the method ofFIG. 4utilizes a database replication protocol as the reliable protocol152in order to reliable transfer data items230from a database of the data set store220to a database of the data and metadata store270.

As shown, the data receiving apparatus130at block410may start the unreliable receiving process. At block412, the unreliable receiver268may determine whether a message has been received via the unreliable protocol151. If a message has not been received, then the unreliable receiving process at block422may determine whether to stop processing incoming messages. If the unreliable receiving process determines not to shutdown, then the unreliable receiving process may return to block412to permit the unreliable receiver268to check for a message from the network150. Otherwise, the unreliable receiving process proceeds with the shutdown.

If at block412, the unreliable receiver268determines that a message has been received via the unreliable protocol151, then the unreliable receiver268presents the data items230and associated metadata232to the data reader266. At block414, the data reader266determines whether the message includes data items230that have not been previously received. In one embodiment, the data reader266determines whether data items230of the message are new data items by analyzing a previously received database table of the data and metadata store270. The previously received database table records metadata232of previously received data items230. If the data reader266determines that the data items230of the message are not new, then the unreliable receiving process proceeds to block422to determine whether to shutdown.

If the data reader266determines that the data items230of the message have not been previously received, then the data reader266at block416updates the previously received database table based upon the associated metadata232for the data items230to account for the received data items230. The data reader266further stores the data items230in a database of the data and metadata store270to record such data items230for future access. In some embodiments, storing the received data items230in the database may eliminate the need for the reliable sender222to later replicate those specific data items to the reliable receiver272. At block420, the data reader266further provides the newly received data items230and associated metadata232to the receiving application262. The unreliable receiving process may again determine at block422whether to shutdown. If the unreliable receiving process determines not to shutdown, then the unreliable receiving process may return to block412in order to permit the unreliable receiver268to receive additional messages via the unreliable protocol151.

The reliable receiving process operates in a manner that is somewhat different from the unreliable receiving process. In a separate thread (not pictured), the data receiving apparatus130or the data source apparatus110may periodically reconcile differences between the data set store220in the data source apparatus110and the data and metadata store270in the data receiving apparatus130, in some cases causing new data to be replicated to the data and metadata store270. In another thread, the data receiving apparatus130at block450may start the reliable receiving process. At block452, the reliable receiver272queries the data and metadata store270of the data receiving apparatus130via a database query interface for data items that were not previously received by the data reader266. At block454, the reliable receiver272determines whether the database query resulted in any new data items230being obtained. If the reliable receiver272determines that new data items230were received as a result of the database query, then the reliable receiver272at block456updates the previously received database table based upon the associated metadata232for the newly received data items230in order to account for the received data items230.

At block460, the data reader266may identify any newly stored data items230based upon associated metadata232and may provide such new data items230and associated metadata232to the receiving application262. The reliable receiving process again determines at block462whether to shutdown. If the reliable receiving process determines not to shutdown, then the reliable receiving process may return to block452in order to permit the reliable receiver272to query the database of the data source apparatus110for new data items.

While the disclosure has been illustrated and described in detail in the drawings and foregoing description, such an illustration and description is to be considered as merely illustrative and not restrictive in character, it being understood that only illustrative embodiments have been shown and described and that all changes and modifications that come within the spirit of the disclosure are desired to be protected.