Browse Prior Art Database

Transmitting an active application state between homogeneous systems

IP.com Disclosure Number: IPCOM000020251D
Original Publication Date: 2003-Nov-06
Included in the Prior Art Database: 2003-Nov-06
Document File: 2 page(s) / 48K

Publishing Venue

IBM

Abstract

This article describes a system for moving the active application state of a program between homogenous systems. In this system the applications need not be written to support the mechanism, and can be shifted without the application moving itself to a specific state. This is described as a workstation tool for productivity since it would allow the redistribution of user application to balance workload, or to continue working uninterrupted whilst performing maintenance requiring reboot to each machine in turn.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 50% of the total text.

Page 1 of 2

Transmitting an active application state between homogeneous systems

Using utilities such as VNC it is possible to use 1 keyboard and 1 mouse to control two different Windows* 2000 machines. However It would be useful to redistribute the workload of applications that are running on the two workstations. Currently this involves shutting down an application on one system and starting the same application from scratch on the other. The only real solution to this is to run one more powerful machine hosting two monitors, rather than have 2 computers running separately.

    By capturing the current state of processes and memory being utilised by a given application,in much the same way as a windows hibernate does system-wide, it would be possible to transmit this information to a program running on a second machine on which the application also exists. The second machine can then reconstruct the application in memory based on the captured state, in much the same way as Windows does system-wide when coming out of hibernation/standby.

    When Windows hibernates or goes into standby, a snap shot of running processes and memory is taken and archived to disk, such that when the user wishes to resume, they can simply switch on and have everything restored to the hibernated state. However, as Windows recognises memory and processes on a per application basis, a similar mecahnism could be used to hibernate on a per application basis. Further, iinstead of archiving to disk, information of an application's hiberanted state could be sent over a network to a listening application in a second machine, which then re-actives the hibernated application. This requires the same libraries etc to be installed on both machines. This could in theory be used to shift an entire desktop of running applications to a second computer, whilst the first is rebooted, then simply redistribute the applications when both systems are running again. Alternatively it would simply allow the second computer to hold the hibernated state of the applications, without running them, simply for return once the first machine has rebooted. This mechanism could similarly be employed to switch applications between virtual machines (VMWare). For exmaple, an application with memory pointers, which requires re-activation at the same memory addresses, will be easier to move between virtual systems.

    In order to allow an application's active state to me moved on demand, without the application having been written specifically to allow for it. It would need to be executed within some container, which abstracts it from direct system memory access, etc.

    This would be an application level virtual machine, as opposed to a full operating system vm. The container would be able to interrupt at any point with some basic 'rules' for what things need to complete first and what do not, e.g. waiting for network response would need to occur, the calling of the next instruction in the application code would not....