The present invention relates generally to a system and method for communications in a computing environment, and more particularly to a system and method for providing reliable file transfers using protocol scripting in a computing environment with a network with multiple communications protocols.
In many computing environments, it can be common to have many devices communicating with one another while using different communications protocols. In order to provide interoperability, software or hardware bridges are required as protocol translators to permit the devices using the different communications protocols to communicate with each other and to transfer files and data. The bridges translate communications in one communications protocol into communications in another communications protocol.
When the communications protocols are designed to properly handle situations that may arise in the transfer of data and files (collectively referred to as file transfers), such as errors, time-outs, re-transmissions, and so forth, the communications between devices can be straight forward and can occur with relatively small delay and at low latency. These communications protocols can be said to be network aware. However, when a communications protocol is not network aware, meaning that they may not be able to gracefully handle events such as transmission errors, time-outs, and so on, then communications between devices may not properly complete when one (or more) of these events occur during a transmission. For example, if a transmission occurs between two devices, wherein the two devices (a first and a second device) use different communications protocols (therefore, a bridge is required), and if an error were to occur during the transmission between the first device and the bridge and if a second communications protocol used between the bridge and the second device was not network aware (a first communications protocol being used between the first device and the bridge), then the missing information (due to the error in the transmission) may not be delivered to the second device since the second communications protocol could not properly handle the erroneous transmission (and possibly the subsequent re-transmission).
One technique that can be used is to simply retransmit failed transmissions. When a transmission between devices fail, then the transmission is repeated until the transmission completes successfully.
Another technique that can be used is to decrease the amount of data that is transferred, i.e., reduce the transmit data block size. Reducing the transmit data block size can help to improve the performance by reducing the amount of time that the data is in the network, thereby reducing the probability of errors. Additionally, the re-transmission of a small data block can occur more rapidly than the re-transmission of a large data block. Therefore, if an error were to occur, the recovery can take place more rapidly.
Yet another technique that can be used would be to upgrade the communications protocols that are not network aware. By upgrading the non-network aware communications protocols, graceful recovery to file transfer errors, time-out, and so forth can be provided to all devices in the computing environment.
One disadvantage of the prior art is that the repeating of the transmission until it succeeds does not correct the problem and that the number of repeated transmissions can be very large if there is a large number of errors in the transmissions. The repeated transmissions can also greatly increase the effective transfer time of a file transfer.
A second disadvantage of the prior art is that certain critical transfers may not be permitted since the cost of a failed transmission can be too high. Therefore, special procedures may be needed to perform the critical transfers. For example, a transfer performing an upgrade in the firmware of a device should not be attempted since a failed transfer can render the device inoperable. To accomplish the upgrade via a file transfer, it may then be necessary to connect the device to a separate communications network, wherein the communications is sufficiently reliable to perform the file transfer.
Yet another disadvantage of the prior art is that the use of small transmit data blocks can increase the communications overhead. High communications overhead can reduce the efficiency of the communications and reduce the overall file transfer rate.
Another disadvantage of the prior art is that some devices may not be upgradeable. Therefore, in order to use those devices, their non-network aware communications protocols will need to be maintained.
These and other problems are generally solved or circumvented, and technical advantages are generally achieved, by preferred embodiments of the present invention which provides for a system and method for providing reliable file transfers using protocol scripting in a computing environment with multiple communications protocols.
In accordance with a preferred embodiment of the present invention, a method encoding a file for transfer across multiple networks is provided. The method comprises logically joining adjacent networks with network aware communications protocols into composite networks, and then starting with an interface between a first composite network and a second composite network, creating a script file using communications protocol instructions used by the second composite network, wherein the communications protocol instructions are used to transfer the file across the second composite network. The creating is repeated at remaining interfaces between consecutive composite networks in a reversed order, starting at the destination.
In accordance with another preferred embodiment of the present invention, a method for transferring a file across multiple networks is provided. The method comprises creating a script file at a first device, transferring the script file to a network interface between the first device and a second device, executing the script file at the network interface, and informing the first device of the execution of the script file.
In accordance with another preferred embodiment of the present invention, a network hub comprising a first network interface, a second network interface, a processor, and a memory is provided. The first network interface is coupled to a first network connection and the second network interface is coupled to a second network connection. The processor is coupled to the first network interface and the second network interface, while the memory is coupled to the processor. The processor is configured to execute script commands provided by the first network connection to transfer data and instructions through the first network interface and the second network interface, while the memory is configured to store implementations of script commands, programs, and data.
An advantage of a preferred embodiment of the present invention is that a file transfer between devices can be broken up into multiple stages with buffering of the data being transferred at each stage, wherein a single stage involves the use of a single communications protocol without any translation. Therefore, the error handling built into the communications protocol can be used to handle events such as errors, time-outs, re-transmits, and so forth, with no interaction between the different communications protocols.
A further advantage of a preferred embodiment of the present invention is that the devices do not need to be upgraded to make use of network aware communications protocols. This permits the continued use of devices that cannot be upgraded, rather than requiring their replacement with newer devices.
Yet another advantage of a preferred embodiment of the present invention is that since the file transfers are now reliable, critical transfers, such as updates, can be performed. This can eliminate the need to perform special tasks to update devices, for example.
Another advantage of a preferred embodiment of the present invention is that the transmit data block size does not need to be reduced to improve transfer reliability. In fact, the transmit data block size can be increased to improve transfer data rates and times by reducing the overall communications overhead.
The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention. It should be appreciated by those skilled in the art that the conception and specific embodiments disclosed may be readily utilized as a basis for modifying or designing other structures or processes for carrying out the same purposes of the present invention. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the invention as set forth in the appended claims.
For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:
a and 2b are diagrams of a file transfer between a host computer and a client device with and without transmission errors;
a and 4b are diagrams of a file transfer between a host computer and client device over multiple networks using communications protocol scripting, according to a preferred embodiment of the present invention;
a and 6b are diagrams of the virtual links involved in communications protocol scripting in a computing environment with multiple bridges and the encapsulation of the file to be transferred in such a computing environment, according to a preferred embodiment of the present invention;
a and 7b are diagrams of sequences of events involved in the transfer of a file to and from a host computer, according to a preferred embodiment of the present invention; and
The making and using of the presently preferred embodiments are discussed in detail below. It should be appreciated, however, that the present invention provides many applicable inventive concepts that can be embodied in a wide variety of specific contexts. The specific embodiments discussed are merely illustrative of specific ways to make and use the invention, and do not limit the scope of the invention.
The present invention will be described with respect to preferred embodiments in a specific context, namely a computing environment wherein file transfers can take place between a host computer and a series of client devices (electronic calculators) over a transmission link comprising a wireless link and a proprietary wired link, wherein the communications protocol used on the proprietary wired link is not network aware. The invention may also be applied, however, to other computing environments, wherein devices communicate using multiple communications protocols, with some of the communications protocols being non-network aware.
With reference now to
With reference now to
When a direct transfer is used, the hub 120 can be used as bridge to translate a first communications protocol (used from the host computer 105 to the hub 120) into a second communications protocol (used from the hub 120 to the client device 110). Note that prior to arriving at the hub 120, the file may have been transferred over several network links and bridges. For example, from the host computer 105, the file may have been transferred to the access point 115 via a wired network link (network link 117 (
A problem that can arise with the hub 120 operating as a simple bridge is that if, due to an error or some other unforeseen delay, data being transferred from the host computer 105 to the hub 120 does not arrive at the expected time, the hub 120 could stop sending data to the client device 110, which could lead to the occurrence of a time-out. This may result in a failed transmission. Alternatively, the hub 120 could transmit NULL data to the client device 110, which can lead to the NULL data being erroneously used as actual data.
With reference now to
Out of the five blocks making up the file 205, the client device 110 only receives blocks “B1” 255, “B4” 270, and “B5” 275, with the transfers of blocks “B2” 260 and “B3” 265 timing out. Therefore, the transfer of the file 205 was unsuccessful and another attempt to transfer the file may be made. Note that the additional file transfer attempts may or may not be successful. If additional file transfer attempts continue to be unsuccessful, the file transfer may be aborted.
In many communications protocols, when a packet transmission fails (either through an error damaging the packet or the packet takes too much time to arrive at a destination), an attempt at retransmitting the packet can be made. In either case, it is possible that the packet successfully arrives at the destination (at the hub 120, for example) on the retransmission attempt. However, since there is a delay between the expected arrival time of the packet and its actual arrival time, timing constraints of the communications protocol used to transmit the packet from the hub 120 to the client device 110 can be violated. This can lead to a failed transfer.
With reference now to
The access point 115 can simply be represented by an access point firmware layer 315, which can be responsible for controlling the operation of the access point 115, including translating transmissions from a wireless communications protocol into a wired communications protocol and vice versa. The hub 120 can be logically partitioned into a hub firmware layer 320 and a bridging layer 322. The hub firmware layer 320 can be responsible for controlling the operation of the hub, while the bridging layer can be responsible for translating transmissions from a wireless communications protocol into a communications protocol consistent with the communications protocol by the client device 110. The client device 110 can be logically partitioned into a player application layer 325 and a login application layer 327. The player application layer 325 can be used to establish a virtual link to the host computer 105 and present data to a user of the client device 110, while the login application layer 327 can establish a session context for file transfers.
While a file transfer over several network links using a multitude of communications protocols may be unreliable due to differences in the way that events, such as errors, time-outs, re-transmissions, and so forth, are handled by the different communications protocols, a file transfer using a single communications protocol can be extremely reliable as long as the communications protocol has built-in error recovery or if the network has low error rates, since there are no potential inter-communications protocol incompatibilities when it comes to error handling. Communications protocol scripting, along with some potentially minor modifications to bridges, can be a way to exploit reliable file transfers using a single communications protocol to help make file transfers using multiple communications protocols reliable.
Communications protocol scripting can involve the encapsulation of the file to be transferred into a script file containing instructions of a communications protocol used by the network links over which the file will be transferred. For example, if a file is to be transferred over two network links, wherein each network link (a first and a second network link) communicates using a different communications protocol, then the file can be encapsulated into a script file containing instructions of a communications protocol used by the second network link and then the encapsulated file can be transferred over the first network link to a bridge using a communications protocol used by the first network link, which can then execute the instructions contained in the encapsulated file to transfer the file over the second network link.
In general, if the file is to be transferred over multiple network links that use a total of N unique communications protocols, then the file can be repeatedly encapsulated a total of N-1 times with the N-1 unique communications protocols in a reverse order, starting with the final communications protocol to be used and then moving in a reverse manner to the second communications protocol to be used. Note that it may not be necessary to encapsulate the file with an initial communications protocol since the initial transfer of the file to the first bridge will already be made using the initial communications protocol and it may not be necessary to provide the communications protocol instructions to the host computer 105. Then, as the encapsulated file is transferred from bridge to bridge, the bridge can execute the instructions that contain the encapsulated file to transfer the encapsulated file to a subsequent bridge. This can be repeated until the file arrives at its destination. Note that consecutive communications protocols that are network aware can be logically combined into a single communications protocol.
With reference now to
With the use of the communications protocol scripting, the hub 120 (or a bridge) can use native communications protocols without having to implement each possible communications protocol. This can reduce software and hardware requirements. Furthermore, the local execution of the communications protocol should preserve typical unit-to-unit timing and so forth, thereby enabling transfer reliability approaching that of a single communications protocol transfer.
With reference now to
Once all five blocks of the file 405 are buffered at the hub 120, the hub 120 can execute the instructions encapsulating the file 405. Since the transfer of the file 405 from the hub 120 to the client device 110 is over a wired connection, the likelihood of an error is very low and all five blocks are transferred successfully on the respective first attempts (shown as arrows 451, 452, 453, 454, and 455).
With reference now to
The software link 510 encompasses the network links that make use of a single non-network aware communications protocol. As shown in
With reference now to
The use of the two non-network aware communications protocols (on the network links between the bridges 606 and 607 and the bridge 607 and the client device 110) requires the host computer 105 to encapsulate the file to be transferred twice, a first time using the instructions of non-network aware communications protocol used on the network link between the bridge 607 and the client device 110 and a second time using the instructions of the non-network aware communications protocol used on the network link between the bridges 606 and 607. The presence of network aware communications protocols between the host computer 105 and the bridge 606 (the script link 610) can allow the host computer 105 to transfer the doubly encapsulated file to the bridge 606, then the bridge 606 can strip the first set of communications protocol instructions from the doubly encapsulated file and transfer the now singly encapsulated file to the bridge 607. The bridge 607 can then strip and execute the communications protocol instructions contained in the singly encapsulated file to transfer the un-encapsulated file to the client device 110.
With reference now to
In a network configuration wherein the source of the file to be transferred can initiate the transfer, a file transfer occurs in one direction, from the source (either the host computer 105 or the client device 110) to the destination (either the client device 110 or the host computer 105). However, in a network configuration wherein a single entity initiates all file transfers, a file transfer between the host computer 105 and the client device 110 can occur in one of two directions: from the host computer 105 to the client device 110 or from the client device 110 to the host computer 105. In such a configuration, the communications protocol scripting can differ slightly depending upon the source of the file to be transferred.
With reference now to
The transfer of a file from the host computer 105 to the client device 110 can begin with the host computer 105 transforming the file into a script file (block 705). The transformation of the file into a script file can involve the encapsulation of the contents of the file with communications protocol instructions that are compatible with the communications protocol used in the network link(s) between the hub 120 and the client device 110. Note that depending upon factors such as file size, script file size limits, and so forth, the host computer 105 may transform the file into one or more script files. After transforming the file into a script file, the host computer 105 can transfer the script file to the hub 120 (block 710) using the communications protocol of the network link between the host computer 105 and the hub 120. Note in transferring the script file to the hub 120, the host computer 105 (or a network interface located in the host computer 105) may have to execute instructions compatible with the communications protocol of the network link between the host computer 105 and the hub 120. However, since the host computer 105 is directly coupled to the network link (through the network interface), it should have, as part of its network stack, a native implementation of the communications protocol and therefore does not need the use of a script file to perform the file transfer.
After the script file has been transferred by the host computer 105 to the hub 120, the hub 120 can be instructed by the host computer 105 to execute the scripts contained in the script file (block 715). When the hub 120 executes the script file (block 720), the contents of the file can be transferred to the client device 110 (block 725). Since the hub 120 is directly connected to the client device 110, the hub 120 should have a native implementation of the communications protocol used to connect the client device 110 to the hub 120. Therefore, the communications between the hub 120 and the client device 110 will preserve the typical unit-to-unit timings involved in a typical transfer and a reliable transfer should be ensured. As the hub 120 finishes the execution of the script file, the hub 120 can notify the host computer 105 that it has successfully transferred the file to the client device 110 (block 730).
The transfer of a file from the client device 110 to the host computer 105, wherein the host computer 105 initiated the file transfer, is similar to the transfer of a file from the host computer 105 to the client device 110. The file transfer can begin with the host computer 105 preparing a script file (block 755). The script file can contain a request for the file from the client device 110. After preparing the script file, the host computer 105 can transfer the script file to the hub 120 (block 760). After the script file has been transferred to the hub 120, the host computer 105 can instruct the hub 120 to execute the script file (block 765).
When the hub 120 executes the script file (block 770), a request can be sent to the client device 110 to transfer the file to the hub 120. Upon receiving the request for the file, the client device 110 transfers the file to the hub 120 (block 775). In order to initiate the transfer of the file from the client device 110, the host computer 105 must be able to reference the file in some fashion. For example, the host computer 105 may specify a name for the file, a location (or locations) in memory where the file is stored, and so forth. After the hub 120 has received the file from the client device 110, the hub 120 informs the host computer 105 that the transfer of the file is complete (block 780). The host computer 105 can then retrieve the file from the hub 120 (block 785).
With reference now to
Coupled to the CPU 805 can be the memory, in the form of random access memory (RAM) 810 and read-only memory (ROM) 815. The RAM 810 can be used for temporary storage of programs, scripts, data, files, and so forth, that can be loaded into the hub 120 after it has been powered on. The ROM 815 can be used to permanently store programs, scripts, configuration information, and so on, that can be needed to ensure the immediate operation of the hub 120 after being powered on.
The ROM 815 may contain a minimum set of scripts that will allow the hub 120 to perform rudimentary file transfers with the host computer 105 and the client device 110. However, should additional functionality be desired, it can be possible to download additional scripts to the hub 120 from the host computer 105, into the RAM 810. Furthermore, the hub 120 can be provided the ability to support additional communications protocols via downloads from the host computer 105 into the RAM 810.
The hub 120 can feature two (or more) network interfaces 820 and 821. The network interfaces 820 and 821 can permit the hub 120 to communicate with other devices via network links. Since the hub 120 can operate as an interface between different networks, the hub 120 features at least two network interfaces, with a network interface being necessary for each type of network connecting to the hub 120. Note that a network interface can permit the connection of more than one device to the hub 120. For example, more than one client device 110 can be connected to the hub 120. Note that the hub 120 may also contain other hardware and software that can function as “glue” hardware and software to ensure the proper operation of the hub 120. For simplicity purposes, the glue hardware and software is not shown in
A preferred embodiment of the present invention permits the exchange of files between a host computer and electronic calculators that are wirelessly coupled together, wherein the electronic calculators are connected to a wireless hub via a proprietary point-to-point network that does not have full network awareness and the wireless hub is connected to the host computer. As a result, the simple transfer of files by directly transferring the files from the host computer can be unreliable due to inability of the proprietary point-to-point communications protocol to interoperate with the wireless network with its potentially large network latencies and potentially high error rates.
The use of communications protocol scripting allows the host computer to transfer the files to and from the wireless hub via a network aware communications protocol that is capable of good performance in the face of the performance problems associated with wireless communications, then the wireless hub can directly communicate to the electronic calculators using the proprietary point-to-point communications protocol over a wired network that does not have the same performance problems.
The wireless hub can have stored in its ROM (similar to the ROM 815 (
The scripts themselves can be a collection of commands that can be executed by the wireless hub. Upon execution in the wireless hub, the scripts can be translated into data and instruction flows across the network link connecting the wireless hub to the electronic calculator. Examples of the commands include: operations on data commands (SEND, RECV, RSET), program flow control commands (JUMP, WAIT, IF_THEN, IF_THEN_ELSE, WHILE, BREAK, CONT), host interaction commands (POST, STAT), and variable manipulation commands (SET, INC, DEC, TEST, BLOCKDATA).
Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the invention as defined by the appended claims.
Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification. As one of ordinary skill in the art will readily appreciate from the disclosure of the present invention, processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed, that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized according to the present invention. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.