JP2010200206A - Server-client system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a server-client system capable of distributing data including related data, in response to one-time data request, even when both the number of clients and file size are large, and of reducing the loads on a server and on a network. <P>SOLUTION: The server client system 1 is constituted of a server 2 capable of supplying specific AP system data D1-1 to D2-n, including boot information and OS; and a plurality of clients 5-1 to 5-n, which are connected with the server over a network 6 and acquire specific AP system data from the server to be used in a common environment. The server monitors data requests from the plurality of clients; and when a data request is issued from any client, data-requested data D1-1 and associated data D1-2, D1-3, which are possible to be accessed layer in association with the data-requested data, are multicast-distributed to the plurality of clients. <P>COPYRIGHT: (C)2010,JPO&amp;INPIT

Description

  The present invention relates to a server client system. Specifically, the present invention relates to a server client system that acquires data stored in a server via a network and starts a specific application system.

  In recent years, server client systems incorporating network boots have become widespread. Network boot is a method in which a client obtains data (usually a file) stored in a server via a network such as a local area network (LAN), and operates an operating system (OS) related to a specific application (AP). It means starting up. The data acquired by the client includes not only AP data (AP program and data) but also a disk image including boot information and an OS. When a disk image is used, the client can use a specific AP in the same manner as when the application system is started from the hard disk.

  FIG. 13 shows the concept of data distribution in a conventional server client system. FIG. 13A shows an example of a server client system 51A distributed from one server. The boot server (server for booting) 52 has a database 54 for storing specific application system data (disk image in this example) 53, and a plurality of clients 55-1 to 55-4 are connected to the boot server 52 via the LAN 56. It is connected. Each client 55-1 to 55-4 individually requests data 53 from the boot server 52, and the boot server 52 distributes the same data 53 to each client 55-1 to 55-4 individually at different times. Reference numeral 57 denotes a LAN 56 switch. FIG. 13B shows an example of a server client system 51B that distributes and distributes servers. By distributing the servers 52-1 and 52-2, the load on each of the servers 52-1 and 52-2 is reduced. A plurality of clients 55-1 to 55-2 are connected to the boot server 52-1 via the LAN 56-1, and a plurality of clients 55-2 to 55-4 are connected to the boot server 52-2 via the LAN 56-2. Has been. Each of the servers 52-1 and 52-2 has databases 54-1 and 54-2 that store specific application system data (disk images in this example) 53. Each client 55-1 to 55-2 individually requests the data 53 from the boot server 52-1, and the boot server 52-1 individually changes the same data 53 to each client 55-1 to 55-2 at different times. Deliver to. Each client 55-3 to 55-4 individually requests data 53 from the boot server 52-2, and the boot server 52-2 individually changes the same data 53 to each client 55-3 to 55-4 at different times. Deliver to.

  FIG. 14 shows an example of a data distribution procedure in a conventional server client system. For example, the system is configured as shown in FIG. Data 53-1 to 53-3 are distributed as the data 53. Each of the clients 55-1 and 55-2 requests the data 53-1 from the server 52, and the server 52 responds to the request by individually changing the data 53-1 to the clients 55-1 and 55-2, respectively. To deliver. Next, the clients 55-1 and 55-2 request the data 53-2 from the server 52, and the server 52 changes the time of the data 53-2 to the clients 55-1 and 55-2 in response to the request. Distributed individually. Next, the clients 55-1 and 55-2 request the data 53-3 from the server 52, and the server 52 changes the time of the data 53-3 to the clients 55-1 and 55-2 in response to the request. Distributed individually. Although the number of clients is shown in the figure up to 2, even when the number of clients is large, the server 52 distributes the requested data individually for each client at different times in response to requests from each client. Further, in order to proceed with the processing of its own work, the client requests the data 53-1 when the data 53-1 is necessary, proceeds with the processing after receiving the data 53-1, and further proceeds to the data 53 when the data 53-2 is necessary. -2 is requested each time, as in the case of requesting -2, and the server 52 distributes the data individually at different times for each request.

  However, both the server and client systems in FIGS. 13A and 13B distribute the same data 53 at different times, so that the data transfer amount = the number of clients × the file size (if there are multiple files, each file The load on the servers and networks 56, 56-1, and 56-2 is large, and the traffic is congested. For this reason, programs and data are classified into a common file composed of programs and data common to all processors and a unique file composed of programs and data corresponding to each processor, and the processor receiving the common file is common A method of recognizing a processor to be loaded next from IPL (initial program load) control information describing a processor to which a file is to be loaded next, and sequentially transmitting a common file to the processor, and a plurality of file servers When a boot data request is received from one of the diskless computers via the network, the boot data is broadcast to a plurality of diskless computers all at once by broadcasting (broadcast communication to unspecified majority) after waiting for a predetermined time. A supply method has been proposed. (See Patent Documents 1 and 2)

  FIG. 15 shows another example of the data distribution procedure in the conventional server client system. In this example, similarly to the above-described conventional example, the server 52 is not limited to the client 55-1 requesting data, but via the LAN 56 by a sequential transfer method, broadcast, multicast (broadcast communication designating a number of other parties), or the like. This is an example of distribution to other clients 55-2 belonging to the same system. The client 55-1 requests the data 53-1 from the server 52, and the server 52 distributes the data 53-1 to the clients 55-1 and 55-2 simultaneously in response to the request. Next, the client 55-1 requests the data 53-2 from the server 52, and the server 52 distributes the data 53-2 to the clients 55-1 and 55-2 simultaneously in response to the request. Next, the client 55-1 requests the data 53-3 from the server 52, and the server 52 distributes the data 53-3 to the clients 55-1 and 55-2 simultaneously in response to the request. In this example, the server can distribute to the clients all at once, but different data is requested for each data, and is distributed for each data every time it is requested.

JP-A-61-228245 (FIGS. 1 to 4, page 300, upper right column, line 2 to page 301, upper left column, line 9) JP-A-06-168198 (FIGS. 1-4, paragraphs 0024-0049)

  However, not only when the server responds to data requests from individual clients one by one, but also when data is distributed all over the LAN to other clients belonging to the same system as well as the client that requested the data. The client makes a data request every time data is needed, and the server has to receive and distribute the request every time. In addition, when a large amount of data is required, each time a request is received and distributed, the data request and response must be repeated between the server and the client, especially when the number of clients is large. There was a problem that the number of requests that the server had to process increased, making it impossible to process. That is, there is a problem that the load on the server and the network increases.

  In particular, in a computer system for personal computer training (performing classes and exercises), when students start computers (clients) all at once, the number of data requests increases, and when the amount of data is large, it takes time to respond. There was a problem that the boot server could not handle the request. In class, students often perform specific operations at the same time in accordance with the instructions of the teacher, and there is a high frequency of concentration of access to the server, not just at startup. For this reason, since a response from the server cannot be obtained immediately, it often takes a long time to start the client. Since the amount of data transferred = number of clients x file size, if both the number of clients and the file size are large, the amount of data transferred becomes enormous, and it is also required when the number of accessed files is large. In many cases, the number of servers increases and the load on the server and the network increases. That is, the problem that the load on the server and the network increases is particularly remarkable.

  The present invention has been made in view of such problems. Even when the number of clients and the file size are both large or the number of accessed files is large, it can be distributed including related data by a single data request. An object of the present invention is to provide a server client system that can reduce the load on the server and the network.

  In order to achieve the above object, the server client system 1 according to the first aspect of the present invention, as shown in FIGS. 3 and 9, for example, includes specific application system data D1- including boot information and an operating system (OS). 1 to D2-n and a plurality of clients connected to the server 2 via the network 6 and acquiring specific application system data D1-1 to D2-n from the server 2 and used in a common environment The server client system 1 is composed of 5-1 to 5-n, and the server 2 monitors data requests from a plurality of clients 5-1 to 5-n, and data requests are made from any of the clients. The data requested data D1-1 and the possibility of subsequent access in relation to the data D1-1. That relevant data D1-2, the D1-3, multicasts to a plurality of clients 5-1 to 5-n.

  Here, boot information refers to data required from when the client is powered on until the desktop screen is displayed, and is included in some APs used to start the OS and system. The application system data naturally includes AP data (AP program and data). Accordingly, the application system data is roughly divided into OS and AP data, and boot information is included in a part of these OS and AP data. In addition, the term “used in a common environment” means that information is communicated according to a common protocol on a common network, such as classes and exercises using a personal computer, and a common OS and a common AP are used. Means used.

  With this configuration, even if the number of clients and the file size are both large or the number of files to be accessed is large, it is possible to distribute all of the related data including multicast data all at once by a single data request. A server client system that can reduce the load on the server and the network can be provided. In other words, even if the clients are started all at once, the data transfer amount is about 1 × file size, and it can be started in almost the same time as starting one client. Therefore, the load on the server and the network can be greatly reduced.

  The server client system 1 according to the second aspect of the present invention is the server client system according to the first aspect. For example, as shown in FIG. 12, the clients 5-1 to 5-n include a plurality of groups having different data sets. The server 2 distributes the common data that can be used by all groups to a plurality of clients in a multicast manner to the clients of each group, and distributes the individual data that can be used by each group by multicast.

  Here, as a plurality of groups, for example, a case where different classes are performed in classroom A and classroom B can be cited. In this case, AP data (AP program and data) used in the two classrooms may be different. For this reason, by dividing the client into the A classroom and the B classroom, the AP data can be distributed separately for the common classroom, the A classroom, and the B classroom. Moreover, since the data used by the development of classes and exercises can change, the data that can be used includes data that may be used in addition to the data that is actually used.

  With this configuration, the common data can be distributed in a batch including the related data with a single data request, and the load on the server and the network can be reduced. In addition, individual data can also be multicast distributed together with related data for each group, reducing the load on the server and the network. In addition, the same data can be distributed to a plurality of groups existing in the same segment on the LAN, or specific data can be distributed for each group. Also, grouping eliminates the need for different groups of unnecessary data.

  In particular, in a computer system for personal computer training, basically all students use the same program in class. Therefore, when one student requests the program as data and starts the program, the program is distributed to other students. That is, in a case where multicast distribution is performed without waiting for data requests from all attendees, a slow-growing student is always in a downloaded state and does not need to access the server. At the same time, since data related to the program, for example, another program required by the program, is distributed together, ideally communication between the server and the client is only the first OS data request and its response. There is a possibility that it can be done.

  The server client system 1 according to the third aspect of the present invention is the server client system according to the first aspect or the second aspect. For example, as shown in FIGS. 3 and 9, the server 2 starts data transmission. The distribution timer 13 for setting time is included, the clients 5-1 to 5-n have the standby timer 23 for setting the data reception standby time, and the server 2 receives a data request from one client belonging to the system. Is detected, the data transmission start time is set so that almost all clients that can use the data related to the data request can be received in the distribution timer 13, and the data in the standby timer 23 is sent to clients other than one client. Is it instructed to set the data reception waiting time corresponding to the transmission start time, and whether it is another client different from one client? When the same data request is detected, the data transmission start time set in the distribution timer 13 is extended and reset, and the data reception standby time set in the standby timer 23 is extended to clients other than the other clients. If the data transmission start time is reset, the last data transmission start time has elapsed.If the data transmission start time has not been reset, the first data transmission start time is set. When the time has elapsed, the requested data and related data are multicast-distributed to a plurality of clients, and the clients 5-1 to 5-n can make a data request to the server 2 and Clients voluntarily, clients other than one client receive standby data in response to a data reception standby time setting instruction from the server 2. The data reception standby time is set in the data 23, the data reception standby state is entered, and when the server 2 receives an instruction to extend the data reception standby time, the clients other than the other clients set the standby timer 23. The data reception standby time is extended and reset to continue the data reception standby state, and when the data requested by the server 2 and the related data are distributed by multicast, the data requested data and the related data are received. To do.

  Here, almost all clients that can use the data are almost all of the clients that belong to the system and are turned on (all attendees in the class and exercises). This means that there may be some leakage in consideration of traffic and PC troubles (for example, 90% if 9 out of 10). Data requests are typically made from all clients that belong to the system and are powered on. When starting up the OS for the first time, it may happen that multicast distribution cannot be received due to variations in client power-on, etc., so it is possible to receive a data request from all these clients and reset the distribution timer. It is necessary to do it appropriately. On the other hand, when the OS or AP is subsequently started, the client side enters the reception standby state all at once according to the data reception standby time setting instruction from the server 2 and can immediately prepare for reception. It is not necessary to repeatedly reset the data transmission start time and instruct to extend the data reception standby time each time a data request is made from the client. For example, when a predetermined time (for example, 1 min) is determined and a data request is made within the time (for example, 80%), the number of clients that have been turned on after the time (in this example, 1 min) has elapsed or belonged to the system After reaching a predetermined ratio (for example, 70%) of (the number of attendees), resetting may be performed, and multicast distribution may be performed after the resetting data transmission start time has elapsed, without resetting, Multicast distribution may be performed after the elapse of the data transmission start time. Also, after counting the number of data requests and reaching the number of clients that belong to the system and turned on, or in the ideal case such as when the system is stable, after detecting a data request from one client, Multicast distribution may be performed after the set data transmission start time elapses or immediately. Furthermore, if there is data that is surely requested even for data not related to the requested data, if the reception standby time is continued without canceling the data reception standby time, one client When the data request is received, the data transmission start time is set and the data reception standby time is continuously set. In addition, the data transmission start time need not be extended. In addition, when there are different data requests from a plurality of clients, it is preferable that the priority order of data is determined and the data is sequentially distributed according to the priority order. The data transmission start time sets a start time, and the data reception standby time sets an end time. Further, the data reception standby time corresponding to the data transmission start time means that the data reception standby time is set so that the data reception standby time ends after almost all data to be distributed is distributed. The data transmission start time reset last is the data transmission start time reset last when the reset is performed a plurality of times. When the resetting is performed only once, the resetting corresponds to the last resetting. If it is not reset, the data transmission start time is naturally the data transmission start time set first.

  With this configuration, when data is multicast distributed, the data transmission start time is determined using a distribution timer, so that data reception by clients that can use the data can be ensured, and efficient distribution can be performed. Can do. Further, by extending the data transmission start time in response to a data request from another client, the data reception of the client that can use the data can be further ensured.

The server client system 1 according to the fourth aspect of the present invention is the server client system according to the third aspect. The server 2 transmits a boot start instruction to the plurality of clients 5-1 to 5-n, and the client 5 -1 to 5-n start booting when a boot start instruction from the server 2 is received.
Here, boot refers to booting (starting) for displaying a specific application system on the desktop screen and making it operable after completion of boot information distribution related to the specific application system. With this configuration, booting can be performed all at once when the boot conditions are satisfied for a plurality of clients, and booting can be ensured.

Further, the server client system 1 according to the fifth aspect of the present invention is the server client system according to the third aspect, wherein the clients 5-1 to 5-n have a predetermined time after completion of boot information distribution related to a specific application system. Start booting after the lapse.
According to this configuration, booting is performed with a certain time margin even if there is no boot start instruction from the server, so that booting can be ensured.

  According to the present invention, even when the number of clients and the file size are both large or the number of files to be accessed is large, it is possible to distribute the data including related data by a single data request, thereby reducing the load on the server and the network. Server client system that can be provided.

It is a figure which shows the concept of the data delivery in the server client system of Example 1. FIG. 1 is a diagram illustrating a hardware configuration example of a server client system 1 of Embodiment 1. FIG. 1 is a diagram illustrating a functional configuration example of a server client system 1 according to a first embodiment. It is a figure which shows the example of a profile management table. It is a figure which shows the example of a processing flow of a server. It is a figure which shows the processing flow example (the 1) of a client. It is a figure which shows the example (2) of the processing flow of a client. It is a figure which shows the example (3) of a processing flow of a client. It is a figure which shows the example of an information communication sequence between the server and client in Example 1. FIG. It is a figure which shows the example of starting sequence between a server and a client. It is the figure which compared starting time. It is a figure which shows the example of an information communication sequence between the server in Example 2, and a client. It is a figure which shows the concept of the data delivery in the conventional server client system. It is a figure which shows the example of the data delivery procedure in the conventional server client system. It is a figure which shows another example of the data delivery procedure in the conventional server client system.

  Embodiments of the present invention will be described below with reference to the drawings. In the drawings, the same or corresponding parts are denoted by the same reference numerals, and redundant description is omitted.

  In this embodiment, an example of the server client system 1 in a personal computer training room will be described. A server 2 and a large number of clients 5 are connected via a LAN 6. For example, the server 2 is installed in the server room, and these clients 5 are installed in one training room.

  FIG. 1 shows the concept of data distribution in the server client system 1 of this embodiment. The boot server (server that also boots) 2 has a database 4 that stores specific application system data (disk image in this example) 3, and a plurality of clients 5-1 to 5-4 are connected via the LAN 6 to the boot server 2. It is connected to the. The application system data includes AP data (AP program and data) and OS. The boot information is included in a part of these OS and AP data. When one client belonging to the system, for example, 5-1 requests data 3 from the boot server 2, the same data 3 is distributed to each of the clients 5-1 to 5-4 by multicast distribution via the LAN 6. The related data related to is also distributed to each of the clients 5-1 to 5-4. Reference numeral 7 denotes a LAN 6 switch. Since multicast distribution is performed, the same file need only be transmitted once, and the related file need only be transmitted once. Thereby, the load of the server and the network 6 can be greatly reduced, and the number of servers can be reduced.

[System configuration]
FIG. 2 shows a hardware configuration example of the server client system 1 of the present embodiment. The server (boot server) 2 has an external storage device (database) 4 for storing specific application system data (disk image) 3, and a plurality of clients 5-1,. 2 is connected.

  The server 2 includes an external storage device 4, a central processing unit (CPU) 11, a memory 12, a timer 13, a network interface 14, and a bus 15 for connecting them. The external storage device 4 has data D1-1 to D1-n and D2-1 to D2-n as specific application system data distributed to the client 5. These data include OS and AP data. The boot information is included in a part of these OSs and a part of AP data. Therefore, these data include disk images. By acquiring these data, the client can use the AP in the same manner as when the application system is started from the hard disk. The CPU 11 reads the control program stored in the memory 12 and controls each part of the server 2 to cause the server 2 to execute a function as a boot server. The memory 12 stores a control program or the like in a ROM (read only memory), and temporarily stores data extracted from the external storage device 4 or control data or the like for distribution to a client (RAM). . The timer 13 is used as a distribution timer, and the data transmission start time is set so that all clients that can use the data can multicast the data 3 during reception standby. It should be noted that all clients are targets, and a case where some leakage occurs due to troubles such as traffic or PC is allowed. The network interface 14 processes data so as to conform to, for example, the TCP / IP protocol, and inputs / outputs data to / from the network 6.

  The clients 5-1,..., 5-n have an external storage device 20, a central processing unit (CPU) 21, a memory 22, a timer 23, a network interface 24, and a bus 25 for connecting them. The external storage device 20 is used to store specific application system data (OS and AP data) acquired from the server 2. “Cache” indicates an area in which acquired data is stored, and “Unused” indicates an empty space area. Note that specific application system data may be stored in the memory 22 instead of the external storage device 20 (see the client 5-n). The client 5 can use the AP by acquiring specific application system data such as OS and AP data including boot information. The CPU 21 controls each part of the client 5 by the OS 29 acquired from the server 2 and stored in the memory 22 to cause the client 5 to execute a function as a computer. The memory 22 stores the BIOS and the like in the ROM, and stores the OS, AP data, and the like acquired from the server 2 by the client 5 in the RAM. The timer 23 is used as a standby timer, and a data reception standby time (end time) for waiting for data (D1-1 etc.) requested for data multicast distribution from the server 2 and data related to the data is set. At that time, the client 5 stands by in a state where data can be received (data reception standby state), and temporarily stops the data request from the data request unit 26 to the server 2 during that time. The data reception standby time is set so that the data reception standby time ends after all data to be distributed is distributed. The network interface 24 processes data so as to conform to a protocol such as TCP / IP and inputs / outputs the data to / from the network 6. Note that all data is a target, and a case where some leakage occurs due to troubles such as traffic or PC is allowed.

  FIG. 3 shows a functional configuration example of the server client system 1 of the present embodiment. The server 2 is installed in the server room, and the clients 5-1 to 5-n belonging to the system are installed on the desks of teachers and students in the training room. Clients 5-1 to 5-n are started up at the start of the training. The clients 5-1 to 5-n acquire not only an AP related to personal computer training from the server 2, but also a disk image including boot information and an OS, start up, and use the AP. However, it is not necessary for the clients 5-1 to 5-n to acquire all of the data indicated by the data set (including the disk image), but to acquire the necessary part of the OS and the part necessary for executing the AP. It ’s fine. The server 2 publishes the data set by the HTTP server function. Further, the server 2 has a function (PXE) for causing the clients 5-1 to 5-n to perform network boot, and multicast distribution for simultaneously transmitting the same data to a plurality of specific clients 5-1 to 5-n. It has a function. Further, the server 2 may have a function (WOL) for powering on the clients 5-1 to 5-n by remote operation. In this embodiment, the server 2 has this function.

  Upon receiving a power-on request from the server 2, the clients 5-1 to 5 -n are activated by turning on their own power. At first, the client hardware (PXE-compatible BIOS and network interface) is minimally configured from the server 2 by PXE. Obtain the OS (kernel that is the core of the OS and the minimum mini-root necessary for boot activation). The minimum configuration OS is acquired in the OS area of the memory 22 and executed by the client. The OS 29 acquired in the OS area of the memory 22 prepares an environment necessary for execution of a specific application system (preparation of a desktop environment). The data request function, the standby timer function, and the multicast reception function are included in the minimum configuration OS, and operate before starting desktop preparation. Thereafter, environment preparation is executed by management of the OS 29 acquired in the OS area of the memory 22. The OS with the minimum configuration makes a data request for data necessary for starting up the remaining part (disk image) of the OS. In this way, the OS 29 is sequentially acquired in the OS area. It is preferable that the portion related to boot information in the OS is acquired at an early stage. When the OS 29 necessary for a specific application system is acquired in the OS area by the net boot, the OS 29 sequentially requests disk images related to the AP. It is preferable that the part related to the boot information in the AP is acquired at an early stage. When the data transmission start time comes on the server 2 side, each data (disk image) is distributed by multicast.

  The server 2 monitors the data request from the client, and multicasts the requested data and related data. Then, synchronous control is performed with a timer, and delivery is performed simultaneously. When the disk image is multicast-distributed from the server 2, the clients 5-1 to 5-n acquire the disk image, perform booting, and use the AP in the same manner as when the application system is started from the hard disk. Can do. Booting (startup) is possible at the stage when boot information of the OS and AP is acquired. Other APs may be acquired before booting or after booting. Multicast distribution before and after booting is possible.

  The server 2 includes a data request management unit 16, a distribution timer setting unit 17, and a distribution management unit 18 in the CPU 11. The data request management unit 16 monitors the data request from the client, and if there is a data request from one client (for example, 5-1) in the system via the network interface 14, the data request management unit 16 The distribution timer 13 is instructed to set the data transmission start time, and the distribution timer setting unit 17 sets a predetermined data transmission start time in the distribution timer 13. The data transmission start time is set in advance to a time sufficient for all clients (attendants 5-1 to 5-m) that can use the data among the clients belonging to the system to wait for data reception. In addition, the delivery timer setting unit 17 instructs the clients 5-1 to 5-m to set the reception standby time (end time) via the network interface 14. In response to this instruction, the clients 5-1 to 5-m stand by in a state where data can be received, and set the reception standby time in the standby timer 23. In addition, when there is a data request from another client (for example, 5-2) in the system via the network interface 14, the data request management unit 16 sets the distribution timer 13 to the distribution timer 13. The distribution timer setting unit 17 extends and resets the data transmission start time to the distribution timer 13, and instructs the clients 5-1 to 5-m (5 (Except -2) is instructed to extend and reset the reception standby time (end time) via the network interface 14. The reason for this extension is to ensure that all clients that can use the data can obtain the data.

  Data requests are typically made from all clients that belong to the system and are powered on. When starting up the OS for the first time, it may happen that multicast distribution cannot be received due to variations in client power-on, etc., so it is possible to receive a data request from all these clients and reset the distribution timer. It is necessary to do it appropriately. On the other hand, when the OS or AP is subsequently started, the client side enters the reception standby state all at once according to the data reception standby time setting instruction from the server 2 and can immediately prepare for reception. It is not necessary to repeatedly reset the data transmission start time and instruct to extend the data reception standby time each time a data request is made from the client. For example, when a predetermined time (for example, 1 min) is determined and a data request is made within the time (for example, 80%), the number of clients that have been turned on after the time (in this example, 1 min) has elapsed or belonged to the system After reaching a predetermined ratio (for example, 70%) of (the number of attendees), resetting may be performed, and multicast distribution may be performed after the resetting data transmission start time has elapsed, without resetting, Multicast distribution may be performed after the elapse of the data transmission start time. Also, after counting the number of data requests and reaching the number of clients that belong to the system and turned on, or in the ideal case such as when the system is stable, after detecting a data request from one client, Multicast distribution may be performed after the set data transmission start time elapses or immediately. Furthermore, if there is data that is surely requested even for data not related to the requested data, if the reception standby time is continued without canceling the data reception standby time, one client When the data request is received, the data transmission start time is set and the data reception standby time is continuously set. In addition, the data transmission start time need not be extended. Further, the data request management unit 16 registers the data requested by the distribution management unit 18 and related data from the external storage device 4 to the distribution waiting data queue table 19A of the memory 12, and when the data transmission start time comes, the data request management unit 16 An instruction is sent to the clients 5-1 to 5-m via the interface 14. Data related to the requested data is registered in the profile management table 19B in the memory 12. The external storage device 4 stores a data set D1 (data D1-1 to D1-n) and a data set D2 (data D2-1 to D2-n), and each data is blocked as a disk image. However, the kernel and miniroot are not subject to blocking.

  FIG. 4 shows an example of the profile management table 19B. The left column lists the requested data, and the right column lists the data related to the data. For example, data D1-2 and D1-3 are related to data D1-1. Data D1-2 is associated with data D1-3 and D1-6. When the data D1-1 is requested by tracing this, the data D1-2, D1-3, D1-6, etc. are listed as related data.

  The distribution management unit 18 extracts the requested data and related data from the external storage device 4 to the distribution waiting data queue table 19-1 in the memory 12 with reference to the profile management table 19B. When the data transmission start time is reached (the distribution timer times out), the distribution timer 13 is reset, and a timeout signal is transmitted to the distribution management unit 18 via the distribution timer setting unit 17. Further, the distribution timer setting unit 17 requests the clients 5-1 to 5-m via the network interface 14 to request the data requested by all clients who can use the data (all attendees in classes and exercises) and related data. To set the end time of the reception waiting time so that it can be received. In addition, all are targets, and there may be some leakage in consideration of trouble. Upon receiving the timeout signal, the distribution management unit 18 sends the requested data extracted in the distribution queue data queue table 19-1 of the memory 12 and related data to the clients 5-1 to 5-5 via the network interface 14. Multicast to m. The synchronization between the server 2 and the clients 5-1 to 5-m may be performed only at the time of the first data distribution, and all clients that can use the data can reliably acquire the data by this one synchronization. When the multicast distribution ends, the distribution timer setting unit 17 instructs the clients 5-1 to 5-m to cancel the reception standby time via the network interface 14.

  The clients 5-1 to 5-n include a data request unit 26, a standby timer setting unit 27, a reception management unit 28, and an OS 29. The clients 5-1 to 5-n do not own the OS themselves, and acquire the OS and boot information from the server 2 by using the PXE function of the server 2. In this embodiment, PXE is used to read the OS (kernel, miniroot, etc.) having the minimum configuration from the server 2 through the BIOS and the network interface when the power is turned on. The minimum configuration OS sets the data request unit 26, and thereafter the OS sequentially instructs the data request unit 26 to request data for the OS and AP data (AP program and data). First, a portion of the OS that is necessary for startup is sequentially requested and acquired, and then AP data is sequentially requested and acquired. Since the data to be requested is taken into the OS by the server 2 or supplied from the server 2 along with the OS, if the client devices have the same performance, the data request is made at almost the same timing. Become. In this way, the data request unit 26 sequentially requests necessary data from the HTTP server and downloads it to the OS area of the memory 22. Further, the data request unit 26 has a function of a virtual block device driver. In other words, even if only the data of the part that is actually accessed is held, the OS 29 functions to make the entire data appear on the clients 5-1 to 5-n. For example, when there are 100 files in the data set of the server 2, even if it appears that there are 100 files on the clients 5-1 to 5-n when viewing the list from the OS 29, the data actually used (for example, 20 Only) the client provides the function of downloading. When the OS 29 requests the 21st file, an access to a file that does not exist normally results in an error, but the virtual block device driver stores the corresponding file (included) data from the server 2 into the memory. 22 and the OS 29 can normally access the file by notifying the OS 29 of the address. In addition, the data request unit 26 instructs the standby timer setting unit 27 to set the data reception standby time (end time) in the standby timer 23 when the data request is made. A predetermined data reception standby time is set in the reception timer 23. The data reception standby time is determined in advance so that the server 2 can receive the data when multicasting the data after the data transmission start time has elapsed. In addition, the standby timer setting unit 27 instructs the reception management unit 28 to secure a cache area in which data is written in the memory 22 so that the multicast distribution data can be received. The data request from the data request unit 26 to the server 2 is temporarily stopped. Further, when receiving an instruction for extending the data reception standby time (end time) from the server 2 via the network interface 24, the standby timer setting unit 27 resets the data reception standby time to be extended. In addition, the standby timer setting unit 27 instructs the reception management unit 28 to secure a cache area for writing data so that the multicast distribution data can be received until the reception standby time ends. During the data reception standby state, the data request from the data request unit 26 to the server 2 is temporarily stopped.

  Multicast distribution of data from the server 2 is started, and the reception management unit 28 continues the reception standby state during the reception standby time, identifies and receives the data distributed from the server 2 via the network interface 24, and receives the memory. Data distributed to the cache area 22 is written. When the standby timer setting unit 27 receives an instruction to set the reception standby time from the server 2, the end time of the data reception standby time is set. The end time is set to end after distributing all data to be distributed. All are targets, and there may be some leakage. When there is an instruction to cancel the data reception standby time from the server 2 or when the standby timer 23 times out, the data reception standby time ends, the standby timer 23 is reset, and the reception management unit is set via the standby timer setting unit 27. A time-out signal is transmitted to 28. When receiving the timeout signal, the reception management unit 28 releases the reception standby state. The data written in the cache area of the memory 22 is moved to the cache area of the external storage device 20 as appropriate according to the situation. When it is moved to the external storage device 20, it can be used for starting a specific application system when the power is turned on next time. The client 5-1 that has acquired the specific application system data from the server boots and can use the specific AP. Note that not all AP data is necessarily required for booting, and it is possible to perform booting at the stage when an OS related to booting and a program related to booting APs are acquired. The data may then be requested for data.

[Processing flow]
FIG. 5 shows a processing flow example of the server. The data request management unit 16 monitors data requests from clients (S101). The system waits until a data request from one client in the system is detected. When a data request is detected (YES in S102), the distribution timer setting unit 17 sets a data transmission start time (S103). Further, the distribution timer setting unit 17 instructs the clients 5-1 to 5-m (excluding one client) to set the reception standby time (end time) (S104). Thereafter, when a data request from another client is detected, the distribution timer setting unit 17 extends and resets the data transmission start time, and the distribution timer setting unit 17 sets the clients 5-1 to 5-m ( (Except for other clients) is instructed to extend and reset the reception wait time (ie, continue the reception wait time). If the data transmission start time is reset, the data is requested when the last reset data transmission start time has passed.If not reset, the data request is sent when the first data transmission start time has passed. Data and related data are distributed to a plurality of clients by multicast. Here, the data transmission start time reset last is the data transmission start time reset last when the reset is performed a plurality of times. When the resetting is performed only once, the resetting corresponds to the last resetting. If it is not reset, the data transmission start time is naturally the data transmission start time set first. Thus, although not shown, the data request monitoring (S101) to the reception standby continuation instruction (S104) are repeated. The distribution timer setting unit 17 waits until the data transmission start time while keeping the clients 5-1 to 5-m in the reception standby state (S104), and starts multicast distribution when the data transmission start time times out (YES in S105). To do. When the time-out occurs, the server 2 instructs the clients 5-1 to 5-m to set the reception standby time (end time) so that the reception standby time ends after multicast distribution ends (S106). The distribution management unit 18 registers the requested data and related data in the distribution waiting data queue table 19-1 of the memory 12 (S107), and when the data transmission start time times out, the requested data and related data are stored. The data to be read is read from the distribution-waiting data queue table 19-1 (S108), and is multicast distributed to the clients 5-1 to 5-m (S109). After the multicast distribution ends, the server 2 instructs the clients 5-1 to 5-m to cancel the reception standby time, and when the clients 5-1 to 5-m receive the reception standby time cancellation instruction, The reception standby state is terminated. Further, when the reception standby time cancel instruction is not received by the clients 5-1 to 5-m, the reception standby state is ended by the timeout of the standby timer 23 in which the reception standby time (end time) is set.

  FIGS. 6 to 8 show examples of client processing flows. In the client, the following three processes, the processes of FIGS. 6 to 8, are performed in parallel. FIG. 6 is an example of a processing flow relating to a data request. When the power is turned on, a minimum configuration OS (kernel, miniroot, etc.) is read from the server 2 into the OS area of the memory 22 by the BIOS and the network interface using PXE. Thereafter, the OS having the minimum configuration sets the data request unit 26, and the OS 29 instructs the data request unit 26 to sequentially request data for the OS and AP data (AP program and data). First, a portion of the OS that is necessary for startup is sequentially requested and acquired, and then AP data is sequentially requested and acquired. The data request unit 26 receives a data read request from the OS 29 (S201). If the data requesting unit 26 can read data from the cache area of the external storage device 20 or the memory 22, that is, if the data requesting unit 26 already holds the data (YES in S202), the data requesting unit 26 sets the fact and the address of the data. The OS 29 is notified (S203), and the next data read request is received (S201). If data cannot be read from the cache area, that is, if data is not yet held (NO in S202), a data request is made to the server 2 (S204). Thereafter, the reception management unit 28 waits for data distributed by multicast from the server, receives the data when it is distributed (S221 in FIG. 8), and notifies the OS 29 of that fact and the address of the received data (S205). Thereafter, for the next data, the data request unit 26 receives a data read request from the OS 29 (S201).

  FIG. 7 is an example of a processing flow related to data reception standby. The standby timer setting unit 27 sets the data reception standby time (end time) of the standby timer 23, and secures a cache area for writing data in the memory 22 so that the multicast distribution data can be received by the reception management unit 28. And instructing the server 2 to temporarily stop the data request from the data request unit 26 during the data reception standby state. Then, it waits for a standby cancellation instruction from the server 2 or a timeout of the standby timer 23 (S211). If there is no standby continuation instruction (extension instruction) from the server 2 (NO in S212), the process waits as it is, and if there is a standby continuation instruction (extension instruction) (YES in S212), the data reception standby time (end time) is extended. (S213). Thereafter, if there is no standby release instruction from the server 2 (NO in S214), the process waits as it is, and if there is a standby release instruction (YES in S214), the data reception standby time is immediately released (S215). Further, the data reception standby time is canceled even if an end instruction is not received from the server due to a timeout of the standby timer 23 relating to the end time. FIG. 8 is an example of a processing flow relating to data reception. The reception management unit 28 waits for data distributed by multicast from the server 2 and receives it when the data is distributed (S221). The reception management unit 28 writes the received data in the cache area of the memory 22 (S222). After that, it waits for the next multicast distributed data (S221).

  FIG. 9 shows an example of an information communication sequence between the server and the client. Refer to FIGS. 5 to 8 for each processing flow. With the server 2 as the center, the client 5-1 is shown on the left side and the client 5-2 is shown on the right side. The vertical axis represents time. The client 5-1 requests data D1-1 from the server 2 (S204), sets a data reception standby time in the standby timer 23 (S211), and waits in a data reception standby state (S213). When the server 2 receives the data request (S102), the server 2 sets a data transmission start time in the distribution timer 13 (S103). Next, when a data request is made for data D1-1 from the client 5-2 to the server 2 (S204), the client 5-2 sets a data reception standby time in the standby timer 23 (S211) and waits for data reception. Wait in a state (S213). Upon receiving the data request (S102), the server 2 extends the data transmission start time to the delivery timer 13 and resets it (S103), and extends the data reception standby time to the client 5-1 and resets it. An instruction is given (S104). When the data transmission start time has elapsed (YES in S105), the server 2 multicasts the data D1-1 to the client 5-1 and the client 5-2 (S109), and the client 5-1 and the client 5-2 receive the data D1. -1 is received (S221). The server 2 multicasts the data D1-1 and the data D1-2 related to the data D1-1 to the client 5-1 and the client 5-2 (S109), and the client 5-1 and the client 5-2 Data D1-2 is received (S205). The server 2 further multicasts the data D1-2 and the data D-3 related to the data D1-1 to the client 5-1 and the client 5-2 (S109), and the client 5-1 and the client 5-2. Receives the data D1-3 (S221). In this way, data requested by one data request and related data that may be accessed in connection with the data are multicast-distributed to a plurality of clients. In the figure, the number of clients is shown up to 2, but even when there are a large number of clients, the data requested by one data request and related data are multicast distributed to a plurality of clients.

  FIG. 10 shows an example of an activation sequence between the server and the client. The boot server 2 has functions of a DHCP server, a TFTP server, and an HTTP server. The HTTP server refers to a server that performs network communication in accordance with the TCP / IP protocol, and the DHCP server causes the server to automatically read information necessary for startup on the TCP / IP network, and start (boot) it. A server that provides an IP address to a client, and a TFTP server refers to a server that provides a kernel that is the core of an OS, such as a Linux (UNIX (registered trademark) -like OS) kernel, a minimal root required for booting, and the like. . That is, the server 2 has a function (PXE) for causing the client 5 to perform a network boot. Further, the server 2 may have a function (WOL) for turning on the client 5 by remote operation.

  When the client 5 is powered on, the client 5 acquires a minimum configuration OS (kernel, miniroot, etc.) from the server 2 by PXE. The client 5 executes the OS having the minimum configuration, and sequentially requests the remaining part of the OS necessary for booting, the related OS, and a specific application system file (data) from the server 2. The server 2 receives the data request from the client 5 and detects the client 5 to be activated. However, in the PC training room, etc., there are a large number of clients to be activated and a large number of files, so if the data requests were individually dealt with, the operation of the server would be enormous and the network burden would be enormous. It takes an enormous amount of time to activate all the clients (attendants) who can use the data. For this reason, the server 2 has a multicast distribution function for transmitting the same data to a plurality of specific clients 5 at the same time, and not only the requested data but also the related data required thereafter by a single request. Are distributed to the client 5 and supplied to the client 5. When a data request is received from any of the clients 5 in the system, the server 2 sends a distribution timer 13 so that all the clients (attendants) that can use the data can receive the multicast data in a standby state where the data can be received. The data transmission start time (end time) is set, and the client 5 sets the data reception standby time in the standby timer 23 to synchronize and distribute all at once. The client 5 waits so that it can receive data distributed by multicast. When there is a data request from another client, in order to ensure data reception, the server 2 extends and resets the data transmission start time, and the client 5 extends the data reception standby time and resets it. When set, multicast distribution is performed. By receiving these data, the client 5 starts (boots) the system and can use the OS and AP data related to the specific application system. Note that not all AP data is necessarily required for booting, and it is possible to perform booting at the stage when an OS related to booting and a program related to booting APs are acquired. The data may then be requested for data.

  For booting a specific application system (after completing the distribution of boot information related to a specific application system, displaying the specific application system on the desktop screen and making it operable), the server 2 starts booting to a plurality of clients 5 By sending an instruction and starting the boot when the client 5 receives the boot start instruction from the server 2, the boot can be performed all at once when the boot conditions are satisfied for a plurality of clients, and the boot is ensured. Can be Further, if the client 5 starts booting after a certain period of time has elapsed after completion of boot information distribution related to a specific application system, the booting is performed with a certain time margin even if there is no boot start instruction from the server. So you can be sure of booting.

  FIG. 11 is a diagram in which the startup time according to the present embodiment is compared with the conventional one. The abscissa indicates the number of clients that are simultaneously activated, and the ordinate indicates the total client activation completion time (sec). The black rhombus ◆ is actually measured data by the multicast distribution method in this embodiment, and the black square ■ is actually measured data by the conventional individual request / response method. In the individual request / response method, the startup completion time increases linearly with the increase in the number of units, whereas in the multicast distribution method, even if the number of units increases, up to 40 units can be processed in almost the same time as starting up one unit. . In this way, there is a four-fold difference in start-up completion time between the multicast distribution method and the individual request / response method in the number of 40 units, and the difference is expected to increase further as the number increases, so the number is large. Indeed, the effect of shortening the startup completion time by the multicast distribution method is great.

  According to the present embodiment, even when the number of clients and the file size are both large or the number of accessed files is large, it is possible to distribute the data including related data by a single data request, thereby reducing the load on the server and the network. A server client system that can be reduced can be provided.

  In the first embodiment, an example in which the same data is multicast distributed to all clients has been described. In this embodiment, an example will be described in which clients are classified into a plurality of groups having different data sets and distributed. As a plurality of groups, for example, a case where different classes are performed in the A classroom and the B classroom can be cited. In this case, the AP program and data to be used may be different. For this reason, by dividing the client into the A classroom and the B classroom, the AP program and data can be distributed for common use, for the A classroom, and for the B classroom. That is, the clients 5-1 to 5-n are classified into a plurality of groups having different data sets, and the server collectively distributes common data that can be used by all groups to the clients of each group. Then, individual data that can be used by each group is distributed by multicast. The server manages which group it belongs to.

  FIG. 12 shows an example of an information communication sequence between the server and the client in this embodiment. The server 2 is shown on the leftmost side, and the clients 5-1 and 5-2 belonging to the first group and the client 5-3 belonging to the second group are sequentially shown from the left side to the right side. The vertical axis represents time. The client 5-1 requests data D1-1 from the server 2 (S204), sets a data reception standby time in the standby timer 23 (S211), and waits in a data reception standby state (S213). When the server 2 receives the data request (S102), the server 2 sets a data transmission start time in the distribution timer 13 (S103). Next, when a data request is made for data D1-1 to the server 2 from the clients 5-2 and 5-3 (S204), the clients 5-2 and 5-3 set the data reception standby time in the standby timer 23. (S211), and waits in a data reception standby state (S213). Upon receiving the data request (S102), the server 2 extends the data transmission start time to the delivery timer 13 and resets it (S103), and extends the data reception standby time to the client 5-1 and resets it. An instruction is given (S104). When the data transmission start time has elapsed (YES in S105), the server 2 multicasts the common data D1-1 to the clients 5-1 to 5-3 (S109), and the clients 5-1 to 5-3 receive the data D1- 1 is received (S221). The server 2 multicasts the common data D1-1 and the common data D1-2 and D1-3 related to the data D1-1 to the clients 5-1 to 5-3 following the common data D1-1 (S109). 5-3 receives the common data D1-2 and D-3 (S221). When the multicast distribution of the common data D1-1 and the related common data D1-2 and D1-3 is completed, the clients 5-1 to 5-3 cancel the data reception standby state (S215).

  Thereafter, the clients 5-1 and 5-2 belonging to the first group request data D2-1, the server 2 sets the data transmission start time (S103), and the clients 5-1 and 5-2 receive the data. Wait in a standby state (S213). The server 2 multicasts individual data D2-1 and individual data D2-2 related to D2-1 to the clients 5-1 and 5-2 belonging to the first group (S109), and the clients 5-1 and 5-2. Receives the data D2-1 and D2-2 (S221). When the multicast distribution of the individual data D2-1 and the related individual data D2-2 is completed, the clients 5-1 and 5-2 cancel the data reception standby state (S215). Although an example in which the data transmission start time is set after data requests from two clients has been described, multicast distribution may be performed by extending the data transmission start time for each data request from the clients. Furthermore, when there is data that is surely requested for data even with individual data, if the reception standby time is continued without releasing the data reception standby time after the common data is distributed, 1 belonging to the first group. When a data request from one client is received, the data transmission start time is set and the data reception standby time is continuously set. In addition, it is not necessary to extend the data transmission start time. Next, the client 5-3 belonging to the second group requests data D3-1, the server 2 sets a data transmission start time (S103), and the client 5-3 waits in a data reception standby state (S213). ). The server 2 multicast-distributes the individual data D3-1 and the individual data D3-2 related to D3-1 to the client 5-3 belonging to the second group (S109), and the client 5-3 receives the data D3-1, D3- 2 is received (S221). When the multicast distribution of the individual data D3-1 and the related individual data D3-2 is completed, the client 5-3 cancels the data reception standby state (S215). Note that multicast distribution may be performed by extending the data transmission start time for each data request from the client. Furthermore, if there is data that is requested to be requested even for individual data, if the reception standby time is continued without releasing the data reception standby time after the common data is distributed, 1 belonging to the second group. When a data request from one client is received, the data transmission start time is set and the data reception standby time is continuously set. In addition, it is not necessary to extend the data transmission start time.

  As described above, the server 2 performs multicast distribution of common data that can be used by all groups to a plurality of clients at once, and multicast distribution of individual data that can be used by each group. In this way, data with different data sets is distributed to each group. As a result, with respect to common data, data including related data can be collectively distributed by a single data request, and the load on the server and the network can be reduced. In addition, individual data can also be multicast distributed together with related data for each group, reducing the load on the server and the network. In addition, the same data can be distributed to a plurality of groups existing in the same segment on the LAN, or specific data can be distributed for each group. In addition, grouping eliminates unnecessary data.

  Although the embodiments of the present invention have been described above, the present invention is not limited to the above-described embodiments, and it is obvious that various modifications can be made to the embodiments without departing from the spirit of the present invention. .

  For example, in the above embodiment, an example of a personal computer training room has been described. However, the present invention can also be used for correspondence education, lectures, seminars, lectures, and conferences using personal computers. In the first embodiment, an example in which the client is installed in one training room has been described. However, the client may be installed in training rooms in Tokyo and Osaka, for example. In the second embodiment, an example in which lessons and exercises in a plurality of classrooms are grouped and used for each classroom has been described. However, the lessons and exercises may be grouped by exercises in one training room. In addition, the example of starting the attendee client among the clients belonging to the system was explained, but all clients may be started so that late students can participate, and the number of clients who are expected to participate is started. In order to cope with an accident such as a failure, a client may be started in which a surplus is added to the expected number of participants. In the above embodiment, the example in which the AP data is distributed after the OS is distributed has been described. However, a part of the AP data may be distributed before the partial OS. In the above embodiment, an example in which the OS makes a data request fetched internally by the server has been described. However, a part related to the client in the profile management table is distributed from the server to each client, and the data is The OS may be able to request data by referring to the request. In addition, the number of clients, data transmission start time, data reception standby time, and the like can be appropriately changed. The present invention is not only an invention of a server client system and a server and a client constituting the server client system, but also an invention of a data distribution method described in the embodiment, and a program for causing a computer to execute the data distribution method This invention can also be realized.

  The present invention can be used for a server client system for education, lecture, conference and the like.

1 server client system 2 server 3 data 4 database (external storage device)
5,5-1 to 5-n Client 6 Network (LAN)
7 Switch 11 CPU
12 memory 13 distribution timer 14 network interface 15 bus 16 data request management unit 17 distribution timer setting unit 18 distribution management unit 19A distribution waiting data queue table 19B profile management table 20 database (external storage device)
21 CPU
22 memory 23 standby timer 24 network interface 25 bus 26 data request unit 27 standby timer setting unit 28 reception management unit 29 OS
51A, 51B Server client system 52, 52-1, 52-2 Boot server 53, 53-1 to 53-3 Data 54 Database 55, 55-1 to 55-4 Client 56, 56-1, 56-2 Network ( LAN)
57 Switches D1-1 to D1-n, D2-1 to D2-n, D3-1 to D3-2 Data

Claims (5)

A server capable of supplying specific application system data including boot information and an operating system; and a plurality of clients connected to the server via a network and acquiring the specific application system data from the server and used in a common environment A configured server client system;
The server monitors data requests from the plurality of clients, and when a data request is made from any of the clients, the data requested by the data and a relation that may be accessed in relation to the data. Multicast delivery of data to the plurality of clients;
Server client system. The clients are classified into a plurality of groups having different data sets, and the server collectively distributes common data that can be used by all groups to the clients of each group, and is used by each group. Possible individual data by multicast distribution by group;
The server client system according to claim 1. The server has a delivery timer for setting a data transmission start time;
The client has a standby timer for setting a data reception standby time;
When the server detects an initial data request from one client belonging to the system, the server sets a data transmission start time so that almost all clients that can use the data related to the data request can receive the distribution timer. And instructing clients other than the one client to set a data reception standby time corresponding to the data transmission start time in the standby timer,
When the same data request is detected from another client different from the one client, the data transmission start time set in the delivery timer is extended and reset, and the standby timer is set to a client other than the other client. Instructed to extend and reset the data reception waiting time set in
When the data transmission start time is reset, the last data transmission start time has elapsed; otherwise, when the first data transmission start time has elapsed, the data Multicasting the requested data and the related data to the plurality of clients;
The client can make the data request to the server;
One client that made the data request voluntarily, and clients other than the one client set the data reception standby time in the standby timer according to the data reception standby time setting instruction from the server, and the data Enter the standby state for reception,
When there is an instruction to extend the data reception standby time from the server, the clients other than the other clients extend the data reception standby time set in the standby timer and reset the data reception standby time. Continue,
Receiving the data-requested data and the related data when the data-requested data and the related data are multicast-delivered from the server;
The server client system according to claim 1 or 2. The server sends a boot start instruction to the plurality of clients;
The client starts booting upon receiving a boot start instruction from the server;
The server client system according to claim 3. The client starts booting after a predetermined time has elapsed after completion of boot information delivery related to a specific application system;
The server client system according to claim 3.