JP2008165823A - System and method for streaming data to computer on network - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a method for booting one or more client computers through a network. <P>SOLUTION: A system and method for quickly streaming data to one or more client devices (2 or 2') such as personal computers (PC) from a server (4) utilizes virtual disk emulation and broadcasting or multicasting of data existing in a network server (38). In several embodiments, data to be streamed include a file required for booting and initializing the one or more client devices (2 or 2'), hibernation, an O/S, and application files. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

The present invention relates to simultaneous data transmission from a network server to one or more client devices such as a personal computer (PC) on a network. Specifically, the present invention facilitates remote operation of client devices by utilizing virtual disk emulation and desired data broadcasting or multicasting. In some embodiments, the data resides on a network server and includes an operating system (O / S), hibernation, and application files that are used to boot or initialize one or more client devices. .

Computer networks are used to interconnect personal computers (PCs) in office and other corporate environments. As the use of PCs expands, there is an increasing demand for sharing computer files and promoting management of each PC after installation. In a network consisting of a large number of PCs, it is very costly for an organization to have IT personnel to actually visit and service each PC. In order to reduce such costs, software and computer manufacturers maintain software products centrally on a network server and develop techniques for downloading desired software to each client PC via the network. .

Network-centric computerization also places new demands on the PC architecture. Embedded systems are usually small and inexpensive and are designed specifically for special purpose devices. PCs at different times of their lifetime
It is an extensible general-purpose computer platform that can play a variety of different roles. Many forms of current embedded systems are communication mechanisms that allow them to interact with other intelligent devices by sending data packets over the network according to a set of rules called "communication protocols" It is connected to the. In order for two computers on a network, such as a server and a client, to communicate with each other, each computer must use an appropriate communication protocol for a particular network. The present invention uses standard TFTP (trivi) for network communications.
al file transport protocol) and DHCP (Dynamic Host Configuration Protocol).

Designers and manufacturers of embedded intelligent connected equipment reduce costs,
We are looking for ways to improve manageability and reliability, promote deployment, and protect intellectual property in devices. One way to achieve these is to introduce the ability for the client PC to be booted (or started) from the network. The purpose of the PC boot process is to load the necessary operating system elements, initialize the hardware device, and present the application to the user. This is a long process and under normal conditions it is necessary to take into account changes in hardware or software defaults and changes in authorized users. Network boot is more suitable for situations where the hardware associated with the PC (or directly connected to the PC) is fixed and the role of the client PC does not change frequently. Network boot enables the removal of the PC's hard disk and facilitates central management of software content. Current network bandwidth (10 / 100Mbs and 1Gb
Since s) does not reach the local hard disk speed of the client PC, remote “cold boot” of the client PC operating system (O / S) is not efficient and very time consuming. Furthermore, the effective bandwidth of the network and network server resources can be further exacerbated when attempting to boot a large number of client devices simultaneously ("boot storm"). The long time required for “cold boot” detracts from the perception and behavior of ordinary embedded devices. Therefore, there is a need for a scalable (or easy to expand and contract) method that speeds up the transmission of desired data from a central repository to a plurality of client devices on the network, such as a network server.

Prior art systems present a technique for solving the long boot time associated with remotely booting a client device from a boot image on a network (see, for example, Patent Document 1). However, this patent teaches playing from a hibernation image stored in the local storage medium of each client PC and following a kind of reset. This approach requires that the client PC perform all reconfiguration of the desired state of the PC prior to hibernation, and the server has multiple corresponding client PCs on a network to which many client PCs are connected. Since each hibernation image is transferred individually, it may cause a network collision.

Some conventional systems use devices and methods that use disk emulation to boot a 32-bit PC operating system (O / S) on a client computer via a network connection to a server ( For example, see Patent Document 2). Specifically, this patent refers to Windows® 9xO / S 32, referred to as “thunking” until the client O / S is able to perform network processing on its own. He teaches how to switch (in each disk I / O call) between bit protection mode processing and the 16-bit real mode used by the BIOS. This method and apparatus is particularly suitable for booting an O / S such as Windows 95 from a server by downloading a complete image of the desired software application on the client PC including the O / S. However, this patent does not allow for the broadcasting or multicasting of desired data, including hibernation files in certain preferred embodiments, to multiple client PCs on the network.

US Pat. No. 6,101,601 US Pat. No. 5,974,547

An object of the present invention is to provide a system for quickly booting an O / S on one or more PCs from a network server in a network system comprising a network server and one or more client computers connected on a network. It is to solve the above-mentioned problems by providing a method.

The present invention provides an apparatus and method for streaming data (or transferring data) from a network server to one or more client PCs. Data may be recovered (or retrieved) in a predetermined manner from multiple sectors of the storage device associated with (or directly connected to) the network server. In operation, one or more client PCs issue a corresponding number of requests (or requests) for downloading of multiple sectors. The request is temporarily transferred (or transmitted) to a server emulating the operation of each local disk of the client PC. The server broadcasts or multicasts the desired data from the virtual hard disk associated with the server (or directly connected to the server) to the requesting client simultaneously (or synchronously). The server is preferred, before sending it to the desired data.
Accept the download request during a predetermined solicitation period (or during the invitation period).

