Method and Apparatus for Downloading a File to a Remote Unit

The invention relates to data communication and more particularly to downloading of files to a computer.

A known data communication system has multiple computers connected to multiple peripheral data buses for communicating data to multiple ports on a single peripheral unit in order to provide higher reliability of data communication by redundant data paths. In systems having redundant buses, one bus at a time is used to communicate with the peripheral unit while the other bus or buses are not used. Only when the one bus is not selected as the primary bus or is not available is one of the other buses used for communicating data into the peripheral unit. This is the redundancy advantage. However, if the peripheral has two or more ports, only one is being used, leaving at least one port and at least one data bus unused. This is a major waste of data communication bandwidth, the result of which is a longer total time to transfer data, such as a file or group of files, to a peripheral.

It is an object of this invention to provide a method for faster downloading of files to a computer peripheral.

It is another object of the present invention to provide a method making a system robust against file corruption.

It is an object of the present invention to provide a method for using multiple data buses to download a file or group of files to a peripheral connected via two or more ports to the two data buses with each data bus communicating approximately half of the data.

It is a further object of the present invention to provide a method for redundant data communication by having an error on one bus induce the other data bus or buses to send approximately equal portions of the data.

Briefly stated in accordance with one aspect of the invention, the foregoing objects are achieved by providing a method for transferring a file to a remote unit that has multiple communication ports, and includes the steps of: dividing the file into multiple portions equal in number to the multiple communication port with each portion being substantially similar in amount of data contained therein; starting a communication of a first portion of the plurality of portions from a first computer to a first port of the remote unit; communicating a message from the first computer to a second computer requesting the second computer communicate a second portion of the plurality of portions to a second port of the remote unit; starting a communication of a second portion of the multiple portions from the second to a second port of the remote unit while the first computer is communicating the first portion to the remote unit; completing communication of the first portion to the remote unit, and completing communication of the second portion to the remote unit. In accordance with another aspect of the invention the foregoing object are achieved by providing a system for communicating a file to a unit that has a first and second communication ports, the system including: a first computer attached to the first communication port of the unit; the first computer having the file divided into a first and a second portions that are substantial equal in size; a second computer attached to the second port of the unit; the second computer having the file divided into a third and a fourth portions that are substantially equal in size. The first portion is equivalent to the third portion and the second portion is equivalent to the fourth portion. After the first computer has started to communicate the first portion of the file to a first communication port of the unit, the first computer sends a request to the second computer for the second computer to communicate the fourth portion of the file to the second communication port, and after the second computer receives the request, if there are no errors at the second computer, the second computer communicates the fourth portion of the file to the second communication port of the unit partly overlapping the communication of the first portion by the first computer to the first communication port of the unit. After the unit receives all necessary portions, each computer that communicated a portion sends a jump instruction which when all computers communicating portions have sent such instructions, the unit starts a process that converts the portions back into the file for use by the unit.

FIG. 1 is a block diagram of a system for practicing the invention.

FIG. 2 illustrates processing of data files for communication over multiple buses, yet having a redundant file communication capability.

FIG. 3 illustrates a data formatting used in one embodiment of the invention.

FIG. 4A and FIG. 4B together form a flow diagram showing the actions that can be taken to provide a method for downloading for a file or group of files to a peripheral.

An example of a system 10 for practicing the present invention is shown in FIG. 1. System 10 has computer 12 and computer 14 connected to peripheral unit 20 by data buses 22 and 24 respectively, and to each other by data bus 16. Data buses 22 and 24 connect to the peripheral unit 20 at port 26 and port 28 respectively. In this exemplary embodiment, the peripheral unit 20 is a Reliable Clustered Computer (RCC) watchdog system, but it could be any one of a number of other units or peripherals, such as switching modules. Really, any unit to which digital data may be pumped.

