US20020046260A1 - Managing networked directory services with auto field population - Google Patents
Managing networked directory services with auto field population Download PDFInfo
- Publication number
- US20020046260A1 US20020046260A1 US09/405,292 US40529299A US2002046260A1 US 20020046260 A1 US20020046260 A1 US 20020046260A1 US 40529299 A US40529299 A US 40529299A US 2002046260 A1 US2002046260 A1 US 2002046260A1
- Authority
- US
- United States
- Prior art keywords
- network management
- service
- remote source
- field
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
- Y10S707/99935—Query augmenting and refining, e.g. inexact access
Definitions
- the present invention relates to the field of networked systems and, in particular, to a method and apparatus for dynamically managing networked directory services.
- Networking of computing elements and, in particular, the implementation of client/server networks, wherein the client is the initiating node and the server is the responding node (i.e., not necessarily referring to a file “server” or an application “server”), are known.
- Examples of these networks include local area networks (LANs), wide area networks (WANs), global networks (Internet), and the networking of telecommunications devices (i.e., cellular networks, PCS networks, wireline telephony networks), and the like.
- TCP/IP Transmission Control Protocol/Internet Protocol
- IPX Internetwork Packet exchange
- UDP/IP User Datagram Protocol/Internet Protocol
- the OS “hangs” (i.e., seemingly “freezes” in an unrecoverable state)
- the user is, in essence, locked out from the operational state of the computer and the only recourse is to restart the OS (e.g., by rebooting the computer).
- GUI graphical user interface
- a network management service for facilitating the management of networked devices by network management applications (a.k.a., agents) is described.
- the network management service comprises an agent discovery service for discovering and registering remote management agents, and a file transfer service operative to send information to and receive information from remote systems.
- FIG. 1 is a block diagram illustrating an example network of computer systems incorporated with the teachings of the present invention
- FIG. 2 is a block diagram of a network management service incorporated with the teachings of the present invention.
- FIG. 3 is an illustration of a simple file transfer datagram used to communicate between network management services
- FIG. 4 is a flow chart depicting the method steps for pushing a file from a client to a server utilizing the network management service of FIG. 2;
- FIG. 5 is a flow chart depicting the method steps for pulling a file from a server to a client utilizing the network management service of FIG. 2;
- FIG. 6 is an illustration of a remote execution datagram used to communicate between network management services
- FIG. 7 is a flow chart depicting the method steps of one example of remotely configuring an unconfigured client utilizing a network management service, in accordance with the teachings of the present invention
- FIG. 8 is a block diagram illustrating an example of an unconfigured client computer
- FIG. 9 is a block diagram depicting the method steps of FIG. 7 from a high-level network architecture view
- FIG. 10 is a flow chart illustrating the method steps for enabling remote power management using the network management service of FIG. 2, in accordance with the teachings of the present invention
- FIG. 11 illustrates a flow chart for an example method of dynamically managing networked directory services, in accordance with one embodiment of the present invention.
- FIG. 12 graphically illustrates an example directory service which is dynamically managed in accordance with the teachings of the present invention, in accordance with one embodiment of the present invention.
- network 100 is comprised of a plurality of computing elements, at least a subset of which include the teachings of the present invention.
- at least a subset of the computing elements comprising network 100 are disposed with an innovative network management services, incorporated with the teachings of the present invention, enabling an improved level of network manageability and interoperability independent of the myriad of operating systems that may reside within network 100 .
- the innovative network management services of the present invention may also be used to dynamically manage networked directory services.
- the network management service incorporating the teachings of the present invention enables a network management application (also commonly referred to as network management agent, or NMA), for example, to interrogate and manipulate network resources on behalf of managed directory services utilizing the teachings of the present invention.
- a network management application also commonly referred to as network management agent, or NMA
- NMA network management agent
- network 100 is shown comprising clients 102 and 104 , and servers 106 and 108 , interconnected to each other via network medium 120 .
- clients 102 and 104 are personal computer systems, while in an alternate to embodiment, clients 102 and 104 are telecommunication network devices.
- network medium 120 is intended to represent a broad category of networking infrastructure including network cables and their associated switching (routing), repeater, and/or delay elements, suitable for a high speed local area network (LAN), or a slower speed wide area network (WAN), or public network (i.e., Internet) implementations known in the art.
- LAN local area network
- WAN wide area network
- Internet public network
- server includes but is not necessarily limited to a “file” server or an “application” server.
- clients 102 and 104 include client application(s) 120 and 122 , client operating system (OS) 130 and 132 , network transport services 140 and 142 (sometimes referred to as the transport layer), operatively coupled as depicted.
- client 102 is shown further comprising network management service 150 incorporated with the teachings of the present invention.
- a network management service e.g., network management service 150
- may be beneficially incorporated into each of the computing elements of network 100 may be beneficially incorporated into each of the computing elements of network 100 , however, as depicted in FIG. 1, a network management service need not be fully disposed in every client or server in order for network 100 to benefit from the present invention.
- client applications 120 and 122 are intended to represent any number of a wide variety of applications, in particular, management applications such as Client Manager and Work Group Manager, available from Intel Corp., of Santa Clara, Calif. As depicted, client applications 120 and 122 rely on operating systems 130 and 132 , respectively, to interface with network transport services 140 and 142 and, ultimately, with network medium 120 . In one embodiment, as will be discussed in greater detail below, client application 120 may alternatively interface with network medium 120 via network management service 150 and network transport service 140 as shown.
- management applications such as Client Manager and Work Group Manager, available from Intel Corp., of Santa Clara, Calif.
- client applications 120 and 122 rely on operating systems 130 and 132 , respectively, to interface with network transport services 140 and 142 and, ultimately, with network medium 120 .
- client application 120 may alternatively interface with network medium 120 via network management service 150 and network transport service 140 as shown.
- operating systems 130 and 132 are intended to represent a wide variety of operating systems common to a corresponding variety of computing platforms. Examples of such operating systems include the UNIX operating system, WindowsTM based operating systems (e.g., WindowsTM 3.1, WindowsTM 95, WindowsTM NT and WindowsTM CE), the MacintoshTM and NeXTStepTM operating systems, and the like.
- WindowsTM based operating systems e.g., WindowsTM 3.1, WindowsTM 95, WindowsTM NT and WindowsTM CE
- MacintoshTM and NeXTStepTM operating systems e.g., WindowsTM 3.1, WindowsTM 95, WindowsTM NT and WindowsTM CE
- Network transport services 140 and 142 perform their conventional function of physically sending and receiving information over the network medium, as known in the art.
- the form of the information exchange is through a message packet.
- the message packet is a datagram, the structure of which will be discussed more fully below in FIG. 3.
- network transport services 140 and 142 are intended to represent a broad category of transport services known in the art. Examples of such network transport services include Intemetwork Packet eXchange (IPX), User Datagram Protocol/internet Protocol (UDPIIP), NetBEUI, NetBIOS over IP, NetBIOS over IPX, and the like.
- IPX Intemetwork Packet eXchange
- UDPIIP User Datagram Protocol/internet Protocol
- NetBEUI NetBIOS over IP
- NetBIOS NetBIOS over IPX
- network 100 is also comprised of servers 106 and 108 , which include server applications 160 and 162 , server operating system 170 and 172 , network transport services 180 and 182 , and network management services 190 and 192 incorporating the teachings of the present invention, respectively.
- servers 106 and 108 which include server applications 160 and 162 , server operating system 170 and 172 , network transport services 180 and 182 , and network management services 190 and 192 incorporating the teachings of the present invention, respectively.
- not all of the plurality of servers 106 and 108 need to have its own network management service. So long as a network management service is disposed within the network, the clients/servers of the network may benefit from some measure of the functionality that network management service provides.
- servers 106 and 108 include server applications 160 and 162 , operating systems 170 and 172 , and network transport services 180 and 182 each of which are intended to represent a broad category of applications, operating systems and network transport services known in the art. Consequently, they will not be discussed further.
- network management services e.g., network management services 150 , 190 and 192
- network management services 150 , 190 and 192 comprise a plurality of services which enable, for example, network management applications to interact with network elements independent of the operating systems resident on those network elements.
- network management service 200 may be beneficially incorporated into network 100 as, for example, network management service 150 , 190 and/or 192 .
- network management service 200 is shown comprising agent discovery service 202 , simple file transfer service 204 and remote execution service 206 .
- network management service 200 may also include communication service 208 depicted in FIG. 2 with dashed lines.
- network management service 200 is an enabling technology. That is to say, network management service 200 enables a client to discover remote agents, communicate with remote agents, transfer files to and from remote computers, and remotely initiate local execution of applications on the client, independent of the particular type of operating system(s) operating on the client computer. Invocation of the services offered by the network management service may be accomplished in any number of approaches known in the art, e.g., application program interface(s) (API's).
- API's application program interface(s)
- network management service 200 includes agent discovery service 202 .
- Agent discovery service 202 is the subject of the parent U.S. Patent Application, identified above.
- agent discovery service 202 enables network management service 200 to discover and register remote agents, and allows local agents to be discovered and remotely registered.
- the remote agents may be agents residing on remote clients or remote servers.
- agent discovery service 202 initiates the discovery process by broadcasting a packet (or datagram) of information on network 100 via network medium 120 .
- the packet of information is referred to as a PING packet, i.e., the packet of information sent by agent discovery service 202 searching for remote agents.
- discovery service of like kind which may or may not be part of a network management agent, responds to the received PING packet with a similar packet of information, i.e., a PONG packet via network 100 .
- lists of remote agents discovered are maintained.
- local applications instruct network management service 200 to discover remote agents, while in an alternate embodiment, network management service 200 autonomously updates the discovered list.
- agent discovery service 202 of network management service 200 responds, in accordance with user preferences for the network element in which it resides, to PING packets of remote agents.
- Another element of the network management service 200 of FIG. 2 is the simple file transfer service 204 .
- files may be “pushed” (e.g., from client 102 to server 106 ) or “pulled” (e.g., from server 106 to client 102 ) using a pair of simple file transfer service 204 disposed in a client and a server, respectively.
- simple file transfer service 204 unilaterally identifies and retrieves a file from a remote agent.
- a listing e.g., a directory
- the files available on the remote agent may be obtained by simple file transfer service 204 , in addition to the files themselves.
- simple file transfer service 204 will depict a directory of available files in a UNICODE format, requiring local agents to interpret the UNICODE listing and translate the UNICODE directory into a local format.
- communication for the simple file transfer service 204 is performed on dynamic IPX sockets and UDP/IP ports, while in alternate embodiments, a fixed socket/port may be assigned.
- simple file transfer service 204 uses a request/reply datagram sequence to accomplish the file transfer.
- simple file transfer service 204 requests include cancel, close, execute, list, create, read, shutdown and write operations.
- each request will be responded to with a reply.
- a create request will be responded to with a create reply.
- a create request is used to obtain a file handle for a new file to be created on the server.
- a cancel request is used to abort or cancel any operation in process.
- the cancel request does not elicit a reply.
- the close request is used to prematurely close a write request.
- the list operation is used to obtain a directory listing of files.
- the directory listing may contain a single file name or it may contain an iterative list of file names satisfying wild-card characters.
- the read request/reply datagrams contain a status field which indicates to the simple file transfer service when the end of file (EOF) is reached.
- the write request is used to “push” a file from the client to the server.
- the write request/reply datagrams contain a status field which indicates to the simple file transfer service that the end of file (EOF) has been reached.
- the shutdown request is used to log off, power off, reboot, “kill” or shutdown a remote server.
- the shutdown request contains an attribute field which specifies which of the above operations are to be performed with the issuance of the shutdown request.
- the server will reply with a failed shutdown request if there are other clients using it.
- the client forces the server to terminate all clients (with ample notification to the clients that the server is going down) and proceeds with the request.
- the execute request is used to remotely initiate local execution of a specified process.
- the request/reply sequences take the form of a communication packet, or datagram.
- FIG. 3 One example of a file transfer datagram is depicted in FIG. 3.
- file transfer datagram 300 is depicted comprising header 302 , version 304 , packet type 306 , dgram_size 308 , client_data 310 , server_data 312 , sequence field 314 , status 316 , file handle 318 , I_parm 13 1 320 , I_parm — 2 322 , data length indicator 324 and data 326 .
- header 302 includes a header identifying the transport service utilized.
- header 302 is the base transport layer header.
- Version field 304 indicates the file transfer protocol version. That is, the version of the datagram is compared to the version of the application, wherein the datagram packet is converted to the appropriate version, if necessary.
- the packet type field 306 of file transfer datagram 300 indicates the request or reply type for the current packet. For example, packet type 306 will indicate whether the current request is an open, close, cancel, etc.
- the dgram_size field 308 specifies the maximum packet size that can be accepted by the sender of the datagram (i.e., datagram 300 ). Consequently, any packet returned to the sender should not exceed this size.
- dgram_size 608 contains the smaller of either the maximum datagram size of the sender, or the maximum datagram size of the base level transport layer employed.
- Client_data field 310 indicates identification data from the client side.
- the server application places the contents of client_data field 310 of a request packet into the client_data field 310 for the corresponding reply packet.
- the data of the client_data field 310 may be used, for example, to identify some instance data associated with the current packet session. Similar to client_data field 310 , is server_data field 312 which contains information with regard to the server. Sequence field 314 is used to identify repeated request and reply packets.
- status field 316 indicates the success or failure of a request. In one embodiment, for example, a zero indicates success, while a non-zero value represents some sort of error.
- File handle 318 may be found in all replies and in all requests except for an open or a create request (wherein the reply will include the file handle).
- I_parm — 1 320 and I_parm — 2 322 are optional fields in the datagram and may, in one embodiment of the present invention, be used for creation data and file size in the open reply.
- Data length 324 indicates the byte-length of the data field. Data 326 , if present contains dynamic length data.
- data field 326 depend on the packet type. For example, for a create packet type, data field 326 may contain the file specification, whereas for a read packet type, data field 326 may contain the read data.
- all file transfer requests and replies use the same packet format. Not all fields are used by all requests or replies. In one embodiment, for example, when a field is not used in a particular request or reply, it is set to zero.
- FIG. 4 depicts a series of method steps wherein a file is pushed from a client to a server (e.g., client 102 , server 106 ) through network management services.
- the process begins with a create request sent by client 102 to server 106 using file transfer service of the respective network management service or equivalent, step 402 , wherein a temporary file is created on server 106 to store the pushed data.
- a temporary file handle is created by simple file transfer service 204 of the server by which the temporary upload file is subsequently referred.
- a file handle is a [unique] ‘token’ (number) that the system uses in referring to an open file” ( Computer Dictionary, Second Edition , published by Microsoft Press, page 165 ( ⁇ 1994)). That is to say, the file handle binds the upload file to a particular network address, wherein the network address includes the client application's dynamic socket/port. It should be appreciated, then, that there may be only one file handle per network address active at one particular time (unless multiple network transport services-sockets/ports are available, i.e., a multiprocessing multi-communication channel system).
- the temporary upload file is created by simple file transfer service 204 of network management service 200 of the server in a non-volatile storage device on the server.
- simple file transfer service 204 of network management service 200 of the server may allocate space in a volatile storage device for the temporary upload file.
- the client opens the file which is to be uploaded and a write file transfer datagram is issued in step 404 , wherein data is written from the file resident on client 102 to the temporary upload file created on server 106 .
- the amount of data pushed with each write file transfer datagram is dependent upon the size of data field 326 of datagram 300 .
- a determination is made at client as to whether the end of the file to be pushed has been reached. If so, a close file transfer datagram is issued and the temporary upload file on the server is closed, step 408 .
- step 406 If it is determined in step 406 that the end of the file to be pushed has not yet been reached, however, the process loops back to step 404 , wherein another write file transfer datagram is issued and the next block of data is written from client 102 to the temporary upload file on server 106 .
- the looping process (e.g., steps 404 and 406 ) continues until all of the data to be pushed has been written to the temporary upload file on server 106 , whereafter a close file transfer datagram is issued and the temporary upload file is closed, step 408 .
- server 106 renames the temporary upload file with the filename designated in the create request and any other file with the same name is removed, step 410 . If, however, a cancel request is issued prior to a close request, any previous file with the same name is preserved.
- files may be pulled from a server to a client (e.g., from server 108 to client 104 ) employing simple file transfer service 204 of network management service 200 or equivalent, as depicted in FIG. 5.
- FIG. 5 depicts the method steps by which the simple file transfer service 204 of network management service 200 of a client “pulls” a file from server 108 to client 104 .
- the method begins wherein simple file transfer service 204 of the client issues an open file transfer datagram, step 502 , and in response simple file transfer service 204 of the server opens the source file located on the server (e.g., server 108 ).
- client 104 creates a temporary download file into which the data from the remote file will be read. Similar to the push process, client 104 creates a temporary download file, referenced via a file handle.
- step 502 a read file transfer datagram is issued, wherein a block of data is read from the remote file into the temporary download file, step 504 .
- the amount of data pulled in a single read file transfer datagram is limited only by the size allocated to data field 326 of file transfer datagram 300 .
- step 506 simple file transfer service 204 of the client determines whether the end of the remote file has been reached. If not, the method loops back to step 504 , and the next block of data is pulled. If, however, the entire file has been pulled, simple file transfer service 204 of the client issues a close file transfer datagram to close the remote file, step 508 .
- the file handle of the temporary download file is made permanent. If, however, a cancel request is issued prior to a close request, the remote file is closed and the temporary download file is removed (i.e., enabling client to reallocate memory allocated to the temporary download file).
- network management service 200 of FIG. 2 includes remote execution service 206 .
- Remote execution service 206 of network management service 200 is used to initiate remote execution of an application, as well as remotely initiate local execution of an application.
- remote execution services 206 disposed on a client and a server cooperate to facilitate a server to respond to a client (or vice versa, or among clients, or among servers) to initiate execution of a file.
- a communication protocol of datagrams is employed by remote execution service 206 to facilitate remote initiation of local execution of an application, or initiate remote execution of an application.
- FIG. 6 One example of a datagram employed by remote execution service 206 is illustrated in FIG. 6.
- FIG. 6 illustrates an example of a datagram communication packet suitable for use by remote execution service 206 .
- remote execution datagram 600 is shown comprising header 602 , version 604 , packet_type 606 , dgram_size 608 , client_data 610 , server_data 612 , sequence 614 , status 616 , data_length 618 and data field 620 .
- data field 620 wherein the executable filename and any command-line arguments (i.e., an argument list) are contained.
- each of the arguments within data_field 620 are zero-terminated, and the argument list ends after an empty string (also zero-terminated).
- an example of the information contained in data_field 620 is depicted in example (1) below.
- data contained within data_field 620 may be terminated with a carriage-return/line-feed, terminated by a null-string (0), as depicted below in example (2).
- the remote execution service 206 upon receipt of remote execution datagram 600 checks for the presence of the executable file described in data_field 620 and, if present, causes the file to be executed.
- Authorization services are incorporated into and are the responsibility of remote execution service 206 .
- the authorization protocol will vary depending on the operating environment. In one embodiment, the execution of the applications will not begin until the network management service 200 has been shutdown. In another embodiment, network management service 200 may cause itself to be transferred to and executed on a remote computer.
- header field 602 contains information related to the type of transport employed.
- header field 602 contains the transport layer header.
- Version field 604 contains the file transfer protocol version.
- the packet_type field 606 of remote execution datagram 600 contains the request or reply type for this packet.
- the dgram_size field 608 contains information as to the maximum packet size that can be accepted by the sender of remote execution datagram 600 . Consequently, any packet returned to the sender of remote execution datagram 600 (i.e., a reply) should not exceed this size.
- dgram_size 608 contains the smaller of either the maximum datagram size of the sender, or the maximum datagram size of the base level transport layer employed.
- remote execution datagram 600 includes client_data field 610 .
- client_data field 610 is a four-byte field containing data from the client side.
- the remote execution service places the contents of client_data field 610 of a request packet into the client_data field 610 for the corresponding reply packet.
- the data of the client_data field 610 may be used, for example, to identify some instance data associated with the current packet session.
- server_data field 612 Similar to client_data field 610 , is server_data field 612 which contains information with regard to the server.
- Sequence field 614 is used to identify repeated request and reply packets.
- Status field 616 of remote execution datagram 600 indicates the success or failure of a request.
- the data_length field 618 indicates to the recipient of remote execution datagram 600 the length of the data field.
- network management service 200 may beneficially include communication service 208 .
- Network management service 190 employs communication service 208 to “translate” the information to/from the transport layer service.
- communication service 208 allows network management service 200 to function regardless of the underlying network transport protocol by abstracting the differences of the supported transport protocols (TCP/IP, IPX/SPX, etc.) into a set of common-denominator functions, and by establishing well-known port or socket addresses for communication service communications. For example, in one embodiment, communication service 208 establishes “listening addresses” for all of the supported transport protocols (identified above) and uses the agent discovery service 202 discovery protocol to make these listening addresses available to other instances of communication service 208 located throughout the network.
- the network management service 200 of the server may then proceed to perform communications over the network, via communication service 208 without regard to any particular transport protocol supported by a particular client.
- communication service 208 on a server e.g., server 108
- network management service 200 may be implemented in a number of alternate embodiments.
- network management service 200 may take the form of a plurality of software instructions stored in a machine readable format and executed by a computer.
- network management service 200 may be embedded in an Application Specific Integrated Circuit within a computer.
- FIGS. 7 - 9 are provided as an example, and not limitation, of an example application of the innovative features of the network management service 200 .
- FIG. 7 a flow chart illustrating one example of a method for configuring an unconfigured client computer.
- FIGS. 7 - 9 will be described in the context of the elements of network 100 .
- a network management application e.g., application 160
- a server e.g., server 108
- network management service 200 detects an unconfigured client computer (e.g., client 105 ) and, in accordance with the innovative features enabled by the network management service (e.g., network management service 192 ), configures the client for operation within network 100 .
- FIG. 8 illustrates a block diagram of the high-level architecture of unconfigured client computer 800 .
- the use of the term “unconfigured” may be a bit of a misnomer insofar as there is a rudimentary level of functionality that is assumed when a computer is shipped from a computer manufacturer. As depicted in the example architecture of FIG.
- “unconfigured” client computer 800 includes hardware 802 , hardware configuration data 804 , basic input/output system (BIOS) 806 , BIOS configuration data 808 and a rudimentary set of network boot instructions stored in non-volatile memory (e.g., a boot PROM) 810 .
- BIOS basic input/output system
- BIOS configuration data 808 e.g., BIOS configuration data 808
- a rudimentary set of network boot instructions stored in non-volatile memory (e.g., a boot PROM) 810 .
- client computer 800 is client 105 .
- Hardware 802 includes at least one processor, a memory subsystem, an input/output device, and a communications subsystem. In one embodiment, hardware 802 may also include such items as a mass storage device, a display, peripherals, and the like.
- Hardware configuration data 804 includes information necessary to interface elements of hardware 802 .
- BIOS 806 provides basic input/output services. In one embodiment, BIOS 806 includes desktop management interface (DMI) services including special network manageability services, e.g., in accordance with Desktop Management BIOS Specification , version 2.0, dated Feb. 23, 1996.
- BIOS configuration data 808 includes configuration data for the hardware/I/O system.
- Boot instructions 810 provide a set of instructions executed at start-up which provide a nominal level of functionality to the computer.
- Boot instructions 810 are stored in a non-volatile memory such as a programmable read-only memory (PROM), and initiate execution of a rudimentary “operating system” (OS).
- PROM programmable read-only memory
- OS operating system
- the rudimentary “OS” provides the computer with a rudimentary level of memory management, communication and file transfer capability to computer 800 .
- the method of configuring an unconfigured client begins with step 702 , wherein server 108 determines that client 105 is not executing an operating system.
- the means by which server 108 determines that client 105 does not have an operating system depends upon the configuration of client 105 .
- the agent discovery service broadcasts PING datagrams looking for servers that can fully configure client 105 .
- a network management service resident on server 108 broadcasts PING datagrams searching for unconfigured network clients, and client 105 responds to the PING datagram with an indication identifying client 105 as an unconfigured network client.
- management application 160 next determines whether client 105 is populated with a network management service.
- agent discovery service 202 of network management service 192 issues a PING datagram on network medium 120 via network transport service 180 , and awaits a reply (i.e., a PONG datagram).
- network management service 192 downloads a copy of network management service to client 105 via the rudimentary OS, in accordance with, for example, the method steps illustrated in FIG. 5, step 708 . Once the download of a network management service has been completed in step 708 , its execution is initiated, step 710 .
- management application 160 determines the operating system requirements for client 105 , step 710 . In one embodiment, for example, this determination is made by ascertaining the type of processor resident in client 105 . Having determined the operating system requirements of client 105 , management application 160 , via simple file transfer service 204 of network management service 192 downloads an appropriate operating system from server 106 to client 105 , step 712 .
- remote execution service 206 of network management service 192 of server 106 and the remote execution service of the newly downloaded network management service on client 105 are employed by management application 160 to remotely initiate execution of the newly downloaded operating system on the client, step 714 .
- the remote execution service of network management service 192 of server 106 issues a remote execution datagram to the remote execution service of the downloaded network management service resident on client 105 , identifying the AUTOEXEC.BAT file, with appropriate command line entries, thereby remotely initiating local execution of the operating system on client 105 .
- server 106 may utilize network management service 192 and the newly downloaded network management service on client 105 to download additional applications or agents to client 105 , step 716 .
- FIG. 9 illustrates a block diagram of the method steps depicted in FIG. 7 from a network perspective.
- FIG. 9 illustrates server 106 downloading a network management service to client 105 and subsequently utilizing the downloaded network management service to facilitate a network management agent to configure client 105 with an operating system and other applications/agents.
- FIG. 10 illustrates the method steps wherein a server configured with network management service 200 facilitates remote initiation (i.e., “power up”) of a network management service-enabled client computer that is in a power-off or “sleep” state (e.g., a low power state) to perform network management operations, and subsequently returns the client to its power state prior to the network management session.
- a server configured with network management service 200 facilitates remote initiation (i.e., “power up”) of a network management service-enabled client computer that is in a power-off or “sleep” state (e.g., a low power state) to perform network management operations, and subsequently returns the client to its power state prior to the network management session.
- a power-off or “sleep” state e.g., a low power state
- the method begins, step 1002 , with a network management agent identifying a client (e.g., client 102 ) that is the target of the management operation (i.e., the remote power-up operation) of the server (e.g., server 108 ).
- a network management agent identifying a client (e.g., client 102 ) that is the target of the management operation (i.e., the remote power-up operation) of the server (e.g., server 108 ).
- the target client may be identified.
- network management agent 162 may make a log entry of the fact that the identified client needs defined network maintenance. Subsequently, when network management agent 162 “senses” that client 102 has been powered-off, network management agent 162 waits for a convenient maintenance period to perform such maintenance (e.g., after normal working hours).
- network management service 192 of the server is called upon to determine if client 102 is configured with a network management service.
- network management service 192 sends a PING datagram to discover if client 102 is configured with a network management service, in accordance with the teachings above. If network management service 192 determines that client 102 is not populated with a network management service, network management service 192 populates client 102 with a network management service.
- network management service 192 of the server pushes (i.e., downloads) a network management service from server 108 to client 102 , step 1006 , and remotely initiates local execution of the pushed network management service, step 1008 , in accordance with the teachings of FIG. 5.
- step 1004 If, in step 1004 , it is determined that client 102 is populated with a network management service (e.g., network management service 150 ), network management agent 162 , through network management service 150 , retrieves the last power state of client 102 .
- network management agent 162 determines if the power state of client 102 is satisfactory to perform the desired operation, step 1012 . If not, network management agent 162 issues a power state command through network management service 192 to network management service 150 to place client 102 in the necessary power state, step 1014 .
- network management agent 162 Having issued the power state command in step 1014 , or if in step 1012 it is determined that client 102 is in the proper power state to perform the desired operation, network management agent 162 performs the desired management function in step 1016 .
- network management service determines that client is in a powered-down state, steps 1010 , 1012 , and issues the necessary power state command to enable at least a subset of the system components comprising client 102 (e.g., the computer, but not the monitor, printer, scanner, etc.), step 1014 .
- client 102 Once client 102 has booted up, albeit running an old version of the OS, network management service initiates an OS upgrade, step 1016 .
- network management agent 162 issues a power state command to network management service 150 through network management service 192 to place client 102 in the power state prior to the network management session, step 1018 .
- the innovative network management service provides a heightened level of network manageability and interoperability.
- the network management service is platform independent; that is, it will work in a myriad of computer processing environments.
- the introduction of a network management service 200 into a network allows a network manager in a central location to not only monitor network statistics, but to interrogate and remotely manipulate remote clients.
- network management service 200 is an enabling technology providing a new generation of network management applications with interoperable access to the most fundamental processes of the computer system.
- FIG. 11 depicts an example method for dynamically managing network directory services utilizing the innovative network management service 200 , in accordance with one embodiment of the present invention.
- the method begins with block 1102 , wherein a directory service application incorporating innovative network management service 200 is established. That is, the innovative directory services application, to be described more fully below, relies on network management service 200 and a directory access protocol such as, for example, the lightweight directory access protocol (LDAP), to provide a user of the directory service with up-to-date information gathered from any of a number of communicatively coupled data sources.
- LDAP lightweight directory access protocol
- the innovative directory service enables a user to populate one or more records of the directory service with one or more network management service functions (e.g., discovery service) in lieu of static data, block 1104 .
- network management service functions e.g., discovery service
- block 1106 when a field of the innovative directory service populated with a network management service 200 is accessed, the network management service 200 selectively invokes one or more network management service agents, e.g., discovery service 202 , execution service 206 , communication service 208 , and the like to access an identified remote data source and obtain the requested information.
- network management service 200 utilizing a network management service 200 function to populate a directory service record, in lieu of actual data, enables the directory service to access remote sources of such data to ensure the latest available data populates the directory service.
- a directory service utilizing the innovative network management service 200 is presented with reference to FIG. 12.
- directory service 1200 is an X.500 compliant directory service, although directory services adhering to other service standards may also be used.
- directory service 1200 is a database of employee information suitable for use, for example, within a department of a multi-site corporation. Those skilled in the art will appreciate that to maintain such a dynamic database with static information would prove costly, as it must be updated as people change departments, switch offices, etc.
- directory service 1200 incorporating the teachings of the present invention enables a user to populate records of the directory with network management service 200 functions. As shown, the certain fields of information associated with employee no. 003241, 1202 is populated with a discovery function call of network management service 200 , while other fields are populated with static information.
- directory service 1200 fields which contain volatile information, or information that is likely to change frequently are better suited to be populated with network management service 200 functions.
- the information for the office location of employee 1202 is dynamically accessed from a remote data source file “LOC.DB” 1204 .
- LOC.DB is a employee location database maintained by a facilities department of the corporation.
- field 1204 depicts “DISC LOC.DB”, which denotes that the information associated with field 1204 is dynamically updated, on command, utilizing at least the discovery service 202 of the network management service 200 .
- the discovery agent when invoked, the discovery agent “discovers” the LOC.DB data resource and registers its location within network management service 200 .
- network management service 200 operating within the dynamically managed directory service 1200 utilizes a directory access protocol or, alternatively, another function within network management service 200 (e.g., remote execution agent, etc.), to access and populate the field with the requested information associated with the corresponding employee number 1202 from the remote information source (i.e., LOC.DB).
- Alternate records of directory service 1200 are populated with static information.
- information which is unlikely to change very frequently may well be populated with static information.
- One example, again associated with employee 1202 is the admin support field, which is populated with the name “Peggy Reynolds” 1206 .
- network management service 200 may be beneficially employed to perform a number of network functions heretofore unavailable in prior art network management tools.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer And Data Communications (AREA)
Abstract
A network management service for facilitating the management of networked devices by network management applications (or agents) is described. In a first embodiment, the network management service for facilitating the management of networked devices by network management applications comprises an agent discovery service for discovering and registering remote management agents, and a file transfer service operative to send information to and receive information from remote systems.
Description
- The present application is a continuation-in-part of application number 08/624,773 entitled “Method and Apparatus for Discovering Server Applications in a Network of Computer Systems” by Allan B. Butt and Michael D. Day II, and commonly assigned to the assignee of the present invention.
- 1. Field of the Invention
- The present invention relates to the field of networked systems and, in particular, to a method and apparatus for dynamically managing networked directory services.
- 2. Background Information
- Networking of computing elements and, in particular, the implementation of client/server networks, wherein the client is the initiating node and the server is the responding node (i.e., not necessarily referring to a file “server” or an application “server”), are known. Examples of these networks include local area networks (LANs), wide area networks (WANs), global networks (Internet), and the networking of telecommunications devices (i.e., cellular networks, PCS networks, wireline telephony networks), and the like. Many of these networks comprise a variety of client computers having different processor architectures and Operating Systems (OS) using Transmission Control Protocol/Internet Protocol (TCP/IP), Internetwork Packet exchange (IPX), and User Datagram Protocol/Internet Protocol (UDP/IP), or other suitable networking protocols (cumulatively referred to as the Internet communication suite) to produce a seemingly transparent network.
- Thus, despite this seemingly transparent operation, the reality is that these heterogeneous computer networks can be very cumbersome to manage and, consequently, expensive to maintain. While the standards-based communication protocols of the Internet communication suite (e.g., TCP/IP, UDP/IP, IPX) have facilitated the promulgation of such heterogeneous networks, those who manage these networks must duplicate a number of resources to account for a variety of processor architectures and corresponding OS disposed throughout the network. That is to say that the file management, processor communications and the interface to the network communication suite rely on the OS as the user interface to provide a functional computer system (at least from the perspective of the end-user). Accordingly, in most instances where the OS “hangs” (i.e., seemingly “freezes” in an unrecoverable state), the user is, in essence, locked out from the operational state of the computer and the only recourse is to restart the OS (e.g., by rebooting the computer).
- Producers and consumers of computer systems have begun to quantify the costs associated with the purchase and maintenance of computer systems and, to some, the results are surprising. One generalization drawn from such study is that the initial cost of purchasing a computer system and software (regardless of size and complexity) is quite small compared to the cost of maintaining such systems. That is to say, the cost of system management, lost productivity due to computer/network downtime and the like are significantly higher than the initial cost of purchasing the hardware and software elements comprising the network.
- It is not surprising then, that consumers of large networks of computing devices are placing more pressure on the computing industry to drive down the cost associated with the management and maintenance associated with computer systems, i.e., to reduce the total cost of ownership (TCO) associated with the purchase and maintenance of the computer systems. Despite their best efforts, however, prior art network management solutions (sometimes referred to as network management tools) to these problems have not had a significant impact on reducing the total cost of ownership.
- While the introduction of these tools have improved the general state of network management, fundamental limitations in their effectiveness remain. An example of one such inherent limitation in prior art management tools is the fact that they rely on an operational operating system (OS) at the client computer. That is to say, the prior art network management tools are unable to interface with a “frozen” client computer, much less perform remote diagnostics and maintenance on a client computer in such a state. Rather, many of the prior art management tools created by third party developers merely generate usage statistics, or information readily available from networked computers (or the individual processors of the networked computers), i.e., they merely collect and provide commonly available information via a graphical user interface (GUI).
- To further illustrate this limitation with an example, if a user calls a corporate help desk complaining of computer problems, and the network manager determines that the user's OS is “frozen”, there is little the network manager can do remotely via the network management software. Consequently, the network manager is often relegated to the rather impotent suggestion of having the user “reboot” the computer and, consequently, losing all of the data stored in volatile memory (i.e., not saved on the hard drive).
- Thus a need exists for a method and apparatus for facilitating the management of networked devices, unencumbered by the deficiencies and limitations commonly associated with the prior art.
- In accordance with the teachings of the present invention, a network management service for facilitating the management of networked devices by network management applications (a.k.a., agents) is described. The network management service comprises an agent discovery service for discovering and registering remote management agents, and a file transfer service operative to send information to and receive information from remote systems.
- The present invention will be described by way of exemplary embodiments, but not limitations, illustrated in the accompanying drawings in which like references denote similar elements, and in which:
- FIG. 1 is a block diagram illustrating an example network of computer systems incorporated with the teachings of the present invention;
- FIG. 2 is a block diagram of a network management service incorporated with the teachings of the present invention;
- FIG. 3 is an illustration of a simple file transfer datagram used to communicate between network management services;
- FIG. 4 is a flow chart depicting the method steps for pushing a file from a client to a server utilizing the network management service of FIG. 2;
- FIG. 5 is a flow chart depicting the method steps for pulling a file from a server to a client utilizing the network management service of FIG. 2;
- FIG. 6 is an illustration of a remote execution datagram used to communicate between network management services;
- FIG. 7 is a flow chart depicting the method steps of one example of remotely configuring an unconfigured client utilizing a network management service, in accordance with the teachings of the present invention;
- FIG. 8 is a block diagram illustrating an example of an unconfigured client computer;
- FIG. 9 is a block diagram depicting the method steps of FIG. 7 from a high-level network architecture view;
- FIG. 10 is a flow chart illustrating the method steps for enabling remote power management using the network management service of FIG. 2, in accordance with the teachings of the present invention;
- FIG. 11 illustrates a flow chart for an example method of dynamically managing networked directory services, in accordance with one embodiment of the present invention; and
- FIG. 12 graphically illustrates an example directory service which is dynamically managed in accordance with the teachings of the present invention, in accordance with one embodiment of the present invention.
- In the following description, for purposes of explanation, specific numbers, materials and configurations are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without the specific details. In other instances, well known features are omitted or simplified in order not to obscure the present invention. Furthermore, for ease of understanding, certain method steps are delineated as separate blocks, however, those skilled in the art will appreciate that such separately delineated blocks should not be construed as necessarily conferring an order dependency in their performance.
- Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrase “in one embodiment” appearing in various places throughout the specification are not necessarily all referring to the same embodiment.
- Referring now to FIG. 1, a block diagram of an example network of computer systems incorporating the teachings of the present invention is depicted. In one embodiment, for example,
network 100 is comprised of a plurality of computing elements, at least a subset of which include the teachings of the present invention. In particular, at least a subset of the computingelements comprising network 100 are disposed with an innovative network management services, incorporated with the teachings of the present invention, enabling an improved level of network manageability and interoperability independent of the myriad of operating systems that may reside withinnetwork 100. In addition to the foregoing, those skilled in the art will appreciate that the innovative network management services of the present invention may also be used to dynamically manage networked directory services. That is, as will be described more fully below, the network management service incorporating the teachings of the present invention enables a network management application (also commonly referred to as network management agent, or NMA), for example, to interrogate and manipulate network resources on behalf of managed directory services utilizing the teachings of the present invention. - As depicted in FIG. 1,
network 100 is shown comprisingclients servers network medium 120. In one embodiment,clients clients network medium 120 is intended to represent a broad category of networking infrastructure including network cables and their associated switching (routing), repeater, and/or delay elements, suitable for a high speed local area network (LAN), or a slower speed wide area network (WAN), or public network (i.e., Internet) implementations known in the art. Although certain computing elements ofnetwork 100 are labeled asservers clients - In one embodiment of the present invention,
clients network transport services 140 and 142 (sometimes referred to as the transport layer), operatively coupled as depicted. In one embodiment of the present invention,client 102 is shown further comprisingnetwork management service 150 incorporated with the teachings of the present invention. As will be discussed in greater detail below, a network management service (e.g., network management service 150) may be beneficially incorporated into each of the computing elements ofnetwork 100, however, as depicted in FIG. 1, a network management service need not be fully disposed in every client or server in order fornetwork 100 to benefit from the present invention. - Continuing with FIG. 1, as illustrated,
client applications client applications operating systems network transport services network medium 120. In one embodiment, as will be discussed in greater detail below,client application 120 may alternatively interface withnetwork medium 120 vianetwork management service 150 andnetwork transport service 140 as shown. - Similarly,
operating systems -
Network transport services network transport services - In addition to
clients network 100 is also comprised ofservers server applications server operating system 170 and 172,network transport services network management services servers - As illustrated in FIG. 1,
servers server applications operating systems 170 and 172, andnetwork transport services network management services - Turning, then, to FIG. 2, a block diagram depicting one example of a network management service (i.e., network management service200) is shown. In one embodiment of the present invention,
network management service 200 may be beneficially incorporated intonetwork 100 as, for example,network management service network management service 200 is shown comprisingagent discovery service 202, simplefile transfer service 204 andremote execution service 206. In another embodiment of the present invention,network management service 200 may also includecommunication service 208 depicted in FIG. 2 with dashed lines. Each of the respective elements ofnetwork management service 200, and their corresponding communication protocols will be described more fully below. However, before describing these elements in further detail it should be noted thatnetwork management service 200 is an enabling technology. That is to say,network management service 200 enables a client to discover remote agents, communicate with remote agents, transfer files to and from remote computers, and remotely initiate local execution of applications on the client, independent of the particular type of operating system(s) operating on the client computer. Invocation of the services offered by the network management service may be accomplished in any number of approaches known in the art, e.g., application program interface(s) (API's). - Returning to the description of the elements of FIG. 2,
network management service 200 includesagent discovery service 202.Agent discovery service 202 is the subject of the parent U.S. Patent Application, identified above. In brief,agent discovery service 202 enablesnetwork management service 200 to discover and register remote agents, and allows local agents to be discovered and remotely registered. The remote agents may be agents residing on remote clients or remote servers. In one embodiment of the present invention,agent discovery service 202 initiates the discovery process by broadcasting a packet (or datagram) of information onnetwork 100 vianetwork medium 120. In the context of this implementation, the packet of information is referred to as a PING packet, i.e., the packet of information sent byagent discovery service 202 searching for remote agents. On behalf of remote agents disposed to discovery, discovery service of like kind, which may or may not be part of a network management agent, responds to the received PING packet with a similar packet of information, i.e., a PONG packet vianetwork 100. - In one embodiment of the present invention, lists of remote agents discovered are maintained. In one embodiment, for example, local applications instruct
network management service 200 to discover remote agents, while in an alternate embodiment,network management service 200 autonomously updates the discovered list. In addition,agent discovery service 202 ofnetwork management service 200 responds, in accordance with user preferences for the network element in which it resides, to PING packets of remote agents. - Another element of the
network management service 200 of FIG. 2 is the simplefile transfer service 204. In one implementation, files may be “pushed” (e.g., fromclient 102 to server 106) or “pulled” (e.g., fromserver 106 to client 102) using a pair of simplefile transfer service 204 disposed in a client and a server, respectively. In an alternate implementation, simplefile transfer service 204 unilaterally identifies and retrieves a file from a remote agent. In one embodiment, a listing (e.g., a directory) of the files available on the remote agent may be obtained by simplefile transfer service 204, in addition to the files themselves. In one embodiment, simplefile transfer service 204 will depict a directory of available files in a UNICODE format, requiring local agents to interpret the UNICODE listing and translate the UNICODE directory into a local format. In one embodiment of the present invention, communication for the simplefile transfer service 204 is performed on dynamic IPX sockets and UDP/IP ports, while in alternate embodiments, a fixed socket/port may be assigned. - The communication protocol employed by simple
file transfer service 204 uses a request/reply datagram sequence to accomplish the file transfer. For example, in one implementation, simplefile transfer service 204 requests include cancel, close, execute, list, create, read, shutdown and write operations. In accordance with this example protocol, each request will be responded to with a reply. For example, a create request will be responded to with a create reply. - In accordance with this example protocol, a create request is used to obtain a file handle for a new file to be created on the server. A cancel request is used to abort or cancel any operation in process. In one embodiment, the cancel request does not elicit a reply. The close request is used to prematurely close a write request. The list operation is used to obtain a directory listing of files. The directory listing may contain a single file name or it may contain an iterative list of file names satisfying wild-card characters. In one embodiment, the read request/reply datagrams contain a status field which indicates to the simple file transfer service when the end of file (EOF) is reached. Similarly, the write request is used to “push” a file from the client to the server. In one embodiment, the write request/reply datagrams contain a status field which indicates to the simple file transfer service that the end of file (EOF) has been reached.
- The shutdown request is used to log off, power off, reboot, “kill” or shutdown a remote server. In particular, the shutdown request contains an attribute field which specifies which of the above operations are to be performed with the issuance of the shutdown request. In one embodiment, the server will reply with a failed shutdown request if there are other clients using it. However, by utilizing the “kill” option of the shutdown request, the client forces the server to terminate all clients (with ample notification to the clients that the server is going down) and proceeds with the request. In accordance with the example protocol, the execute request is used to remotely initiate local execution of a specified process. In one embodiment of the present invention, the request/reply sequences take the form of a communication packet, or datagram. One example of a file transfer datagram is depicted in FIG. 3.
- In accordance with the example file transfer datagram of FIG. 3, file
transfer datagram 300 is depicted comprisingheader 302,version 304,packet type 306,dgram_size 308,client_data 310, server_data 312,sequence field 314,status 316,file handle 318,I_parm 131 320,I_parm —2 322,data length indicator 324 anddata 326. In this examplefile transfer datagram 300,header 302 includes a header identifying the transport service utilized. In one embodiment, for example,header 302 is the base transport layer header.Version field 304 indicates the file transfer protocol version. That is, the version of the datagram is compared to the version of the application, wherein the datagram packet is converted to the appropriate version, if necessary. - The
packet type field 306 offile transfer datagram 300 indicates the request or reply type for the current packet. For example,packet type 306 will indicate whether the current request is an open, close, cancel, etc. Thedgram_size field 308 specifies the maximum packet size that can be accepted by the sender of the datagram (i.e., datagram 300). Consequently, any packet returned to the sender should not exceed this size. In addition, those skilled in the art will appreciate that each of the different transport layers support a different maximum datagram size, which should not be exceeded. Consequently, dgram_size 608 contains the smaller of either the maximum datagram size of the sender, or the maximum datagram size of the base level transport layer employed.Client_data field 310 indicates identification data from the client side. The server application places the contents ofclient_data field 310 of a request packet into theclient_data field 310 for the corresponding reply packet. The data of theclient_data field 310 may be used, for example, to identify some instance data associated with the current packet session. Similar to client_datafield 310, is server_data field 312 which contains information with regard to the server.Sequence field 314 is used to identify repeated request and reply packets. - With continued reference to the file transfer datagram of FIG. 3,
status field 316 indicates the success or failure of a request. In one embodiment, for example, a zero indicates success, while a non-zero value represents some sort of error.File handle 318 may be found in all replies and in all requests except for an open or a create request (wherein the reply will include the file handle).I_parm —1 320 andI_parm —2 322 are optional fields in the datagram and may, in one embodiment of the present invention, be used for creation data and file size in the open reply.Data length 324 indicates the byte-length of the data field.Data 326, if present contains dynamic length data. - The contents of
data field 326 depend on the packet type. For example, for a create packet type,data field 326 may contain the file specification, whereas for a read packet type,data field 326 may contain the read data. In the example implementation, all file transfer requests and replies use the same packet format. Not all fields are used by all requests or replies. In one embodiment, for example, when a field is not used in a particular request or reply, it is set to zero. - In accordance with this example implementation, FIG. 4 depicts a series of method steps wherein a file is pushed from a client to a server (e.g.,
client 102, server 106) through network management services. As depicted in FIG. 4, the process begins with a create request sent byclient 102 toserver 106 using file transfer service of the respective network management service or equivalent,step 402, wherein a temporary file is created onserver 106 to store the pushed data. In one embodiment of the present invention, when the temporary upload file is created, a corresponding temporary file handle is created by simplefile transfer service 204 of the server by which the temporary upload file is subsequently referred. Those skilled in the art will recognize that “a file handle is a [unique] ‘token’ (number) that the system uses in referring to an open file” (Computer Dictionary, Second Edition, published by Microsoft Press, page 165 (©1994)). That is to say, the file handle binds the upload file to a particular network address, wherein the network address includes the client application's dynamic socket/port. It should be appreciated, then, that there may be only one file handle per network address active at one particular time (unless multiple network transport services-sockets/ports are available, i.e., a multiprocessing multi-communication channel system). - In one embodiment, the temporary upload file is created by simple
file transfer service 204 ofnetwork management service 200 of the server in a non-volatile storage device on the server. In an alternate embodiment, simplefile transfer service 204 ofnetwork management service 200 of the server may allocate space in a volatile storage device for the temporary upload file. - Once the temporary upload file has been created, i.e., on the server (e.g., server106), the client opens the file which is to be uploaded and a write file transfer datagram is issued in step 404, wherein data is written from the file resident on
client 102 to the temporary upload file created onserver 106. The amount of data pushed with each write file transfer datagram is dependent upon the size ofdata field 326 ofdatagram 300. Instep 406, a determination is made at client as to whether the end of the file to be pushed has been reached. If so, a close file transfer datagram is issued and the temporary upload file on the server is closed,step 408. If it is determined instep 406 that the end of the file to be pushed has not yet been reached, however, the process loops back to step 404, wherein another write file transfer datagram is issued and the next block of data is written fromclient 102 to the temporary upload file onserver 106. The looping process (e.g., steps 404 and 406) continues until all of the data to be pushed has been written to the temporary upload file onserver 106, whereafter a close file transfer datagram is issued and the temporary upload file is closed,step 408. Once the temporary upload file is closed,step 408,server 106 renames the temporary upload file with the filename designated in the create request and any other file with the same name is removed, step 410. If, however, a cancel request is issued prior to a close request, any previous file with the same name is preserved. - Similarly, in accordance with this example implementation, files may be pulled from a server to a client (e.g., from
server 108 to client 104) employing simplefile transfer service 204 ofnetwork management service 200 or equivalent, as depicted in FIG. 5. As illustrated, FIG. 5 depicts the method steps by which the simplefile transfer service 204 ofnetwork management service 200 of a client “pulls” a file fromserver 108 toclient 104. The method begins wherein simplefile transfer service 204 of the client issues an open file transfer datagram,step 502, and in response simplefile transfer service 204 of the server opens the source file located on the server (e.g., server 108). Concurrently,client 104 creates a temporary download file into which the data from the remote file will be read. Similar to the push process,client 104 creates a temporary download file, referenced via a file handle. - Once the remote file is opened,
step 502, a read file transfer datagram is issued, wherein a block of data is read from the remote file into the temporary download file,step 504. The amount of data pulled in a single read file transfer datagram is limited only by the size allocated todata field 326 offile transfer datagram 300. Subsequently, instep 506, simplefile transfer service 204 of the client determines whether the end of the remote file has been reached. If not, the method loops back to step 504, and the next block of data is pulled. If, however, the entire file has been pulled, simplefile transfer service 204 of the client issues a close file transfer datagram to close the remote file,step 508. Once the close request has been issued, the file handle of the temporary download file is made permanent. If, however, a cancel request is issued prior to a close request, the remote file is closed and the temporary download file is removed (i.e., enabling client to reallocate memory allocated to the temporary download file). - In addition to its
agent discovery service 202 and filetransfer service 204 elements,network management service 200 of FIG. 2 includesremote execution service 206.Remote execution service 206 ofnetwork management service 200 is used to initiate remote execution of an application, as well as remotely initiate local execution of an application. In one embodimentremote execution services 206 disposed on a client and a server cooperate to facilitate a server to respond to a client (or vice versa, or among clients, or among servers) to initiate execution of a file. In one implementation, a communication protocol of datagrams is employed byremote execution service 206 to facilitate remote initiation of local execution of an application, or initiate remote execution of an application. One example of a datagram employed byremote execution service 206 is illustrated in FIG. 6. - FIG. 6 illustrates an example of a datagram communication packet suitable for use by
remote execution service 206. As depicted in FIG. 6,remote execution datagram 600 is shown comprisingheader 602,version 604, packet_type 606, dgram_size 608, client_data 610,server_data 612, sequence 614,status 616, data_length 618 anddata field 620. Of particular interest isdata field 620, wherein the executable filename and any command-line arguments (i.e., an argument list) are contained. In one embodiment of the present invention, each of the arguments withindata_field 620 are zero-terminated, and the argument list ends after an empty string (also zero-terminated). Thus, in accordance with this example implementation, an example of the information contained indata_field 620 is depicted in example (1) below. - PBRUSH.EXE\0BITMAP.BMP\0\0 (1)
- In an alternate embodiment, the data contained within
data_field 620 may be terminated with a carriage-return/line-feed, terminated by a null-string (0), as depicted below in example (2). - PBRUSH.EXE
- BITMAP.BMP (2)
- 0
- The
remote execution service 206, in the role of facilitator, upon receipt ofremote execution datagram 600 checks for the presence of the executable file described indata_field 620 and, if present, causes the file to be executed. Authorization services are incorporated into and are the responsibility ofremote execution service 206. The authorization protocol will vary depending on the operating environment. In one embodiment, the execution of the applications will not begin until thenetwork management service 200 has been shutdown. In another embodiment,network management service 200 may cause itself to be transferred to and executed on a remote computer. - Continuing with the description of
remote execution datagram 600,header field 602 contains information related to the type of transport employed. In one embodiment, for example,header field 602 contains the transport layer header.Version field 604 contains the file transfer protocol version. The packet_type field 606 ofremote execution datagram 600 contains the request or reply type for this packet. The dgram_size field 608 contains information as to the maximum packet size that can be accepted by the sender ofremote execution datagram 600. Consequently, any packet returned to the sender of remote execution datagram 600 (i.e., a reply) should not exceed this size. As was the case forfile transfer datagram 300, dgram_size 608 contains the smaller of either the maximum datagram size of the sender, or the maximum datagram size of the base level transport layer employed. - In addition,
remote execution datagram 600 includes client_data field 610. In one embodiment, for example, client_data field 610 is a four-byte field containing data from the client side. The remote execution service places the contents of client_data field 610 of a request packet into the client_data field 610 for the corresponding reply packet. The data of the client_data field 610 may be used, for example, to identify some instance data associated with the current packet session. Similar to client_data field 610, isserver_data field 612 which contains information with regard to the server. Sequence field 614 is used to identify repeated request and reply packets.Status field 616 ofremote execution datagram 600 indicates the success or failure of a request. The data_length field 618 indicates to the recipient ofremote execution datagram 600 the length of the data field. - In addition to the above described elements of
network management service 200, i.e.,agent discovery service 202, simplefile transfer service 204 andremote execution service 206,network management service 200 may beneficially includecommunication service 208.Network management service 190 employscommunication service 208 to “translate” the information to/from the transport layer service. - In one embodiment,
communication service 208 allowsnetwork management service 200 to function regardless of the underlying network transport protocol by abstracting the differences of the supported transport protocols (TCP/IP, IPX/SPX, etc.) into a set of common-denominator functions, and by establishing well-known port or socket addresses for communication service communications. For example, in one embodiment,communication service 208 establishes “listening addresses” for all of the supported transport protocols (identified above) and uses theagent discovery service 202 discovery protocol to make these listening addresses available to other instances ofcommunication service 208 located throughout the network. Having established listening addresses for each supported transport protocol, and having made those addresses discoverable tocommunication service 208 of remote network management services (i.e., network management service 200), thenetwork management service 200 of the server may then proceed to perform communications over the network, viacommunication service 208 without regard to any particular transport protocol supported by a particular client. In particular,communication service 208 on a server (e.g., server 108) knows which protocol(s) is (are) supported bycommunication service 208 on the client (e.g., client 104), and at which listening addresses those protocols are typically received. - Given the descriptions and example implementations above, one skilled in the art will appreciate that the innovative features of
network management service 200 may be implemented in a number of alternate embodiments. In one embodiment, for example,network management service 200 may take the form of a plurality of software instructions stored in a machine readable format and executed by a computer. In an alternate embodiment,network management service 200 may be embedded in an Application Specific Integrated Circuit within a computer. - Having described the functional elements and protocols employed by
network management service 200 in FIGS. 2-6 above, FIGS. 7-9 are provided as an example, and not limitation, of an example application of the innovative features of thenetwork management service 200. In FIG. 7, a flow chart illustrating one example of a method for configuring an unconfigured client computer. For ease of understanding, the example application of FIGS. 7-9 will be described in the context of the elements ofnetwork 100. Accordingly, in the context of the example implementation, a network management application (e.g., application 160) executing on a server (e.g., server 108) throughnetwork management service 200 detects an unconfigured client computer (e.g., client 105) and, in accordance with the innovative features enabled by the network management service (e.g., network management service 192), configures the client for operation withinnetwork 100. - Before describing the method of FIG. 7 in detail, it may be helpful to review an example high-level architecture of an unconfigured client. FIG. 8 illustrates a block diagram of the high-level architecture of
unconfigured client computer 800. The use of the term “unconfigured” may be a bit of a misnomer insofar as there is a rudimentary level of functionality that is assumed when a computer is shipped from a computer manufacturer. As depicted in the example architecture of FIG. 8, “unconfigured”client computer 800 includeshardware 802,hardware configuration data 804, basic input/output system (BIOS) 806,BIOS configuration data 808 and a rudimentary set of network boot instructions stored in non-volatile memory (e.g., a boot PROM) 810. - In one embodiment,
client computer 800 isclient 105.Hardware 802 includes at least one processor, a memory subsystem, an input/output device, and a communications subsystem. In one embodiment,hardware 802 may also include such items as a mass storage device, a display, peripherals, and the like.Hardware configuration data 804 includes information necessary to interface elements ofhardware 802.BIOS 806 provides basic input/output services. In one embodiment,BIOS 806 includes desktop management interface (DMI) services including special network manageability services, e.g., in accordance with Desktop Management BIOS Specification, version 2.0, dated Feb. 23, 1996.BIOS configuration data 808 includes configuration data for the hardware/I/O system.Boot instructions 810 provide a set of instructions executed at start-up which provide a nominal level of functionality to the computer.Boot instructions 810 are stored in a non-volatile memory such as a programmable read-only memory (PROM), and initiate execution of a rudimentary “operating system” (OS). In one embodiment, the rudimentary “OS” provides the computer with a rudimentary level of memory management, communication and file transfer capability tocomputer 800. - Returning to the example method of FIG. 7, the method of configuring an unconfigured client begins with
step 702, whereinserver 108 determines thatclient 105 is not executing an operating system. The means by whichserver 108 determines thatclient 105 does not have an operating system depends upon the configuration ofclient 105. For example, in one embodiment whereinclient 105 is configured withnetwork management service 200, the agent discovery service broadcasts PING datagrams looking for servers that can fully configureclient 105. In an alternate embodiment, a network management service resident onserver 108 broadcasts PING datagrams searching for unconfigured network clients, andclient 105 responds to the PING datagram with anindication identifying client 105 as an unconfigured network client. - For the illustrated example, once it has been determined by
management application 160 thatclient 105 is not populated with an operating system,management application 160 next determines whetherclient 105 is populated with a network management service. As described above, in one embodiment,agent discovery service 202 ofnetwork management service 192 issues a PING datagram onnetwork medium 120 vianetwork transport service 180, and awaits a reply (i.e., a PONG datagram). If, instep 704, it is determined thatclient 105 does not have a network management service,network management service 192 downloads a copy of network management service toclient 105 via the rudimentary OS, in accordance with, for example, the method steps illustrated in FIG. 5,step 708. Once the download of a network management service has been completed instep 708, its execution is initiated,step 710. - Once a network management service has been downloaded to and executed on
client 105 fromnetwork management service 192 insteps step 704 it was determined thatclient 105 was already enabled with a network management service,management application 160 determines the operating system requirements forclient 105,step 710. In one embodiment, for example, this determination is made by ascertaining the type of processor resident inclient 105. Having determined the operating system requirements ofclient 105,management application 160, via simplefile transfer service 204 ofnetwork management service 192 downloads an appropriate operating system fromserver 106 toclient 105,step 712. Once the download of the appropriate operating system has been completed instep 712,remote execution service 206 ofnetwork management service 192 ofserver 106 and the remote execution service of the newly downloaded network management service onclient 105 are employed bymanagement application 160 to remotely initiate execution of the newly downloaded operating system on the client,step 714. In one embodiment, for example, the remote execution service ofnetwork management service 192 ofserver 106 issues a remote execution datagram to the remote execution service of the downloaded network management service resident onclient 105, identifying the AUTOEXEC.BAT file, with appropriate command line entries, thereby remotely initiating local execution of the operating system onclient 105. - In addition to the download of a new, or an upgrade of an existing operating system,
server 106 may utilizenetwork management service 192 and the newly downloaded network management service onclient 105 to download additional applications or agents toclient 105,step 716. FIG. 9 illustrates a block diagram of the method steps depicted in FIG. 7 from a network perspective. In particular, FIG. 9 illustratesserver 106 downloading a network management service toclient 105 and subsequently utilizing the downloaded network management service to facilitate a network management agent to configureclient 105 with an operating system and other applications/agents. - Another example of the innovative features enabled by the introduction of
network management service 200 into a network is illustrated in FIG. 10. In particular, FIG. 10 illustrates the method steps wherein a server configured withnetwork management service 200 facilitates remote initiation (i.e., “power up”) of a network management service-enabled client computer that is in a power-off or “sleep” state (e.g., a low power state) to perform network management operations, and subsequently returns the client to its power state prior to the network management session. For ease of explanation, the method steps of FIG. 10 will be developed in the context of the network elements of FIG. 1. - The method begins,
step 1002, with a network management agent identifying a client (e.g., client 102) that is the target of the management operation (i.e., the remote power-up operation) of the server (e.g., server 108). There are a number of methods by which the target client may be identified. In one embodiment, for example,network management agent 162 establishes a list of all network clients which are operating under a prior version of a particular operating system, which includesclient 102 for this example. In accordance with the teachings of the present invention, rather than interrupting the computer services to a user ofclient 102 by immediately upgrading the clients operating system,network management agent 162 may make a log entry of the fact that the identified client needs defined network maintenance. Subsequently, whennetwork management agent 162 “senses” thatclient 102 has been powered-off,network management agent 162 waits for a convenient maintenance period to perform such maintenance (e.g., after normal working hours). - Having identified the target client in
step 1002,network management service 192 of the server is called upon to determine ifclient 102 is configured with a network management service. In one embodiment,network management service 192 sends a PING datagram to discover ifclient 102 is configured with a network management service, in accordance with the teachings above. Ifnetwork management service 192 determines thatclient 102 is not populated with a network management service,network management service 192 populatesclient 102 with a network management service. In particular, with client powered-up,network management service 192 of the server pushes (i.e., downloads) a network management service fromserver 108 toclient 102,step 1006, and remotely initiates local execution of the pushed network management service,step 1008, in accordance with the teachings of FIG. 5. - If, in
step 1004, it is determined thatclient 102 is populated with a network management service (e.g., network management service 150),network management agent 162, throughnetwork management service 150, retrieves the last power state ofclient 102. Instep 1010,network management agent 162 determines if the power state ofclient 102 is satisfactory to perform the desired operation,step 1012. If not,network management agent 162 issues a power state command throughnetwork management service 192 tonetwork management service 150 to placeclient 102 in the necessary power state,step 1014. - Having issued the power state command in
step 1014, or if instep 1012 it is determined thatclient 102 is in the proper power state to perform the desired operation,network management agent 162 performs the desired management function instep 1016. In accordance with the present example implementation, network management service determines that client is in a powered-down state, steps 1010, 1012, and issues the necessary power state command to enable at least a subset of the system components comprising client 102 (e.g., the computer, but not the monitor, printer, scanner, etc.),step 1014. Onceclient 102 has booted up, albeit running an old version of the OS, network management service initiates an OS upgrade,step 1016. - Having completed the desired network management operation in
step 1016,network management agent 162 issues a power state command tonetwork management service 150 throughnetwork management service 192 to placeclient 102 in the power state prior to the network management session,step 1018. - Those skilled in the art will appreciate that the innovative network management service provides a heightened level of network manageability and interoperability. As described above, the network management service is platform independent; that is, it will work in a myriad of computer processing environments. Insofar as the
network management service 200 operates independently of any particular computer operating system, the introduction of anetwork management service 200 into a network (e.g., network 100) allows a network manager in a central location to not only monitor network statistics, but to interrogate and remotely manipulate remote clients. As alluded to earlier,network management service 200 is an enabling technology providing a new generation of network management applications with interoperable access to the most fundamental processes of the computer system. - Turning to FIG. 11, another example application utilizing the innovative
network management service 200 is presented. In particular, FIG. 11 depicts an example method for dynamically managing network directory services utilizing the innovativenetwork management service 200, in accordance with one embodiment of the present invention. As shown, the method begins with block 1102, wherein a directory service application incorporating innovativenetwork management service 200 is established. That is, the innovative directory services application, to be described more fully below, relies onnetwork management service 200 and a directory access protocol such as, for example, the lightweight directory access protocol (LDAP), to provide a user of the directory service with up-to-date information gathered from any of a number of communicatively coupled data sources. - In accordance with the teachings of the present invention, the innovative directory service enables a user to populate one or more records of the directory service with one or more network management service functions (e.g., discovery service) in lieu of static data, block1104. In block 1106, when a field of the innovative directory service populated with a
network management service 200 is accessed, thenetwork management service 200 selectively invokes one or more network management service agents, e.g.,discovery service 202,execution service 206,communication service 208, and the like to access an identified remote data source and obtain the requested information. In accordance with the teachings ofnetwork management service 200, above, utilizing anetwork management service 200 function to populate a directory service record, in lieu of actual data, enables the directory service to access remote sources of such data to ensure the latest available data populates the directory service. One example of just such a directory service utilizing the innovativenetwork management service 200 is presented with reference to FIG. 12. - Turning briefly to FIG. 12, a graphical illustration of an
example directory service 1200 utilizingnetwork management service 200 is presented, in accordance with one example embodiment of the present invention. In one embodiment of the present invention,directory service 1200 is an X.500 compliant directory service, although directory services adhering to other service standards may also be used. As shown,directory service 1200 is a database of employee information suitable for use, for example, within a department of a multi-site corporation. Those skilled in the art will appreciate that to maintain such a dynamic database with static information would prove costly, as it must be updated as people change departments, switch offices, etc. However,directory service 1200 incorporating the teachings of the present invention enables a user to populate records of the directory withnetwork management service 200 functions. As shown, the certain fields of information associated with employee no. 003241, 1202 is populated with a discovery function call ofnetwork management service 200, while other fields are populated with static information. - In one embodiment,
directory service 1200 fields which contain volatile information, or information that is likely to change frequently are better suited to be populated withnetwork management service 200 functions. In the illustrated embodiment, for example, the information for the office location of employee 1202 is dynamically accessed from a remote data source file “LOC.DB” 1204. In one embodiment, LOC.DB is a employee location database maintained by a facilities department of the corporation. In accordance with one embodiment of the present invention,field 1204 depicts “DISC LOC.DB”, which denotes that the information associated withfield 1204 is dynamically updated, on command, utilizing at least thediscovery service 202 of thenetwork management service 200. Thus, in accordance with the teachings of the present invention provided above, when invoked, the discovery agent “discovers” the LOC.DB data resource and registers its location withinnetwork management service 200. Whenfield 1204 is accessed,network management service 200 operating within the dynamically manageddirectory service 1200 utilizes a directory access protocol or, alternatively, another function within network management service 200 (e.g., remote execution agent, etc.), to access and populate the field with the requested information associated with the corresponding employee number 1202 from the remote information source (i.e., LOC.DB). - Alternate records of
directory service 1200 are populated with static information. In one embodiment, for example, information which is unlikely to change very frequently may well be populated with static information. One example, again associated with employee 1202, is the admin support field, which is populated with the name “Peggy Reynolds” 1206. - Thus, alternative embodiments and applications for a method and apparatus facilitating the management of networked devices and directory services have been disclosed. While the method and apparatus of the present invention has been described in terms of the above illustrated embodiments, those skilled in the art will recognize that the invention is not limited to the embodiments described. For example, one skilled in the art will appreciate from the above description and example implementations that network
management service 200 may be beneficially employed to perform a number of network functions heretofore unavailable in prior art network management tools. In addition, it has been shown that it is unnecessary for each of the computing elements withinnetwork 100 to incorporatenetwork management service 200, for so long as it is available within the network, it may be downloaded and executed on an as-needed basis. Thus, those skilled in the art will appreciate that the present invention can be practiced with modification and alteration within the spirit and scope of the appended claims. Accordingly, the descriptions thereof are to be regarded as illustrative instead of restrictive on the present invention.
Claims (16)
1. A method comprising:
maintaining a directory service;
populating a field of the directory service with a discovery function call;
dynamically accessing information from a remote source in response to an access to the field.
2. The method of claim 1 further comprising populating the field with the information dynamically accessed from the remote source.
3. The method of claim 1 wherein dynamically accessing information from a remote source in response to an access to the field further comprises:
discovering the remote source with a network management service;
registering the remote source with the network management service; and
retrieving information from the remote source.
4. The method of claim 1 wherein dynamically accessing information from a remote source in response to an access to the field further comprises retrieving information from a remote source previously discovered and registered using a network management service.
5. A machine readable medium having stored thereon sequences of instructions that, when executed by one or more processors, cause one or more electronic devices to:
maintain a directory service;
populate a field of the directory service with a discovery function call;
dynamically access information from a remote source in response to an access to the field.
6. The machine readable medium of claim 5 further comprising sequences of instructions, that when executed by the one or more processors, cause the one or more electronic devices to populate the field with the information dynamically accessed from the remote source.
7. The machine readable medium of claim 6 wherein the sequences of instructions that cause the one or more electronic devices to dynamically access information from a remote source in response to an access to the field further comprise sequences of instructions that, when executed, cause the one or more electronic devices to:
discover the remote source with a network management service;
register the remote source with the network management service; and
retrieve information from the remote source.
8. The machine readable medium of claim 5 wherein the sequences of instructions that cause the one or more electronic devices to dynamically access information from a remote source in response to an access to the field further comprise sequences of instructions that, when executed, cause the one or more electric devices to retrieve information from a remote source previously discovered and registered using a network management service.
9. An apparatus comprising:
means for maintaining a directory service;
means for populating a field of the directory service with a discovery function call;
means for dynamically accessing information from a remote source in response to an access to the field.
10. The apparatus of claim 9 further comprising means for populating the field with the information dynamically accessed from the remote source.
11. The apparatus of claim 9 wherein the means for dynamically accessing information from a remote source in response to an access to the field further comprise:
means for discovering the remote source with a network management service;
means for registering the remote source with the network management service; and
means for retrieving information from the remote source.
12. The apparatus of claim 9 wherein the means for dynamically accessing information from a remote source in response to an access to the field further comprise means for retrieving information from a remote source previously discovered and registered using a network management service.
13. A network comprising:
a first device to maintain a directory service, the directory service having a discovery function call populating at least one field; and
a second device coupled to the first device, the second device to store information associated with the directory service;
wherein access to the field of the directory service causes a discovery function call to be executed to dynamically access the information of the second device.
14. The network of claim 13 wherein the directory service further stores static information in at least one field.
15. The network of claim 13 wherein the discovery function call discovers and registers the second device is response to the field being accessed.
16. The network of claim 13 wherein the discovery service populates the field with information from the second device.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/405,292 US6430596B1 (en) | 1996-03-27 | 1999-09-23 | Managing networked directory services with auto field population |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US62477396A | 1996-03-27 | 1996-03-27 | |
US09/405,292 US6430596B1 (en) | 1996-03-27 | 1999-09-23 | Managing networked directory services with auto field population |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US62477396A Continuation-In-Part | 1996-03-27 | 1996-03-27 |
Publications (2)
Publication Number | Publication Date |
---|---|
US20020046260A1 true US20020046260A1 (en) | 2002-04-18 |
US6430596B1 US6430596B1 (en) | 2002-08-06 |
Family
ID=46276498
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/405,292 Expired - Lifetime US6430596B1 (en) | 1996-03-27 | 1999-09-23 | Managing networked directory services with auto field population |
Country Status (1)
Country | Link |
---|---|
US (1) | US6430596B1 (en) |
Cited By (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020138592A1 (en) * | 2001-01-23 | 2002-09-26 | Rolf Toft | Method and apparatus for operating system and application selection |
US20020161891A1 (en) * | 2001-04-25 | 2002-10-31 | Tatsuo Higuchi | System and method for computer resource marketing |
US20030167312A1 (en) * | 2000-09-13 | 2003-09-04 | Yoshiaki Mori | Method of copying data and recording medium including a recorded program for copying data |
US20030182415A1 (en) * | 2002-01-18 | 2003-09-25 | Dominique Vicard | Power management method and apparatus |
US20030208566A1 (en) * | 2002-05-03 | 2003-11-06 | Sonics, Inc. | Composing on-chip interconnects with configurable interfaces |
US20030208553A1 (en) * | 2002-05-03 | 2003-11-06 | Sonics, Inc. | Communication system and method with configurable posting points |
US20030208611A1 (en) * | 2002-05-03 | 2003-11-06 | Sonics, Inc. | On -chip inter-network performance optimization using configurable performance parameters |
US20040025071A1 (en) * | 2002-01-18 | 2004-02-05 | Dominique Vicard | Distributed computing system and method |
US20040128341A1 (en) * | 2002-12-27 | 2004-07-01 | Kamil Synek | Method and apparatus for automatic configuration of multiple on-chip interconnects |
US20040128427A1 (en) * | 2000-12-07 | 2004-07-01 | Kazar Michael L. | Method and system for responding to file system requests |
US20040229699A1 (en) * | 2003-02-26 | 2004-11-18 | Gentles Thomas A. | Service-oriented gaming network environment |
US20050097199A1 (en) * | 2003-10-10 | 2005-05-05 | Keith Woodard | Method and system for scanning network devices |
US20050114397A1 (en) * | 2003-04-04 | 2005-05-26 | Computer Associates Think, Inc. | Method and system for management and configuration of remote agents |
WO2006014504A2 (en) | 2004-07-07 | 2006-02-09 | Sciencelogic, Llc | Self configuring network management system |
US7099932B1 (en) | 2000-08-16 | 2006-08-29 | Cisco Technology, Inc. | Method and apparatus for retrieving network quality of service policy information from a directory in a quality of service policy management system |
US20060236316A1 (en) * | 2005-04-18 | 2006-10-19 | Broadcom Corporation | Use of metadata for seamless updates |
US20070203972A1 (en) * | 2002-02-05 | 2007-08-30 | Eutech Cybernetics | Remote application publication and communication system |
US7376827B1 (en) * | 1999-11-05 | 2008-05-20 | Cisco Technology, Inc. | Directory-enabled network elements |
US20080228908A1 (en) * | 2004-07-07 | 2008-09-18 | Link David F | Management techniques for non-traditional network and information system topologies |
US20090234905A1 (en) * | 2008-03-12 | 2009-09-17 | Sysmex Corporation | Maintenance information management system, management apparatus, and maintenance information management method |
US20090264203A1 (en) * | 2006-08-08 | 2009-10-22 | Warkentin Terry D | Configurable wagering game manager |
US20100094981A1 (en) * | 2005-07-07 | 2010-04-15 | Cordray Christopher G | Dynamically Deployable Self Configuring Distributed Network Management System |
US20110022715A1 (en) * | 2003-12-30 | 2011-01-27 | Frank Chan | Management session initiation with a customer premises device |
US8090856B1 (en) * | 2000-01-31 | 2012-01-03 | Telecommunication Systems, Inc. | Intelligent messaging network server interconnection |
US20150113035A1 (en) * | 2012-06-19 | 2015-04-23 | Square Enix Holdings Co., Ltd. | Processing system, information processing apparatus, control method, program and storage medium |
US20180081929A1 (en) * | 2016-09-20 | 2018-03-22 | Konica Minolta, Inc. | Client information management apparatus and non-transitory recording medium |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6721314B1 (en) * | 1999-05-20 | 2004-04-13 | Lucent Technologies Inc. | Method and apparatus for applying once-only processing in a data network |
US6633909B1 (en) * | 1999-09-23 | 2003-10-14 | International Business Machines Corporation | Notification method that guarantees a system manager discovers an SNMP agent |
US6591310B1 (en) * | 2000-05-11 | 2003-07-08 | Lsi Logic Corporation | Method of responding to I/O request and associated reply descriptor |
JP4380032B2 (en) * | 2000-07-19 | 2009-12-09 | ソニー株式会社 | Information processing system, information processing method, and storage medium |
US20040093408A1 (en) * | 2002-11-08 | 2004-05-13 | Hirani Harikrishin W. | IT asset tracking system |
US7164435B2 (en) * | 2003-02-10 | 2007-01-16 | D-Link Systems, Inc. | Videoconferencing system |
US7640546B2 (en) * | 2004-01-16 | 2009-12-29 | Barclays Capital Inc. | Method and system for identifying active devices on network |
US20060153208A1 (en) * | 2005-01-11 | 2006-07-13 | Costanzo Francis P | Discovery, deployment, and security systems and methods |
Family Cites Families (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4800488A (en) | 1985-11-12 | 1989-01-24 | American Telephone And Telegraph Company, At&T Bell Laboratories | Method of propagating resource information in a computer network |
US5167035A (en) | 1988-09-08 | 1992-11-24 | Digital Equipment Corporation | Transferring messages between nodes in a network |
AU631276B2 (en) * | 1989-12-22 | 1992-11-19 | Bull Hn Information Systems Inc. | Name resolution in a directory database |
US5619716A (en) | 1991-11-05 | 1997-04-08 | Hitachi, Ltd. | Information processing system having a configuration management system for managing the software of the information processing system |
US5642515A (en) | 1992-04-17 | 1997-06-24 | International Business Machines Corporation | Network server for local and remote resources |
AU5953394A (en) | 1992-12-17 | 1994-07-04 | Legent Corporation | System and method for generating local area network operating statistics |
JPH0778115A (en) * | 1993-09-08 | 1995-03-20 | Fujitsu Ltd | Network definition changing system |
IL111154A0 (en) | 1993-10-21 | 1994-12-29 | Martino Ii John A | Systems and methods for electronic messaging |
US5581704A (en) | 1993-12-06 | 1996-12-03 | Panasonic Technologies, Inc. | System for maintaining data coherency in cache memory by periodically broadcasting invalidation reports from server to client |
GB2286508A (en) | 1994-02-08 | 1995-08-16 | Ibm | Performance and status monitoring in a computer network |
US5655081A (en) | 1995-03-08 | 1997-08-05 | Bmc Software, Inc. | System for monitoring and managing computer resources and applications across a distributed computing environment using an intelligent autonomous agent architecture |
US5978577A (en) * | 1995-03-17 | 1999-11-02 | Csg Systems, Inc. | Method and apparatus for transaction processing in a distributed database system |
US5687320A (en) | 1995-04-27 | 1997-11-11 | Hewlett-Packard Company | Indirect method for network peripheral automated detection |
US5659787A (en) | 1995-05-26 | 1997-08-19 | Sensormatic Electronics Corporation | Data communication network with highly efficient polling procedure |
US5628005A (en) | 1995-06-07 | 1997-05-06 | Microsoft Corporation | System and method for providing opportunistic file access in a network environment |
US5596574A (en) | 1995-07-06 | 1997-01-21 | Novell, Inc. | Method and apparatus for synchronizing data transmission with on-demand links of a network |
US5862326A (en) | 1995-09-21 | 1999-01-19 | Pacific Communication Sciences, Inc. | Efficient request-reply protocol for a client-server model |
US6195678B1 (en) * | 1996-09-03 | 2001-02-27 | Fujitsu Limited | Remote resource management system for automatically downloading required files from application server depending on contents of selected files on requesting computer |
US6016508A (en) * | 1997-07-02 | 2000-01-18 | Microsoft Corporation | Server-determined client refresh periods for dynamic directory services |
-
1999
- 1999-09-23 US US09/405,292 patent/US6430596B1/en not_active Expired - Lifetime
Cited By (67)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7376827B1 (en) * | 1999-11-05 | 2008-05-20 | Cisco Technology, Inc. | Directory-enabled network elements |
US8090856B1 (en) * | 2000-01-31 | 2012-01-03 | Telecommunication Systems, Inc. | Intelligent messaging network server interconnection |
US7099932B1 (en) | 2000-08-16 | 2006-08-29 | Cisco Technology, Inc. | Method and apparatus for retrieving network quality of service policy information from a directory in a quality of service policy management system |
US20030167312A1 (en) * | 2000-09-13 | 2003-09-04 | Yoshiaki Mori | Method of copying data and recording medium including a recorded program for copying data |
US7590798B2 (en) * | 2000-12-07 | 2009-09-15 | Netapp, Inc. | Method and system for responding to file system requests |
US20080133772A1 (en) * | 2000-12-07 | 2008-06-05 | Kazar Michael L | Method and system for responding to file system requests |
US7917693B2 (en) | 2000-12-07 | 2011-03-29 | Netapp, Inc. | Method and system for responding to file system requests |
US20110202581A1 (en) * | 2000-12-07 | 2011-08-18 | Kazar Michael L | Method and system for responding to file system requests |
US20090271459A1 (en) * | 2000-12-07 | 2009-10-29 | Kazar Michael L | Method and system for responding to file system requests |
US20040128427A1 (en) * | 2000-12-07 | 2004-07-01 | Kazar Michael L. | Method and system for responding to file system requests |
US8032697B2 (en) | 2000-12-07 | 2011-10-04 | Netapp, Inc. | Method and system for responding to file system requests |
US8429341B2 (en) | 2000-12-07 | 2013-04-23 | Netapp, Inc. | Method and system for responding to file system requests |
US7072950B2 (en) * | 2001-01-23 | 2006-07-04 | Sony Corporation | Method and apparatus for operating system and application selection |
US20020138592A1 (en) * | 2001-01-23 | 2002-09-26 | Rolf Toft | Method and apparatus for operating system and application selection |
US20020161891A1 (en) * | 2001-04-25 | 2002-10-31 | Tatsuo Higuchi | System and method for computer resource marketing |
US20060010031A1 (en) * | 2001-04-25 | 2006-01-12 | Tatsuo Higuchi | System and method for computer resource marketing |
US20040025071A1 (en) * | 2002-01-18 | 2004-02-05 | Dominique Vicard | Distributed computing system and method |
US20030182415A1 (en) * | 2002-01-18 | 2003-09-25 | Dominique Vicard | Power management method and apparatus |
US20070203972A1 (en) * | 2002-02-05 | 2007-08-30 | Eutech Cybernetics | Remote application publication and communication system |
US7587459B2 (en) * | 2002-02-05 | 2009-09-08 | Eutech Cybernetics | Remote application publication and communication system |
US20030208611A1 (en) * | 2002-05-03 | 2003-11-06 | Sonics, Inc. | On -chip inter-network performance optimization using configurable performance parameters |
US20030208553A1 (en) * | 2002-05-03 | 2003-11-06 | Sonics, Inc. | Communication system and method with configurable posting points |
US7356633B2 (en) | 2002-05-03 | 2008-04-08 | Sonics, Inc. | Composing on-chip interconnects with configurable interfaces |
US20030208566A1 (en) * | 2002-05-03 | 2003-11-06 | Sonics, Inc. | Composing on-chip interconnects with configurable interfaces |
US7194566B2 (en) | 2002-05-03 | 2007-03-20 | Sonics, Inc. | Communication system and method with configurable posting points |
US20080140903A1 (en) * | 2002-05-03 | 2008-06-12 | Chien-Chun Chou | Composing on-chip interconnects with configurable interfaces |
US7254603B2 (en) * | 2002-05-03 | 2007-08-07 | Sonics, Inc. | On-chip inter-network performance optimization using configurable performance parameters |
US7660932B2 (en) | 2002-05-03 | 2010-02-09 | Sonics, Inc. | Composing on-chip interconnects with configurable interfaces |
US7603441B2 (en) | 2002-12-27 | 2009-10-13 | Sonics, Inc. | Method and apparatus for automatic configuration of multiple on-chip interconnects |
US20040128341A1 (en) * | 2002-12-27 | 2004-07-01 | Kamil Synek | Method and apparatus for automatic configuration of multiple on-chip interconnects |
AU2004200738B2 (en) * | 2003-02-26 | 2010-07-08 | Wms Gaming Inc. | A service-oriented gaming network environment |
US20040229699A1 (en) * | 2003-02-26 | 2004-11-18 | Gentles Thomas A. | Service-oriented gaming network environment |
US20050114397A1 (en) * | 2003-04-04 | 2005-05-26 | Computer Associates Think, Inc. | Method and system for management and configuration of remote agents |
US7711803B2 (en) * | 2003-04-04 | 2010-05-04 | Computer Associates Think, Inc. | Method and system for management and configuration of remote agents |
US20050097199A1 (en) * | 2003-10-10 | 2005-05-05 | Keith Woodard | Method and system for scanning network devices |
US8281019B1 (en) | 2003-10-10 | 2012-10-02 | Symantec Corporation | Method and system for scanning network devices |
US8804569B2 (en) * | 2003-12-30 | 2014-08-12 | Bce Inc. | Management session initiation with a customer premises device |
US20110022715A1 (en) * | 2003-12-30 | 2011-01-27 | Frank Chan | Management session initiation with a customer premises device |
EP1782246A4 (en) * | 2004-07-07 | 2014-08-20 | Sciencelogic Llc | Self configuring network management system |
US9077611B2 (en) | 2004-07-07 | 2015-07-07 | Sciencelogic, Inc. | Self configuring network management system |
US10686675B2 (en) | 2004-07-07 | 2020-06-16 | Sciencelogic, Inc. | Self configuring network management system |
US20080228908A1 (en) * | 2004-07-07 | 2008-09-18 | Link David F | Management techniques for non-traditional network and information system topologies |
EP1782246A2 (en) * | 2004-07-07 | 2007-05-09 | Sciencelogic, LLC | Self configuring network management system |
US11362911B2 (en) | 2004-07-07 | 2022-06-14 | Sciencelogic, Inc. | Network management device and method for discovering and managing network connected databases |
US20060092861A1 (en) * | 2004-07-07 | 2006-05-04 | Christopher Corday | Self configuring network management system |
WO2006014504A2 (en) | 2004-07-07 | 2006-02-09 | Sciencelogic, Llc | Self configuring network management system |
US7600214B2 (en) * | 2005-04-18 | 2009-10-06 | Broadcom Corporation | Use of metadata for seamless updates |
US20100005459A1 (en) * | 2005-04-18 | 2010-01-07 | Broadcom Corporation | Use of metadata for seamless updates |
US20060236316A1 (en) * | 2005-04-18 | 2006-10-19 | Broadcom Corporation | Use of metadata for seamless updates |
US8468495B2 (en) | 2005-04-18 | 2013-06-18 | Broadcom Corporation | Use of metadata for seamless updates |
US8924915B2 (en) | 2005-04-18 | 2014-12-30 | Broadcom Corporation | Use of metadata for seamless updates |
US10237140B2 (en) | 2005-07-07 | 2019-03-19 | Sciencelogic, Inc. | Network management method using specification authorizing network task management software to operate on specified task management hardware computing components |
US10225157B2 (en) | 2005-07-07 | 2019-03-05 | Sciencelogic, Inc. | Dynamically deployable self configuring distributed network management system and method having execution authorization based on a specification defining trust domain membership and/or privileges |
US10230586B2 (en) | 2005-07-07 | 2019-03-12 | Sciencelogic, Inc. | Dynamically deployable self configuring distributed network management system |
US10230588B2 (en) | 2005-07-07 | 2019-03-12 | Sciencelogic, Inc. | Dynamically deployable self configuring distributed network management system using a trust domain specification to authorize execution of network collection software on hardware components |
US9418040B2 (en) | 2005-07-07 | 2016-08-16 | Sciencelogic, Inc. | Dynamically deployable self configuring distributed network management system |
US10230587B2 (en) | 2005-07-07 | 2019-03-12 | Sciencelogic, Inc. | Dynamically deployable self configuring distributed network management system with specification defining trust domain membership and/or privileges and data management computing component |
US20100094981A1 (en) * | 2005-07-07 | 2010-04-15 | Cordray Christopher G | Dynamically Deployable Self Configuring Distributed Network Management System |
US20090264203A1 (en) * | 2006-08-08 | 2009-10-22 | Warkentin Terry D | Configurable wagering game manager |
US8172686B2 (en) | 2006-08-08 | 2012-05-08 | Wms Gaming Inc. | Configurable wagering game manager |
US8402082B2 (en) * | 2008-03-12 | 2013-03-19 | Sysmex Corporation | Maintenance information management system, management apparatus, and maintenance information management method |
US20090234905A1 (en) * | 2008-03-12 | 2009-09-17 | Sysmex Corporation | Maintenance information management system, management apparatus, and maintenance information management method |
US11706102B2 (en) | 2008-10-10 | 2023-07-18 | Sciencelogic, Inc. | Dynamically deployable self configuring distributed network management system |
US10016676B2 (en) * | 2012-06-19 | 2018-07-10 | Square Enix Holdings Co., Ltd. | Processing system, information processing apparatus, control method, program and storage medium |
US20150113035A1 (en) * | 2012-06-19 | 2015-04-23 | Square Enix Holdings Co., Ltd. | Processing system, information processing apparatus, control method, program and storage medium |
US20180081929A1 (en) * | 2016-09-20 | 2018-03-22 | Konica Minolta, Inc. | Client information management apparatus and non-transitory recording medium |
US10671598B2 (en) * | 2016-09-20 | 2020-06-02 | Konica Minolta, Inc. | Client information management apparatus and non-transitory recording medium |
Also Published As
Publication number | Publication date |
---|---|
US6430596B1 (en) | 2002-08-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6430596B1 (en) | Managing networked directory services with auto field population | |
US5968116A (en) | Method and apparatus for facilitating the management of networked devices | |
US7552265B2 (en) | System and method for providing context information | |
US7296042B2 (en) | System and method for enabling communication among arbitrary components | |
US8606886B2 (en) | System for conversion between physical machines, virtual machines and machine images | |
US8126959B2 (en) | Method and system for dynamic redistribution of remote computer boot service in a network containing multiple boot servers | |
US7433942B2 (en) | Network management | |
JP3578254B2 (en) | How to perform system administration tasks | |
US7139816B2 (en) | Method, apparatus, and program for server based network computer load balancing across multiple boot servers | |
US7526515B2 (en) | Method and system for a grid-enabled virtual machine with movable objects | |
US6374299B1 (en) | Enhanced scalable distributed network controller | |
US7197545B1 (en) | Techniques for dynamically loading modules for devices discovered in a storage network | |
EP0613274A2 (en) | Socket structure for concurrent multiple protocol access | |
US20080104661A1 (en) | Managing Policy Settings for Remote Clients | |
JPH09198294A (en) | System performing synchronization between local area network and distributed computing environment | |
US20030009657A1 (en) | Method and system for booting of a target device in a network management system | |
US6877066B2 (en) | Method and system for adaptive caching in a network management framework using skeleton caches | |
US7418709B2 (en) | URL namespace to support multiple-protocol processing within worker processes | |
US20030145089A1 (en) | System and method for enabling arbitrary components to transfer data between each other | |
US7043726B2 (en) | Binding of processes in network systems | |
EP0709994A2 (en) | Communications management between client and server processes | |
US9241024B2 (en) | File system interface to web and network services | |
US6757747B1 (en) | Proxy object for managing an application instance on a dataless client machine | |
US7313598B1 (en) | Method and apparatus for partial replication of directory information in a distributed environment | |
US20030084113A1 (en) | Device management method, device management apparatus, and device management program |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTEL CORPORATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:DAY, MICHAEL D., II;REEL/FRAME:010378/0874 Effective date: 19991103 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
FPAY | Fee payment |
Year of fee payment: 8 |
|
FPAY | Fee payment |
Year of fee payment: 12 |