In a particular embodiment, emulation is accomplished by executing emulation code that resides on each of the client PCs. Preferably, the emulation code is a pre-execution boot environment (PXE) code that resides on the network interface card (NIC) of each client PC. In an alternative embodiment, emulation is the result of an original boot code downloaded from a network server that, when executed, assumes disk access control by an interrupt handling procedure (Int 13h) and requests the desired data. .
In another embodiment, the emulation assumes control of part of the O / S (which is preferably Windows 2000, NT, or XP), and also the client's network interface, as desired. This is accomplished at each client PC by executing two original drivers downloaded from a network server that request the data.

The data to be streamed (or data to be transferred) may be broadcast or multicast in simultaneous burst mode from the network server to the client PC requesting download. Therefore, the data is stored on each client PC
Instead of being sent redundantly, it need only be sent once from the network server. As data sectors are received at each client, they are queued (or queued) in a data cache that has been previously allocated by an ingenious driver. This is because each client has an O / S data structure, a driver, and / or
Allows you to concentrate on other operations, such as initializing the application.

In a particular embodiment, the present invention provides virtual disk emulation and server 1
O on one or more client PCs from a network server by utilizing a streaming method (or data transfer method) to multicast or broadcast a portion of a pre-configured disk image to one or more clients /
Systems and methods for booting S are provided. Ingenious drivers, as one function, broadcast part (sectors) of a disk image that collectively (or jointly) compose the O / S files needed to complete the reboot process Alternatively, it operates to assist each client PC to recover (or replay) to a usable state by receiving (or accepting) the multicast. Requests for disk access in the early stages of the boot process are first redirected (or redirected) from each client to the network server by using the PXE service.
. The PXE code will help establish an initial virtual connection between each client and server, and allow the server to be recognized as another client's drive. P
The XE code assists in downloading additional emulation code, which (ie, downloaded emulation code) then downloads O / S code that assists in downloading a portion of the transmitted disk image. During the initial stages of the boot process, insufficient O / S elements are loaded and activated to provide client O / S supported network access. As a result, client hard disk access requests are handled via an Int 13h handler and downloaded emulation code. In about 25% of the O / S boot, the O / S uses an ingenious driver to take control of communication with the server, effectively avoiding the need for the BIOS Int 13h service.

In another embodiment, one or more PCs from the network server of the present invention
The system and method for quickly booting the above O / S uses a hibernation file. In this embodiment, the data to be streamed includes a hibernation image including a hibernation image and a plurality of O / S files. Although the streaming process itself does not depend on hibernation functionality at all, one or more PCs in this embodiment need to run an O / S that supports hibernation. Such systems include Microsoft Windows 2000 and XP. A further description of network boot using the synchronous streaming method is described in Applicant's International Publication No. 03/090109 “System for and Method of Network Booting of an Operating System to a Client Computer Using Hibernation” The entire contents thereof are also incorporated herein by reference.

The present invention requires less hardware because the client device does not have to be configured with a hard disk. The present invention also allows the client PC to download the same desired data. This facilitates maintenance of each client device since each client does not need to execute the same O / S or application replication. For example, software upgrades need to be performed only on a single disk image or a specific group of data sectors, regardless of the number of client PCs.
Since streaming data is broadcast or multicast to multiple clients, network traffic is greatly reduced during traffic peaks, for example when multiple clients attempt to boot simultaneously. Thus, the solution of the present invention is very scalable (or easy to expand and shrink) because fewer resources are required to boot an increasing number of client PCs.

In the following, certain preferred embodiments of the invention will be described with reference to the drawings.
The terms “MBR (Master Boot Record)”, “storage driver (or storage device driver)”, and “network filter driver” as used herein are bootstrappings developed by the applicant. Means a software module. In order to differentiate software modules developed by a person other than the applicant, a conventional conventional module name such as “O / S” is adopted. Further, the terms “virtual drive”, “boot drive”, and “server drive” are used interchangeably in the following description.

The network computer environment shown in FIG. 1 may be a corporate network or client / server configuration, where any of the PCs 2 may function as a file server or network server 4. The network server 4 may be a normal type system including a relatively small PC and a large mainframe. In the specific embodiment described below, the server 4 is a read-only memory with one or more central processing units (CPUs) 6, a hard disk 8 and its own BIOS 18 connected by one or more buses 16. (ROM) 1
0, an intermediate computer having a random access memory (RAM) 12 and a network adapter 14. As will be apparent to those skilled in the art, the BIOS 18 is a set of basic routines that assist in the communication of information between components within a network server. In the specific embodiment described below, the network server hard disk 8 may be an O / S loader (eg, NTLDR), utility function file (eg, WIN32.SYS), or one or more hibernation files 20, sector sequences. Various microinstruction code sets such as file 22, MBR (Master Boot Record) 24, streaming module 26, and O / SMBR 28 including at least network filter driver 30 and storage driver (or storage device driver) 32 / S file is stored.

Optionally, one or more additional servers 34 may be connected to the network and communicate with the first server 4 and the client PC 2. In the case of a multi-server network, a client module 36 (eg, HPPC) exists in the first server 4 and in response to a request from the client device 2, which additional server 34 includes client addressing information and download information. May be specified.

One or more client apparatuses 2 are connected to the server 4 via a network router or network switch 38 on the network. Physical connection is cable,
It can be any of a variety of types including switched telephone lines, wireless devices operating in the radio and infrared spectrum, and other means. The client device and server transmit data to each other using a standard communication protocol. The O / S 40 manages the physical functions or facilities of each client device after an appropriate number of O / S modules and O / S drivers are activated. Each client device is manufactured by Intel Corporation x
A CPU 42, such as an 86 family microprocessor, is provided. Each client also has a local memory 4 including a ROM 46 and a RAM 50 that store the BIOS 48.
4, a local storage device (or local storage) 52, and a network adapter 54 connected to the CPU by a system bus 56.

