Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Method for a client machine to multicast install status to specific, multiple servers

IP.com Disclosure Number: IPCOM000020992D
Original Publication Date: 2003-Dec-16
Included in the Prior Art Database: 2003-Dec-16
Document File: 2 page(s) / 41K

Publishing Venue

IBM

Abstract

Method for a client machine to multicast install status to specific, multiple servers.

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

Page 1 of 2

Method for a client machine to multicast install status to specific, multiple servers

In most network install environments, there is a one-to-one relationship between the install server and the install client. When a client machine needs installing, the owner (or admin) is responsible for configuring the network install environment and basically shepherding the install. Once complete, the machine is made available to the owner and/or users.

In a large tech environment there may be multiple admins responsible for any given set of machines. The machine sets (in some cases) tend to overlap amongst admins. When this happens, admins find themselves unaware of when a machine is scheduled for install or even completed from an install. Since the machine sets may overlap within each admin's network install environment, the install client needs a way of notifying any install server which may have interest in the client's machine status.

AIX* uses the Network Installation Management (NIM) package for installing and managing client machines. The NIM topology consists of a managing server (master) and a set of install clients. In this environment, the NIM master is capable of monitoring/installing any client defined to exist in the master's NIM environment. The NIM master uses an ODM database to store machine status and install status for each client. The situation described in previous paragraphs happens when multiple masters define the same client(s) to exist in each of their NIM environments. As long as the NIM master has permission on the client, it is capable of invoking commands irrespective of what another NIM master may be doing or what state another NIM master perceives the client to be in.

The client can make use of locking methods to not allow more than one NIM master operation at a time, but it still doesn't solve the problem of having different client status on each NIM master. The NIM masters can make use of database synching, but what happens when a master goes offline; how will the client notify the master who initiated the command of it's return status? A better solution would be for the client to keep a list of "interested" parties (in our case, NIM masters) and report it's status to each party member.

This patent proposes that each install client keep a list of members to notify when status changes have occurred. The notify list would allow the install client to make use of multicast (or broadcast) for sending it's status information to those needing to be informed. By keeping a list of notify members, the install client ensures that all servers receive the same status. In our NIM example, status is consistent without the need for master's to synchronize with each other. This means less network traffic since the multicast data is placed on the network once; also less data overhead for sy...