A “thin client” (sometimes also called a lean client) is a computer device that depends primarily on a central server for processing activities, and mainly focuses on conveying input and output between the user and the remote server. This is to be contrasted with a “thick” or “fat” client, which does as much processing as possible on the local device, and passes only data for communications and storage to the server. Many thin client devices run only web browsers or remote desktop software, meaning that all significant processing occurs on the server.
Thin client computers typically have a very small flash storage device that contains the operating system (OS) and all of the software used on that particular computer. The thin client operating system plus all of the added software is called a “flash image” or “operating system image” and can be handled as one large file.
It can be desirable to update a thin client operating system from time to time. For example, a user of a network having multiple thin clients may desire to modify the original flash image or create their own flash image and redeploy this new image to all of the associated thin clients. Some thin client operating system images provide a feature to re-image the thin client with a new version of the flash image. However, thin clients typically do not have enough available memory to allow downloading of the entire flash image in one operation. Consequently, multiple write cycles are used. Unfortunately, if the thin client device loses power or network connectivity during the relatively long write cycles for downloading the new flash image, it is possible to corrupt the image of a thin client so that the device will not boot at all.
Various features and advantages of the present disclosure will be apparent from the detailed description which follows, taken in conjunction with the accompanying drawings, which together illustrate, by way of example, features of the present disclosure, and wherein:
Reference will now be made to exemplary embodiments illustrated in the drawings, and specific language will be used herein to describe the same. It will nevertheless be understood that no limitation of the scope of the present disclosure is thereby intended. Alterations and further modifications of the features illustrated herein, and additional applications of the principles illustrated herein, which would occur to one skilled in the relevant art and having possession of this disclosure, are to be considered within the scope of this disclosure.
As noted above, many thin clients do not have enough available RAM to allow downloading of an entire new flash image in one operation. Consequently, multiple write cycles are used to update the flash image. Unfortunately, if a thin client device loses power or network connectivity during one of the relatively long write cycles for downloading the new flash image, it is possible to corrupt the image of the thin client so that the device will not boot at all. Some management software solutions load a thin client with a second small operating system to perform the re-imaging of the flash memory. However, this second operating system typically requires from 5 to 20 MB of flash space. Flash space is at a premium on thin clients since flash devices are typically 64 MB on the cheapest systems to 1 GB on the high end thin clients. On the other hand, some thin clients can update the flash image from within their operating system, and can download an entire new flash image into RAM first and then write the entire new flash image to the flash device. Nevertheless, this approach still has a potential window of failure during the write of the new flash image to the flash device.
Advantageously, a method has been developed for safely updating a thin client operating system over a network. As used herein, the term “safely updating” is used to refer to a method for updating (i.e. writing to memory in the thin client a new copy of) a thin client flash image in a manner that reduces the potential window of failure from loss of power or network connectivity during the network download or flash write processes. This method helps minimize windows of failure for updating the flash image.
One embodiment of a safe method for updating a thin client operating system over a network is outlined in the flowchart of
Located on the server 110 is a new thin client operating system image version 122, labeled “new image,” that is to be downloaded to the thin client 112. The new image can include many new applications and drivers and/or revisions of previous applications and drivers. The server also includes a relatively small service operating system (“service OS”) 124 that plays a part in the downloading of the new image 122. The service OS can be a single purpose Linux image, for example. The illustration of
The process of downloading the new image 122 will be described with reference to the flowchart of
Once the service OS 124 has been downloaded into RAM 116, confirmation that the file transfer process occurred properly is performed (step 14 in
At this point the process can take a couple of different paths. In one option, the thin client 112 can be prompted to reboot under the service OS (step 18 in
After the service OS 124 has been successfully copied to the thin client 112, the next step is to divide the new image 122 into a large part 130 and a small part 132, as shown in
This process repeats so long as there are additional portions of the large part 130 to be downloaded (step 28 in
After the large part 130 of the new flash image 122 has been downloaded and written to flash memory 118, the small part 132 that will overwrite the service OS is fully downloaded to RAM 116 (step 30 in
With this method, the only opportunities for failure are when the service OS is getting written to the flash memory 118, and when the service OS is getting overwritten by the small chunk of the new flash image. These opportunities are only open for the total time it takes to write 4-10 MB of data to the flash memory 118, which is on the order of a few seconds. In contrast, the potential window of failure for some thin client updating systems, where the new image is larger than available RAM, can be several minutes. This method thus reduces the potential window of failure when updating a flash image in a thin client, to allow the new image to be safely written to the flash memory. This method address these potential windows of failure, and also enables thin clients that have a flash image that is larger than available RAM to be safely updated via a network.
Advantageously, the imaging process is performed from within the original operating system. A safe kernel is present through most of the update and will take over if power is ever lost. No extra flash space is needed. The FTP/TCP/IP protocol is typically allowed by firewalls and therefore a thin client user can have one sole location for their home-grown thin client images and allow access from around the world. This method is desirable to thin client users because of the small image size on a thin client. With this method the image size does not need to be smaller than the total available RAM size for the process to work. Additionally, operating system calls can be used to write the new image to the flash memory without having to reboot multiple times.
It is to be understood that the above-referenced arrangements are illustrative of the application of the principles disclosed herein. It will be apparent to those of ordinary skill in the art that numerous modifications can be made without departing from the principles and concepts of this disclosure, as set forth in the claims.
This Application claims the priority of U.S. Provisional Application Ser. No. 61/080,052 filed Jul. 11, 2008, titled “System And Method For Safely Updating Thin Client Operation System Over A Network” which is hereby incorporated by reference herein as if produced in full below.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/US2009/048735 | 6/25/2009 | WO | 00 | 1/5/2011 |
Publishing Document | Publishing Date | Country | Kind |
---|---|---|---|
WO2010/005803 | 1/14/2010 | WO | A |
Number | Name | Date | Kind |
---|---|---|---|
5579522 | Christenson et al. | Nov 1996 | A |
6223284 | Novoa et al. | Apr 2001 | B1 |
6282643 | Cromer et al. | Aug 2001 | B1 |
6314455 | Cromer et al. | Nov 2001 | B1 |
6718464 | Cromer et al. | Apr 2004 | B2 |
7069452 | Hind et al. | Jun 2006 | B1 |
7139909 | Lee | Nov 2006 | B2 |
7698698 | Skan | Apr 2010 | B2 |
20020002652 | Takahashi | Jan 2002 | A1 |
20020099934 | Cromer et al. | Jul 2002 | A1 |
20030061323 | East | Mar 2003 | A1 |
20050055595 | Frazer et al. | Mar 2005 | A1 |
20050086464 | Lee | Apr 2005 | A1 |
20050144609 | Rothman et al. | Jun 2005 | A1 |
20050203944 | Dinh | Sep 2005 | A1 |
20050228978 | Saliou et al. | Oct 2005 | A1 |
20050229173 | Mihm et al. | Oct 2005 | A1 |
20050235280 | Le et al. | Oct 2005 | A1 |
20060200658 | Penkethman | Sep 2006 | A1 |
20070220013 | Rabines | Sep 2007 | A1 |
20100325622 | Morton | Dec 2010 | A1 |
Number | Date | Country |
---|---|---|
0803812 | Oct 1997 | EP |
WO2004003733 | Jan 2004 | WO |
Entry |
---|
EPO, Supplementary EP Search Report dated Oct. 7, 2011, App No. 09794967.1-1243 / 2300929 filed Jan. 11, 2011, PCT/US2009048735 filed Jun. 25, 2009. |
WIPO, International Search Report and Written Opinion, App. No. PCT/US2009/048735, filed Jun. 25, 2009, Mailed Dec. 17, 2009. |
Number | Date | Country | |
---|---|---|---|
20110119434 A1 | May 2011 | US |
Number | Date | Country | |
---|---|---|---|
61080052 | Jul 2008 | US |