FIG. 1 also illustrates a portion of the client's RAM 50 after the appropriate number of sectors have been downloaded and the code they contain has been executed. RAM as shown
50 is the downloaded O / S 40, O / S driver 76, O / S loader 78, O
/ S utility function file (for example, WIN32.SYS) 72, network filter driver 30, storage driver (or storage device driver) 3
2 and O / S network stack 68 may be included. In some embodiments,
The RAM 50 may also include a hibernation file 20.

Referring to FIG. 2, each client's network adapter 54 is preferably a network interface card (NIC) that provides a data link between the client's hardware and the network. Each NIC 54 includes a bus interface 58 for connection to a client system bus 56 and one or more network connectors 60 for connection to a network. Network connector 60 is a LAN
Or it may correspond to WAN. The NIC 54 also includes a random access memory (RAM) 62 for storing the NIC's unique destination address, and
An optional ROM (OPROM) 64 for storing the PXE emulation code 66 is provided. The destination address allows each client 2 to be individually addressed by other computers on the network.

Synchronous Streaming of Desired Data to Multiple Clients As described above, the present invention provides a transparent (or transparent) local disk in response to a read request (or read request) issued by one or more clients 2. (Transparently) (ie emulated so that the client user is unaware of the intervention) and broadcasting or multicasting the contents of a set of data sectors present in the server's “virtual drive” 8 This provides a system and method for streaming data (or transferring data) from a network server to one or more clients 2. Data may be recovered (or retrieved) in a predetermined manner from multiple sectors within the storage device associated with (or directly connected to) network server 4. In operation, one or more clients 2 that need to download specific data issue requests (or requests) for multiple sector downloads that collectively (or jointly) compose the desired data. . It has to be noted here that different sets of clients may request different data downloads. The request is forwarded to the server, which transparently emulates each client's local disk activity. The streaming module 26 of the network server 4 broadcasts or multicasts the desired data from the “virtual” storage device to the requesting client set. The streaming module 26 preferably accepts the download request for a predetermined solicitation period (or invitation period) before sending the desired data.

FIG. 4 is a flowchart illustrating a process 400 for synchronous data streaming in accordance with the present invention. It has to be noted here that the following description is written for a single set of clients that need to download the same data. This is to facilitate understanding of the present invention and not to limit the present invention. As will be apparent to those skilled in the art, the synchronous streaming method is applicable to multiple sets of clients that are simultaneously requesting different data downloads from a network server.

In step 402, each client desiring to download specific data issues an initial request. The desired data may be various application files, O / S files, boot programs, or hibernation files existing in the virtual drive 8 of the server. These requests are issued to the server 4 and the server can either execute the PXE code 66 and the downloaded MBR 33 code, or
The client's local disk 52 is emulated during various stages of boot up through the execution of O / SMBR 28 code along with network filters and storage drivers.

In step 404, the server's streaming module 26 registers each client 2 'that has issued an initial request during a predetermined solicitation period. Each registered client waits for a data packet from the streaming module 26.

In step 406, the streaming module looks for the sector sequence file 22 on the server 4. The sector sequence file 22 determines the access to the data sector containing the desired data and the broadcast or multicast order of the data sector. If the sector sequence file 22 is not found, the program flow proceeds to a learning process (or learning process) 450 for recording the sector sequence file described later.

In step 408, if the sector sequence file 22 is found, the streaming module 26 sends the client 2 'registered the desired data in the burst mode.
Broadcast or multicast to. Data packets are transmitted at a fixed rate as preferred.

In step 410, the data packets received by each registered client 2 'are stored in a fixed length queue to compensate for the difference in transfer rate and client boot processing speed. The network and storage driver loads the received data into a large temporary partition ("data cache") in memory that is pre-allocated in each client. Each registered client keeps track of (or records the location of) data packets that it has successfully received. This may be done by serializing the transmitted data packets.

In step 412, each registered client 2 'sends the server the latest N
An acknowledgment (or received signal) is transmitted indicating that attempts have been made to successfully receive packets. The purpose of the client acknowledgment is to ensure that the local client buffer is not overrun.

In step 414, the streaming module 26 confirms that all desired data has been accessed and that their content (or content) has been transmitted. If these processes are not complete, step 408 and step 410 are repeated until completion.

In step 416, if all the desired data has been transmitted, the streaming module transmits a message indicating that the transmission is complete. However, at this point, not all clients may have received all blocks of information without problems. That is, some packets may be missing for some reason. Also,
Some clients may miss the start of transmission.

In step 418, each registered client 2 'informs the streaming module 26 by a message indicating that all transmissions of the desired data packet have been successful, or a message indicating the need for retransmission of missed packets. You may respond.

In step 420, the streaming module 26 compiles a list of packet retransmissions based on the response received from the registered client 2 ', indicating the need for missed or missing transmitted data packets, and effectively Order. Alternatively, the list of packet retransmissions (prior to step 414) may be iteratively edited for each determined number of bytes during the transmission of the data packet. In step 422, the streaming module 26 may retransmit the required data packets individually to the registered client 2 '. At this point, most clients are processing received data packets, so the network bandwidth is high, so individual retransmissions have a discernable effect on boot time or network traffic. Would not give.

In step 424, after the downloaded data has been successfully processed, the memory allocated in advance for the cache is deallocated.