Computer 12 and computer 14 work together to download a file or a group of files. For example, assume that a file named "task" is to be downloaded, also sometimes referred to as "pumped". Further assume peripheral unit 20 to be pumped is attached to computers 12 and 14 which can communicate with each other via data bus 16. Each of the computers 12 and 14 has a copy of the "task" file. Each of the computers 12, 14 follows the same process to split the "task" file is split into two files, named "task.1" and "task.2". Thus, both of these files, "task.1" and "task.2", have copies in computer 12 and computer 14. Now if computer 12 receives or generates a command to begin pumping peripheral unit 20, it immediately begins downloading file "task.1" and sends a command to computer 14 to download file "task.2". It should be noted that it could just as easily have been computer 14 that received or generated a command to start pumping peripheral unit 20 and immediately begin pumping file "task.1" and signaling to computer 12 to begin pumping file "task.2" instead. If no response is received by computer 12 from computer 14 to the request then computer 12 repeats the command to download "task.2". In this instance, computer 12 ends up pumping both "task.1" and "task.2". If computer 14 informs computer 12 that it can not download "task.2" then computer 12 downloads "task.2", just as if computer 14 had not responded to the request of computer 12. If computer 14 sends a message to computer 12 that it will download "task.2" but computer 12 does not receive the message, then "task.2" will be downloaded by both computer 12 and computer 14. However, since the downloading is addressed, the result is that the second computer to download "task.2" will replace the previous image of "task.2" with an identical image (assuming the first image was error free).

For small transfers, one of the computers could send either the whole file to the other computer or the file could be originally loaded into each of the computers 12, 14. The third possibility of having one computer do the file splitting and then downloading the other computer has more potential single point failures, so it is less robust and less reliable statistically. For distributions to a large number of peripherals, original loading from disk or tape is more advantageous from a bandwidth perspective. However, if some of the computers doing the pumping are difficult to physically load by service personnel, loading from on computer to another over bus 16, with appropriate error detection and correction methods, is more advantageous from a travel and personnel cost perspective.

Referring now to FIGS. 1 and 2, preferably each computer 12, 14 has a respective copy of the whole original file "task" 112, 114. Each computer 12, 14 processes its copy of the original file 112, 114 into two approximate halves. For brevity, only the processing of "task" copy 112 by computer 12 is described. Those in the art will recognize that a virtually identical process generates equivalent, virtually identical, results within computer 14. As shown in FIG. 2, "task" copy 112 is processed by file splitter process 204 into two approximate halves "task.1" copy 210 and "task.2" copy 212. In a similar manner (not shown), computer 14 processes "task" copy 114 into two approximate halves "task.1" copy 220 and "task.2" copy 222.

The file splitter process 204 determines the size of the file "task" 112 and splits it into two portions 210 and 212 that are approximately halves. Each of the portions 210 and 212 is processed into a format, such as Intel X86 hexadecimal, suitable for pumping to the peripheral unit 20. Intel is a registered trademark of Intel Corporation, Santa Clara, Calif. A header is added to each of the portions 210,212. Each header includes information regarding timestamps, file size, and a file sum for the entire reconstructed image.

Referring now to FIG. 3, the format of the portion 210 is shown as a representative processed file. Portion 210 has header 302 which has time created and file size information. The header 302 is followed by N lines 3041-304N which carry the data. A length of each line is determined by the splitter process, which also appends a checksum to each line. Portions 212, 220 and 222 are similarly processed.

Referring now to FIGS. 4A and 4B, a method 400 for pumping a file to a peripheral. Method 400 begins with action 401 which is the start and progresses to action 403. Action 403 induces computer.sub.-- A to start the method 400 by pumping the first portion (file 1) of the overall file. Next, method 400 progresses to action 405. Action 405 has computer.sub.-- A send a message to computer.sub.-- B requesting that computer.sub.-- B pump the second portion of the file to the peripheral. After action 405, method 400 progresses to decision 406. Decision 406 determines if computer.sub.-- B got the message sent by computer.sub.-- A. If computer.sub.-- B does not get the message method 400 progresses to decision 427 and if computer.sub.-- B does get the message from computer.sub.-- A the method 400 progresses to decision 407. Decision 407 determines if the file on computer.sub.-- B matches the header information sent by computer.sub.-- A in its pump request message. If the decision is that the file does not match the header information, the method 400 progresses to action 409, otherwise if there is a match the method 400 progresses to action 423. Action 409 has computer.sub.-- B send a refusal to pump the requested file to computer.sub.-- A. After the refusal is sent, the method 400 progresses to decision 410 where a determination is made if computer.sub.-- A got the refusal of computer.sub.-- B. If computer.sub.-- A got the refusal, method 400 progresses to action 411, and if computer.sub.-- A did not get the refusal, method 400 progresses to decision 427. Action 411 is where computer.sub.-- B declares that it has finished its duty and the method 400 then progresses to action 413.