As noted above, the advantages of streaming 400 are that each client needs data while the client's O / S is devoted to initializing the O / S data structure, driver, or application. This means that the O / S data that will be required in the future will already be prepared by preloading the data packet into the memory. The streaming module 26 broadcasts or multicasts a packet to the client before the client becomes able to use the packet, and shifts the dependency of the bootup time from the packet transmission time to the client boot processing time.

In certain embodiments, the streaming module 26 utilizes the sector sequence file 22 to determine the order of the virtual drive sector content to be transmitted. The sector sequence file 22 is expected to be stored on the server 4 before embarking on a synchronous streaming process, but if this is not done, the sector sequence file 22 is stored in the learning process (or described below) (or , Learning process) 450 may be generated.

If the streaming module 26 cannot find the sector sequence file 22, a learning process 450 is performed. In one embodiment, the sector sequence file consists of a list of sectors that the O / S must read to complete the disk image transmission. In another embodiment, the sector sequence file may include not only the list of sectors, but also the actual data stored sequentially, contained within the listed sectors. In another embodiment, the sector sequence file may be multiple to support simultaneous (or synchronous) streaming of different sets of data to different sets of issuing clients. May be composed of a single file containing a sector list and corresponding sector data. The advantage of storing actual data is that sequential file reads are much faster than random reads, which increases server drive throughput and more effectively supports multiple streams to multiple clients. The ability is to increase. One result of this is that the actual data learned can be read exclusively from the sector sequence file until all of the learned data has been sent to the client. After this point, the server can return to using the virtual drive image.

In step 426, the streaming module 26 registers the registered client 2
Select one client from '. In step 428, the selected client is allowed to generate a conventional disk access request for itself, and the streaming module adds the new client to its desired sector sequence file. Record all sector access requests (and in some embodiments, the requested data itself) generated to satisfy the data download. In step 430, the selected client informs the streaming module 26 that it has completed the download. At this point, the new sector sequence file is stored in the virtual drive 8 and the streaming process is resumed in step 408. The use of streaming processing in a network boot application is described below. When learning process 450 is required to create sector sequence file 22 in the context of network boot, it is customary for selected clients to use original MBR 24 and drivers (30 and 32). While allowed to boot, the streaming module 26 will request all sector access requests generated by the client selected for the new sector sequence file during booting (and in some embodiments, the requested data itself). ).

Boot NIC Basic Architecture The present invention relates to a system for synchronous data streaming accessed from a data sector on a “virtual” drive of a network server, which is required for a client computer to boot quickly. Give way. In a particular embodiment, the data sectors that the client computer needs to download collectively (or jointly) configure the boot program and O / S files needed for booting. In another particular embodiment, the data sector additionally includes one or more hibernation files. Each client that needs to download specific data issues an initial request. These requests are issued to the server 4, which has a PXE code 6
6 and emulating the client's local disk 52 during various stages of bootup through execution of downloaded MBR33 code or through execution of O / SMBR28 code along with network filters and storage drivers To do. In other words, in the context of a complete network boot of O / S on the client:
The synchronous streaming process 400 is basically repeated (with some meaningful differences) before and after the O / S driver is initialized. This is because the O / S boot process uses an interrupt handler procedure (or interrupt handler process) during the early stages of the boot process to download a file from the virtual drive 8, whereas
Thereafter, the storage driver 32 and the network filter driver 30 are used after they are initialized. This means that two solutions are required to perform substantially equivalent tasks.

As each client boots, they first communicate with the server 4 using the PXE service. The PXE code 66 establishes an initial emulated “virtual drive” connection between each client and server. The PXE (Pre-Runtime Boot Environment) service allows the MBR (Master Boot Record) code 33 to send a read request to the server, so that the boot file or hibernation file 20 present on the server is sent by the CPU 42 of each client. , Allowing it to be recognized as multiple data sectors that can be stored on the hard disk 52 of the local client. During the early stages of bootstrapping, the BIOS interrupt handler service operates only in real mode, so emulation is provided by execution of the MBR code 33 in real mode. In the second half of the process, the O / S kernel code and (Gatapi mode (
(Thunking does not occur) Emulation is provided by the storage driver 32 and the network filter driver 30 executed only in the protected mode.

FIG. 3 is a block diagram illustrating a portion of the client's local memory 44 after the network filter driver 30 and storage driver (or storage device driver) 32 have been downloaded from the network server and executed. The only role of the network filter driver is to monitor all data packets sent from the network to the O / S network stack 68 via the client NIC 54 in order to identify the data packets that are specific to the boot NIC. Blocking the unique data packets from being sent to the network stack 68 and sending them to the storage driver 32 instead. Next, the storage driver 32 is mounted by a mount manager and a volume manager.
), And various managers 70 of Windows (registered trademark) having a storage role, such as a partition manager. If the network data packet is not specific to Boot NIC (BootNIC specific), the data packet is sent to the O / S network stack 68 without being affected. As will be apparent to those skilled in the art, there are three different types of data packets: (1) Broadcast packet, packet addressed to all computers on the network. (2) A multicast packet, a packet addressed by a computer that is two or more, but not necessarily all computers on the network. (3) Direct addressing packets, packets addressed only to specific client devices. The system according to the present invention may use any of these data packet transmission means.

The present invention is the result of an effort to create a predictable and interoperable way for clients to interact with the network in a pre-boot environment (PXE) (with or without an operating system) Boot execution environment (PXE (pre-boot execution
Take advantage of widely used specifications known as environment)).
The current version of PXE was established as an Intel-led industry initiative of Wired for Management (WfM). PXE encompasses the following three technologies that establish a common and coherent set of pre-boot services with the boot firmware of Intel architecture-based systems: (I) A uniform protocol for the client 2 to request the allocation of the IP address of the network and consequently to request the download of the bootstrap program (MBR 24 and O / SMBR 28) from the network boot server 4. (Ii) A set of APIs available for pre-booting the client 2 firmware environment that constitutes a consistent set of services available by the BIOS 48 or bootstrap program. (Iii) A standard method of starting pre-boot firmware for executing the PXE protocol on the client PC.

The use of the PXE spec allows the client NIC 54 to act as a boot device. It also allows BIOS 48 to directly use the NIC code stored on OPROM 64 before or during POST processing. The present invention, in certain embodiments, selectively PXE boot server discovery.
Take advantage of features. By using this feature, the boot client 2 can discover (or discover) an appropriate boot server 4 or 34 from the list of available boot servers provided to the client 2 during the initial stage of remote boot. . The boot server type depends on the type of client system architecture or the unique ID of each client.
can be assigned and maintained by an information technology administrator. PXE uses Dynamic Host Configuration Protocol (DHCP) and Trivial File Transfer Protocol (TFTP) to communicate with server 4. When PXE enables the client to boot, it obtains an IP address from the DHCP server 4. The client 2 may then discover a DHCP server 4 that gives the client a list of boot servers. FIG. 1 shows an additional server 34 that may act as a boot server.
It is shown. However, to facilitate the description of the present invention, the simultaneous streaming processing embodiment of the present invention implements a single server 4 network where a single client set requires the same data download. Explained in connection with examples.

Alternatively, a BOOTP-capable client with a static IP address can be used (although flexibility and configuration ease are reduced) instead of the DHCP and PXE methods.

Streaming Boot from Network Hibernation Image In this application, the term “hibernation” means that the PC is powered off while the PC is “paused”. While the PC is turned off, power is removed from all or most of its components. And when the PC is turned back on or "restarted", the PC returns to normal operation in the same state as when it was turned off. Micr
The “hibernation function” described in US Patent No. 6,209,088 of osoft Corp is a PC
Called immediately before turning off, interrupts execution of all programs and saves all state information of the PC as a “hibernation image” in a non-volatile storage device. "Resume function"
Is executed from volatile memory and is typically implemented by code executed from the same executable address space used by O / S and / or application programs started by O / S. In the specific environment of the present invention described below, the “hibernation file” includes an O / S file such as an O / S driver and an initialization file that is read into the volatile memory of the PC before the hibernation function is started.

The present invention, in another aspect, is improved for booting an O / S from a server 4 storing a hibernation image 20 having an O / S file for a client PC to one or more clients 2. Systems and methods are provided. Each client's CPU 42 executes only instructions (or instructions) from addressable memory, such as DRAM or other types of volatile electronic memory. To initialize this addressable memory, a small amount of PXE code 66 is sent to OPROM 64 on NIC 54.
Given to. The PXE code 66 allows a request to be issued to the network server 4 emulating the client's local disk to read the MBR code 24. The downloaded MBR code 33 allows further disk emulation, requiring that the first part of the O / SMBR 28 be sent from the server to the client, where it is loaded into the DRAM. Next, the O / SMBR 28 downloads and initializes the remaining portions of the O / S, and those remaining portions download the hibernation file 20. It has to be noted here that in some of the systems within the scope of the invention, different sets of clients may request different boot file downloads of the hibernation file. Applicants have observed that the synchronous streaming of the present invention can reduce the time required to boot O / S 40 over the network by more than 50% over traditional standard O / S local boot.

The hibernation transaction protocol consists of two parts. The first half is to create a hibernation image on the boot drive 8 and the second half is the actual resume (or recovery) from the hibernation file.

Prior to the start of the boot up of the present invention, the hibernation file 20 present on the server 4 is generated in a direct manner. After the client PC is set in a desired state, a hibernation function is used to generate a hibernation image in the hibernation file 20. The hibernation file 20 is then sent to the boot drive 8 of the server. Alternatively, the hibernation process may be performed such that the hibernation file is saved directly to the server boot drive. The hibernation function instructs all drivers to power down, but only the storage driver 32 caches WIN32.SYS 72 in the local memory 50, and the memory content is saved to the file HIBERFIL.SYS (when the O / S loader resumes). Is written down to a file to be checked for validity, and then powered down by an O / S request. Another step that is preferably performed before starting the boot process is to install MBR on the boot drive 8
24 emulation codes are stored.

  In the Windows® architecture, the Windows® architecture communicates with the server because the driver is required to exhibit a “type” and one driver cannot simultaneously be a storage driver and a network driver. Therefore, two drivers, a storage driver 32 and a network filter driver 30, are required instead of one driver. The execution of hibernation in Windows 2000 and XP assumes that only one O / S driver is required to communicate with the storage driver, and therefore the hibernation process is more than one O / S driver. Does not give a mechanism to allow to support. Since standard O / S drivers currently available are not written to resume from a file on the network, they will not work well. In a standard restart from a local drive, the O / S storage driver is required to know only (and indeed is) how to communicate with the local hard disk.

The storage driver 32 is a power handler of the NIC driver 74 (power handler).
) By replacing the dispatch address with the handler of the storage driver itself (dispatch routine disp).
atch routine). The storage driver 32 may then call the original NIC driver power handler routine.