The alternative path from decision 407 next progresses to action 423 where computer.sub.-- B sends a message agreeing to pump as requested. After action 423, method 400 progresses to decision 425. Decision 425 determines if computer.sub.-- A receives the message of computer.sub.-- B agreeing to pump a portion of the file before a preset time period has run. If the determination is no, then method 400 progresses to determination 427. Decision 427 checks a retry count to see if it has been met. If the retry count has not been met, method 400 progresses to action 428 which iterates the retry count and returns to action 405. If the retry count has been met, then method 400 progresses to action 413 with the conclusion that computer.sub.-- B cannot be counted upon to help pump the file. If at decision 425 the determination is yes, which is the desired result that computer.sub.-- A and computer.sub.-- B will cooperate in pumping the file to ports of the remote unit 20, then method 400 progresses to action 431.

Action 431 is where computer.sub.-- A pumping of the first portion of the file to be communicated. Next is action 433, which is where computer.sub.-- A announces to computer.sub.-- B that its first portion of the file has been pumped to the remote unit 20. After action 433, action 435 is where computer.sub.-- A waits for an announcement that computer.sub.-- B has finished pumping its second portion of the file to the remote unit 20. Next, method 400 progresses to decision 437 where a determination is made if a preset wait time period has been exceeded. The exception is if the timer expires because of communication or operation problems between computer.sub.-- B and computer.sub.-- A. For an exception of this type to occur at this stage is unlikely and very difficult to deal with, so for such, method 400 progresses to action 439 which aborts the pumping of the file and then stops. After the stop, a repair and restart at action 401 is in order.

The normal determination at decision 437 is that the time period does not expire and method 400 progresses to action 441. At action 441, computersB completes the communication of the second portion to remote unit 20. Next, at action 443 computer.sub.-- B sends a jump WD instruction to remote unit 20, which is a WatchDog unit, but could be some other type of remote unit. After action 443, at action 445 computer.sub.-- B sends a message to computer.sub.-- A that it has completed its task and it is done. Next, decision 447 determines if computer.sub.-- A gets the "computer.sub.-- B is done" message. For the negative exceptions, method 400 progresses to action 449, which aborts the file communication, and stops for repair or retry. For the usual positive determination that computer.sub.-- A gets the "computer.sub.-- B done" message, method 400 progresses to action 451. Action 451 is the normal last action of computer.sub.-- A sending a jump WD to WatchDog remote unit 20 and then progressing to the stop, which means the method 400 has finished the communication of the file.

An alternative branch to action 451 is from either action 411 or decision 427 negative determination through action 413 and action 415. At action 413 computer.sub.-- A finishes pumping the first portion of the file and method 400 progresses to action 415. At action 415, computer.sub.-- B has not been completely responsive so computer.sub.-- A pumps the second portion of the file. After action 415, method 400 progresses to action 451 where computer.sub.-- A sends the remote unit 20 a jump instruction, then stops.

Remote unit 20, which in the exemplary embodiment is a watch dog unit, is given a jump instruction either by computer.sub.-- A and by computer.sub.-- B if both pump portions of the file. If because of problems only one of computer.sub.-- A and computer.sub.-- B pumps all portions, then only the pumping computer gives the jump instruction. Upon receiving the jump instruction, a processor in the remote unit 20 starts a process that joins the two portion back into the file desired to be communicated or pumped. Under typical operating conditions the pumping through multiple ports and rejoining is faster than pumping through a single port. When the file has to be pumped to multiple remote units, the time savings increase because the time required for the dividing of the file is spread over multiple pumps. If there are multiple computers pumping through multiple ports, then the remote unit being pumped must receive an end-of-file-portion instruction from each pumping computer before all the portions are joined together into the desired file.

Thus, it will now be understood that there has been disclosed a method and apparatus for pumping a file to a remote unit via multiple portions pumped through multiple ports of the remote unit. While the invention has been particularly illustrated and described with reference to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form, details, and applications may be made therein. For example, the file could be divided into multiple portions in real time, such as live video and/or audio and joined back together in real time at the remote unit upon receiving periodic portion completed signals. It is accordingly intended that the appended claims shall cover all such changes in form, details and applications which do not depart from the true spirit and scope of the invention.