The boot process consists of many processes, but generally involves one program starting a more advanced program with respect to the prior program. The main steps of the inventive method are BIOS initialization, PXE initialization, MBR loading and Int 13h redirection, hibernation image loading, and O / S resumption (or recovery). Here, these solutions are specific to Windows 2000, but the steps described below summarize the general framework for extending these solutions to other operating systems. It is a thing.

Referring to FIG. 5, immediately after power-up, initialization of the BIOS 48 of the client 2 is started together with execution of a power-on / self-test (POST) sequence (step 502). Each client broadcasts a DHCP discovery request to confirm its own IP address. Server O / S that supports this protocol (and other protocols) may or may not be network server 4 and these parameters along with the address of the server from which the client is booted (from there) return. The virtual boot drive 8 may comprise a non-volatile storage device associated with (or directly connected to) the network server 4 (or alternative boot server 34). Types of drivers include floppy (registered trademark) disks, hard disks, magnetic tapes, DVDs, CD-ROMs, and flash ROMs. In order to become a virtual boot drive 8, the device must keep a copy of the O / S file or the hibernation file containing the microinstruction code that is intended to be downloaded.

During POST, CPU 42 checks the address on bus 56 to determine if OPROM 64 is present on client 2. If OPROM is found, the CPU
All the hardware initialization routines on the ROM are processed to initialize the NIC 54 to a usable state (step 504). The OPROM code then initializes the PXE code (
Step 506). The OPROM code also “hooks” to the BIOS boot process via an interrupt 13h handler service that controls the reading and writing of the hard disk 52.
k) ". By using the PXE code to assume control of the NIC 54, the OP
The ROM 64 code communicates with the server 4 and allows the server hard disk 8 to transparently emulate the client 2 local hard disk 52 via disk read and write redirection to the server.

At the end of the POST sequence, BIOS 48 will begin booting the O / S. B
The IOS reads the first sector (cylinder 0, head 0, sector 1) of the virtual drive 8 of the server (step 510). The first sector stores an MBR (Master Boot Record) 24 containing additional emulation code for booting the O / S 40. The MBR 24 code is conventionally supplied by the O / S manufacturer, but additional emulation code needs to be developed to facilitate the hibernation resume process described below. The MBR code is executed after being loaded into the client's memory (step 512). The MBR code is PX to communicate with the network server
Continue to use E66, hook interrupt 13h to get all storage device access requests, and prevent writing to the server's virtual hard disk 8 during the early stages of the boot process (step 514). Read requests are favorably processed using the synchronous streaming method 400 described above. The read request is not sent to the original Int 13h BIOS routine, but is instead used by the MBR for the PXE to receive data from the network server 4. The read request is fulfilled by the MBR code, and the request is returned to the request issuer along with the data downloaded from the network server. Disc lights are operated in different styles. The MBR code does not perform writing, but returns a signal indicating normal writing to the disk write request issuer. Light is the original Int 13h
Also not sent to the BIOS routine.

  The MBR code then downloads an O / SMBR 28 developed by the O / S manufacturer, as shown in FIG. 1 as “Windows 2000 MBR”. The MBR code 33 of each client 2 gets all requests for local disk reads via its Int 13h vector hooking before OPROM 64 has the opportunity to examine the request. The downloaded MBR 88 then forwards the request to the network server using PXE 66 to download O / SMBR 28 (step 516).

In step 518, the network server 4 starts from the virtual drive 8 of the server,
Data packets that collectively (or jointly) configure O / SMBR 28 are O / SMB
Stream (or transfer data) synchronously to each client 2 requesting R download. The streaming module 26 registers for download to all the clients 2 that issued a request for O / SMBR download during the solicitation period. The solicitation period has a predetermined time interval that gives all clients the opportunity to register. The streaming module 26 then designates the first client as the read request source. That is, only that client is allowed to generate a read request for the streaming module 26 to transfer the content of the next data sector to all registered clients 2 '. The streaming module 26 then accesses all of the registered clients 2 'and simultaneously identifies the identity of the read request source and the content of the first sector of the group of sectors of the virtual drive 8 that collectively stores the O / SMBR 28. To send. The streaming module then determines whether all sectors of the group of O / SMBR sectors have been transmitted. If more sectors need to be transmitted and there are more than one registered clients, the streaming module specifies a new read request source. Next, the streaming module accesses the next sector and identifies the new read requester and the client 2 that has registered its content.
Send to all of 'simultaneously. The step of designating a new read request source is preferred and is performed in order. That is, after each transmission round, one registered client takes on the role of generating virtual drive read requests in turn, and other unspecified clients simply wait for data transmission. Streaming processing 400 is O / SMBR2
8 is repeated until it is transmitted and loaded to each client, at which point the downloaded O / SMBR assumes control of the network interface 54 and request generation processing.

Note that each read request is the same regardless of which registered client issued it. Therefore, read requests performed by the MBR code proceed in a lock-step manner. Since each client requests a read from the same virtual drive and is already executing the same MBR 28 downloaded from the virtual drive, each read request will be the same.

Referring to FIG. 5, in step 520, each registered client 2 ′ receives and stores the transmitted O / SMBR sector. The received data sector is RAM 50
Stored in Each sector may be transmitted with a serial number. Each client may then determine whether the client has successfully received all of the transmitted sectors (step 522). If the client misses a data packet, the client may request the missed data sector from the network server asynchronously. However,
Data is returned to that single client only and is not broadcast or multicast to all registered clients.

  In step 524, O / SMBR 28 (eg, Windows 2000 MBR) is loaded into each client's memory 50 and executed. Next, the O / SMBR downloads the O / S loader 74 (eg, NTLDR) described by the O / S manufacturer from the virtual drive (step 526). The downloaded O / S loader 78 may check whether a valid hibernation image exists in the virtual drive 8 (step 528). The virtual drive is set to include a valid hibernation image 20 in advance. The O / S loader 78 then starts loading the hibernation image via a series of Int 13h read requests that the MBR 33 acquires and redirects to the network server 4 (step 530). Here, the streaming process 400 may be utilized again to access and transmit the content of multiple sectors on the virtual drive 8 that collectively store the hibernation file 20 (step 532).

After the hibernation image is copied to the local memory 44 of each client, the O / S loader 78 recovers (or replays) the O / S recovered from the hibernation image.
In S40, that is, execution is passed to Windows XP or 2000 (step 534). Note that after this point, read requests are not performed in a synchronous fashion. That is, they are sent to the network server on a stand-alone basis and answered by the network server.

At this point, the O / S 40 needs to perform some initialization to wake up a driver, such as the storage driver 32, and return the system to a usable state. One difficult problem that occurs here is the NIC driver 74 and the network filter driver 3
The storage driver 32 must prevent all reads and writes until 0 is initialized. However, the network filter driver is O / S
It will not be initialized until 40 reads a file that gives the system utility functions (eg WIN32.SYS). The problem is that before generating the hibernation image
The solution is to do an early caching of WIN32.SYS in the client's memory 50, thereby making the file part of the hibernation image itself read into the local memory 50 at this point. As a result, the file WIN32K.SYS can be read from the local memory without having to access the virtual drive 8. With one exception, the storage driver 32 queues all O / S disk write and read requests into the pre-allocated cache during the generation of the hibernation image, ie, at this point in the client system memory 50. . The storage driver 32 waits until the permission for processing the request is secure, that is, the NIC driver 74
And simply store the request until the network filter driver 30 is initialized (
Step 536). The file WIN32K.SYS is read from the local client memory, and the data is returned to the O / S (step 538).

Next, the O / S 40 is connected to the NIC driver 74 and the network filter driver 30.
(Step 540). In step 542, the network filter driver 30 informs the storage driver 32 that the NIC 54 has been initialized and the network filter driver 30 is ready to accept pending read and write requests. Alternatively, the storage driver 32 “hooks” to the dispatch function of the NIC driver 74 in advance (during generation of the hibernation image) and monitors the data for its “IRP_MJ_POWER”. This alerts the storage driver 32 when a network driver wakes up. After the O / S 40 transmits IRP_MJ_POWER to the NIC driver 74, the request is always in the full power on state. Storage driver 3
2 waits until the NIC driver finishes the processing of IRP_MJ_POWER, that is, until the network driver completely occurs.

In step 544, the storage driver restores the O / S 40 to a usable state, after which the user can use the client PC in the normal manner.
Dequeue all cached read and write requests. It should be noted here that in this embodiment, the storage driver manipulates reads and writes in slightly different ways. That is, the storage driver writes all writes to the virtual drive in order to prevent destroying its data when different clients write to the same virtual image at the same time. Cache locally. Conversely, reads are made by actual reads from the virtual drive, unless a copy of the required sector is cached on the client. In the latter case, the sector is cached from the client's memory and no network transaction takes place.

From the above features and implementation of the invention, other embodiments of the invention will be apparent to persons skilled in the art. For example, in some embodiments, the synchronous streaming process 400 may be used only for downloading data requested by an interrupt handler procedure (or interrupt handler process), or only for server protected mode access. Also good. Alternatively, the synchronous streaming process 400 may be used for preloading applications to clients. Similarly, in other embodiments, booting from a network copy of a hibernation image that does not use an MBR code to synchronize request and reception of data packets is within the scope of the present invention. Therefore, the foregoing description and examples are illustrative only and the true scope and spirit of the invention is defined by the appended claims.

1 is a block diagram illustrating a client / server network environment in which the present invention is implemented. FIG. FIG. 2 is a block diagram illustrating a network adapter according to one embodiment of the present invention. FIG. 4 is a block diagram illustrating an example of a portion of a client's local memory after an ingenious driver has been downloaded from a network server and executed. Figure 6 is a flowchart illustrating one embodiment of a synchronous streaming process provided by the present invention. 6 is a flowchart illustrating one embodiment of a network boot process using a hibernation image file.

Explanation of symbols

2 Client 4 1st server 6 CPU
8 Hard disk (virtual drive)
10 ROM
12 RAM
14 Communication interface (network adapter)
16 bus 18 BIOS
20 Hibernation file 22 Sector sequence file 24 MBR
26 Streaming module 28 O / SMBR
30 Network filter driver 32 Storage driver 33 MBR
34 Second server 36 Client module 38 Network router / switch 40 O / S
42 CPU
44 memory 46 ROM
48 BIOS
50 memory (RAM)
52 Hard disk 54 Network adapter (NIC)
56 System bus 58 Bus interface 60 Network connector 62 RAM
64 OPROM
66 PXE
68 OS network stack 70 Various managers of Windows (registered trademark) 72 Initialization file 74 NIC driver 76 OS driver 78 OS loader

Claims (20)

A method of booting one or more client computers over a network, comprising:
The method
Requesting one or more sectors of data stored on the network from a server by one or more client computers, the sectors of data for booting the one or more client computers; Providing resources, and
Receiving from the server a portion of the content of a sector sequence file residing on the network, the sector sequence file including at least a portion of the sector of the requested one or more data. When,
Caching a portion of the sector file sequence in each of the one or more client computers in an allocated memory cache of the one or more client computers;
Reading a portion of the cached sector sequence file during a boot process of the one or more client computers. Initiating communication with the server using a pre-runtime boot environment protocol;
Discovering a boot server from a list of available boot servers, the list of available boot servers further comprising: at least a first server and a second server; Item 2. The method according to Item 1. The receiving further comprises receiving a sector of the data transmitted by a streaming module;
The method of claim 1, wherein the streaming module locates the sector sequence file on the network and accesses sectors of the data according to instructions described by the sector file sequence. Identifying a portion of the requested sector of data that was not received;
4. The method of claim 3, further comprising: requesting from the server a retransmission of a portion of the requested sector of data that was not transmitted. Determining whether the sector sequence file exists on the network;
Receiving the sector of the requested data from the streaming module;
The method of claim 1, wherein the streaming module creates a sector sequence file by recording the order in which the sectors of data were accessed. Communicating with a virtual drive located on a network, the virtual driver creating what emulates a local disk that resides on the requesting one or more client computers; And
The method of claim 1, further comprising: downloading a sector of the data from the virtual drive using an interrupt handler executed by the one or more client computers. A method of booting one or more client computers over a network, comprising:
The method
Receiving by a server a request for one or more sectors of data stored on the network from the one or more client computers, wherein the sectors of data identify the one or more client computers; Used to boot, and
Locating a sector sequence file containing sectors of the requested data by a streaming module on the server, the sector sequence file describing the order in which the sectors of the requested data are accessed;
Accessing the requested sector of data according to the described order by the streaming module;
Sending, by the streaming module, the requested sectors of data to the one or more client computers according to the described order.   8. The method of claim 7, further comprising creating a virtual drive by the streaming module by emulating a local disk that resides on the requesting one or more client computers. Determining whether the sector sequence file exists on the network;
If the sector sequence file does not exist on the network, the streaming module accesses the streaming module and records the sector order of the data to be transmitted, thereby creating a sector file sequence; The method of claim 7 further comprising. A system for booting one or more client computers over a network,
The system
One or more client computers that communicate with the server over a network;
A pre-runtime boot environment framework on the one or more client computers, the pre-runtime boot environment framework requesting one or more sectors of data from the server;
A sector sequence file located on the network, the sector sequence file having an order of accessing sectors of the one or more data;
A streaming module located on the server;
A memory cache located in each of the one or more client computers, wherein the transmitted one or more sectors of data are received when the one or more client computers receive the sector; A cache memory for storing one or more sectors of data,
The streaming module
Find the sector sequence file,
Accessing the one or more sectors of data in the sector sequence file according to the order;
A system configured to transmit the one or more sectors of data to the one or more client computers.   The system of claim 10, wherein the server is a boot server discovered by the one or more client computers in a list of available boot servers. A system for booting one or more client computers over a network,
The system
Means for requesting one or more sectors of data stored on the network from a server by one or more client computers for booting the one or more client computers; Providing means of resources, and
Means for receiving from the server a portion of the content of a sector sequence file residing on the network, the sector sequence file comprising at least a portion of the sector of the requested one or more data When,
Means for caching a portion of the sector file sequence in each of the one or more client computers in an allocated memory cache of the one or more client computers;
Means for reading a portion of the cached sector sequence file during a boot process of the one or more client computers. Means for initiating communication with the server using a pre-runtime boot environment protocol;
Means for discovering a boot server from a list of available boot servers, the list of available boot servers further comprising: means comprising at least a first server and a second server. 12. The system according to 12. The means for receiving further comprises means for receiving a sector of the data transmitted by a streaming module;
13. The system of claim 12, wherein the streaming module locates the sector sequence file on the network and accesses the sector of data according to instructions described by the sector file sequence. Means for identifying a portion of the sector of the requested data that was not received;
15. The system of claim 14, further comprising: means for requesting a retransmission of a portion of the requested sector of data that was not transmitted from a server. Means for determining whether the sector sequence file exists on the network;
Means for receiving a sector of the requested data from the streaming module;
13. The system of claim 12, wherein if the sector sequence file does not exist on the network, the streaming module creates a sector sequence file by recording the order in which the sectors of data were accessed. Means for communicating with a virtual drive located on a network, the virtual driver creating what emulates a local disk residing on the requesting one or more client computers; Means,
13. The system of claim 12, further comprising: means for downloading the sector of data from the virtual drive using an interrupt handler executed by the one or more client computers. A system for booting one or more client computers over a network,
The system
Means for receiving, by a server, a request for one or more sectors of data stored on the network from the one or more client computers, wherein the sectors of data identify the one or more client computers; Means used to boot; and
Means for locating a sector sequence file including a sector of the requested data by a streaming module on the server, the sector sequence file describing a sequence of accessing sectors of the requested data;
Means for accessing, by the streaming module, the sectors of the requested data according to the described order;
Means for transmitting, by the streaming module, the requested sector of data to the one or more client computers according to the described order.   19. The system of claim 18, further comprising means for creating a virtual drive by the streaming module by emulating a local disk that resides on the requesting one or more client computers. Means for determining whether the sector sequence file exists on the network;
Means for creating a sector file sequence by recording the order of sectors of the data to be transmitted and transmitted by the streaming module by the streaming module if the sector sequence file does not exist on the network; The system of claim 18 further comprising:

Images