Patent Publication Number: US-6219711-B1

Title: Synchronous communication interface

Description:
RELATED APPLICATION 
     The subject matter of U.S. Patent Application entitled “Synchronous Communication Emulation,” filed on Oct. 1, 1997, application Ser. No. 08/942,004, is related to this application. 
     PRIORITY CLAIM 
     The benefit under 35 U.S.C. §119(e) of U.S. Provisional Application No. 60/046,310, filed May 13, 1997 and entitled “High Performance Network Server System Management Interface,” is hereby claimed. 
    
    
     APPENDIX A 
     Appendix A, which forms a part of this disclosure, is a list of commonly owned copending U.S. patent applications. Each one of the applications listed in Appendix A is hereby incorporated herein in its entirety by reference thereto. 
     COPYRIGHT RIGHTS 
     A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. 
     FIELD OF THE INVENTION 
     The present invention relates generally to the field of computer communications. In particular, the present invention relates to an apparatus for performing synchronous operations in an asynchronous communications environment. 
     BACKGROUND OF THE INVENTION 
     A plurality of linked computers, known as a network, is now commonplace in businesses and organizations. Such networks include Local Area Networks (“LAN”) or Wide Area Networks (“WAN”) which are interconnected with ethernet, twisted pair, fiber optics or token ring communications hardware. 
     Computers in such networks often interact by relying on what is called the client-server model. In the client-server model, communication takes the form of request-response pairs. Generally speaking, a program at one location sends a request to a program at another location and waits for a response. The requesting program is called the “client,” and the program which responds to the request is called the “server.” 
     One client-server communication system is the Simple Network Management Protocol (“the SNMP system”). In the SNMP system, each client transmits requests to, and receives responses from, one or more servers connected to the SNMP system. Each server processes its respective requests, and if needed, sends responses back to the clients. The requests and responses generated by the clients and servers are often generally referred to as network messages, network communications, data packets, and the like. 
     In the SNMP system, client requests are often sent asynchronously. That is, the requests are processed independently and not necessarily in the same order. For example, a particular server may process one request faster than another request. In addition, some servers may execute faster than other servers. 
     Another aspect of many asynchronous networking systems is that a client often continues to generate additional requests while awaiting the response to outstanding requests. For example, assume that a client generates a first request. While a server processes the first request, the client can continue to generate additional requests. Indeed, the number of outstanding requests is not limited, and can often exceed hundreds or thousands of requests. 
     Multiple outstanding requests in an asynchronous networking system significantly add to software development complexity. For example, when a client initiates multiple outstanding requests, the client must track the status of the requests. In some instances, due to server failure, a request may not be processed. In such instances, a new request may need to be generated. 
     In addition, when the client receives a response, the client must ensure that the response is matched with the corresponding request. For instance, a server may respond to the tenth request before responding to the first request. Thus, when the client receives the response, the client must match the response with the corresponding tenth request. As can be appreciated, the complexities of tracking requests can result in errors when a response is not properly matched with a corresponding request. 
     Another drawback of conventional asynchronous networking systems occurs when a client application attempts to display the responses to multiple requests. For example, assume that a user executes a program to monitor the operational status of different network components. Such a program is often called a system management application. 
     To display the operational status of different network components, the system management application may generate a number of asynchronous requests for information about the different network components. However, it is highly probable that the system administration application will receive the responses in a different order than the requests. 
     Consequently, the system administration application may begin to display the responses in a manner which confuses the user. For example, information about the tenth component might be displayed before information about the first component. When viewing this information, a user may in some cases, see data fields which contain partial information, or no information at all. 
     Thus, when a software developer designs a software application for an asynchronous networking system, the software developer must account for the unorderly processing of the asynchronous requests. Furthermore, the developer must track the status of each outstanding asynchronous request and ensure that each response is matched with its corresponding request. 
     It is well-acknowledged that the complexity of asynchronous networking systems increase the costs of developing new applications and enhancing existing applications. Furthermore, delays in delivering completed applications, continue to be a problem. When developing an application which relies on asynchronous communications, a developer can often encounter significant delays associated with debugging the intermittent errors which can occur when matching responses to requests. 
     As can be appreciated, highly trained software developers are needed to write application programs which are compatible with asynchronous networking systems. Such software developers are often in short supply, which further delays the development of new applications and increases costs. 
     The complexity, increased costs and need for trained software developers can discourage developers from designing and developing application programs for certain asynchronous networking systems. Indeed, the success or failure of a networking system can depend on the commitment of third parties to develop applications which are compatible with the networking system. 
     Thus, software developers need a product which reduces the complexity associated with developing application programs for asynchronous networking systems. For example, current SNMP systems do not provide a mechanism which frees software developers from the complexity of asynchronous communications. Consequently, current SNMP systems do not provide a mechanism which simplifies the generation of asynchronous requests, which ensures that the requests are managed correctly, and which also reduces the time and costs associated with developing new programs. 
     SUMMARY OF THE INVENTION 
     The present invention provides a synchronous interface module which permits an application program to use a synchronous request for data in an asynchronous communications environment. The interface module contains a send request module, a monitoring module, and a receive data module. The send request module makes a request for data using a request that causes the data to return asynchronously. The monitoring module suspends operation of the interface module until the requested data is available. The receive data module retrieves the data which was obtained in response to the send request module for the interface module so that the interface module may provide the data to the application module via a synchronous communication. 
     In another embodiment of the invention, the interface comprises an apparatus for emulating a synchronous network transaction comprising an application module and an accept request module, both of which are in communication with one another. The application module includes a routine to make a data request to the accept request module so that the accept request module may receive the data request from the application module. A conversion module is also in communication with the accept request module to thereby obtain the data to satisfy the data request over an asynchronous network using one or more network communication modules. The conversion module is further configured to respond to the application module&#39;s request in a single response. Finally, a network communication module is included and is configured to provide the items of data to the conversion module using tools which provide the data in an asynchronous manner. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     These and other aspects, advantages, and novel features of the invention will become apparent upon reading the following detailed description and upon reference to accompanying drawings in which: 
     FIG. 1 illustrates a block diagram of a computer network appropriate for use with one embodiment of the invention; 
     FIG. 2 illustrates a high-level block diagram of the modules in one embodiment of the present invention; 
     FIG. 3 illustrates the module-level architecture of one embodiment of the invention; 
     FIG. 4 illustrates a flow chart of the synchronous emulation process in one embodiment of the invention; and 
     FIG. 5 illustrates a detailed flow chart of the synchronous emulation process in one embodiment of the invention. 
     FIG. 6 shows an exemplary computer system that implements one embodiment of the invention. 
    
    
     DETAILED DESCRIPTION 
     To overcome the limitations of the prior art, one embodiment of the invention provides an unique synchronous interface which configures an asynchronous networking system to emulate a synchronous networking system. Thus, the unique synchronous interface makes an asynchronous system appear to operate like a synchronous system. As a result, software developers can design applications which are much simpler and easier to develop. 
     Unlike an asynchronous networking system, a synchronous networking system processes requests in an orderly fashion. For example, in many synchronous systems, after initiating a request, the client ceases execution until the server responds. When the client receives the response, the client may then initiate another request. Thus, each request is processed before execution of the next request. 
     For instance, assume that an application desires to send to a server, two requests to obtain two data values. In an asynchronous system, the client application may send both requests before receiving any responses. The responses are then received in any order. 
     In contrast, in a synchronous system, the application sends the first request for the first data value and waits for the response. After receiving the response, the client application then sends the second request for the second data value. Thus, in a synchronous system, an application does not need to monitor and manage multiple outstanding requests. As a result, applications which are designed for a synchronous network system are much simpler and easier to develop. 
     Such applications communicate with the unique synchronous interface to initiate a synchronous transaction. The unique synchronous interface performs the tasks necessary to emulate the synchronous transaction process while actually performing a transaction on an asynchronous network. 
     To facilitate a complete understanding of the invention, the remainder of the detailed description is arranged with the following sections and subsections: 
     I. Architectural Overview 
     II. The Synchronous Communication Interface 
     III. The Synchronous Emulation Process 
     A. Operation Of The Task Loop 
     B. Timer Operation 
     C. Retry Query Operation 
     IV. Exemplarary Advantages 
     V. Conclusion 
     I. Architectural Overview 
     FIG. 1 illustrates an architectural overview of a computer system  100  appropriate for use with one embodiment of the present invention. The computer system  100  includes one or more client computer(s)  102  and one or more server computer(s)  104  connected by at least one network  106 . In one embodiment of the invention, the client and server computers  102  and  104  are multi-processor Pentium-based computers having 256 megabytes or more of RAM. It will be apparent to those of ordinary skill in the art, however, that the client and server computers  102  and  104  may be any conventional general purpose single- or multi-chip microprocessor such as a Pentium processor, a Pentium Pro processor, aa 8051 processor, a MIPS processor, a Power PC processor, an ALPHA processor, etc. 
     The network  106  can be implemented as a wide area network (“WAN”) or a local area network (“LAN”). The network  106  allows client users (i.e., users of the client computers  102 ) dispersed over a geographic area to access the server computers  104 . In one embodiment, the network  106  is implemented with a standardized communication protocol known as the Simple Network Management Protocol (“SNMP”). SNMP is explained in more detail in  The Simple Book  by Marshall T. Rose, 2d ed, Prentice-Hall, Inc., 1994, which is hereby incorporated herein by reference. The SNMP acts as a mechanism to provide and transport management information between different network components. 
     SNMP uses a transport protocol stack such as the User Datagram Protocol/Internet Protocol (“UDP/IP”) or the Transmission Control Protocol/Internet Protocol (“TCP/IP”). UDP/IP provides connectionless communication and is part of the TCP/IP suite. UDP/IP operates at the transport layer, and in contrast to TCP/IP, does not guarantee the delivery of data. TCP/IP is a standard Internet protocol (or set of protocols) which specifies how two computers exchange data over the Internet. TCP/IP handles issues such as packetization, packet addressing, handshaking and error correction. For more information on TCP/IP, see Volumes I, II and III of Comer and Stevens, Internetworking with TCP/IP, Prentice Hall, Inc., ISBNs 0-13-468505-9 (vol. I), 0-13-125527-4 (vol. II), and 0-13-474222-2 (vol. III). 
     The SNMP system as provided by NetFRAME Systems Incorporated of Milpitas, includes a number of modules. In the following description, a module includes, but is not limited to, software or hardware components which perform certain tasks. Thus, a module may include object-oriented software components, class components, methods, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, data structures, tables, arrays, variables, etc. A module may also mean a published report by a group of experts defining objects for a particular area of technology such as RFC 1213,  Management Information Base for Network Management of TCP/IP-based Internets: MIB-II.  While the modules in one embodiment of the invention comprise object-oriented C++ computer code, the invention contemplates the use of other computer languages. 
     The modules in the client computer  102  include an application module  110 , an SNMP module  112 , a MIB module  114 , a communication driver module  116  and communication hardware  118 . The SNMP module  112  sends requests to, and receives responses from the server computers  104 . As discussed in further detail below, in one embodiment, the SNMP module  112  also provides synchronous communication emulation. 
     The MIB module  114  defines the format and content of the variables associated with the SNMP network  106 . The MIB definitions are commonly contained within a conventional text file having ASCII format which is stored on a computer hard drive. Additional information regarding MIBs is available in  Managing Internetworks with SNMP  by Mark A. Miller, M&amp;T Books, 1993, which is hereby incorporated herein by reference. 
     The SNMP system also utilizes the communication driver modules  116  and the computer hardware  118  to transmit messages to the network  106 . The communication driver modules  116  are modules which provide an interface between other software modules and the communication hardware  118 . The communication driver modules  116  provide information regarding the communication hardware  118 , and provides means to interface with the communication hardware  118 . The communication hardware  118  may include various network adapters which interact with network media such as Ethernet (IEEE 802.3), Token Ring (IEEE 802.5), Fiber Distributed Datalink Interface (FDDI) or Asynchronous Transfer Mode (ATM). In one embodiment, the high speed communication channels, communication busses and controllers in the communication hardware  118 , are all provided in pairs. If one of should fail, another channel, communication bus or controller is available for use. 
     The SNMP system on the server computers  104 , on the other hand, includes an intrapulse module  130 , a systems services module  132 , an SNMP extension agent module  134 , the MIB module  114 , an SNMP agent module  136 , communication driver modules  138  and communication hardware  140 . The Intrapulse module  130  is a product from NetFrame Systems, Inc., which continuously monitors and manages the physical environment of the server computers  104 . Likewise, the system services module  132  is a software/hardware interface with provides information regarding the server computers  104  to the SNMP extension agent module  134 . Other hardware monitoring systems, however, are fully contemplated for use with the invention described herein. 
     The SNMP extension agent module  134  provides communication interface services for communication between the SNMP agent module  136  and the Intrapulse module  130  and system services module  132 . For example, if the SNMP agent module  136  does not recognize a particular request, then the request is forwarded to the SNMP extension agent module  134 . 
     The SNMP agent module  136  is a process which executes on a server computer  104 . The SNMP agent module  136  responds to requests from the client computers  102 . The SNMP agent module  136  is a standard module and is part of the SNMP network standard. 
     Like the communication driver modules  116  and the communication hardware  118  in the client computer  102 , the communication driver modules  138  and communication hardware  140  in the server computers  104  transmit messages on the network  106 . The communication driver modules  138  provide information regarding the communication hardware  140 , and provide a means to interface with the communication hardware  140 . The communication hardware  140  may include various network adapters which interact with network media such as Ethernet (IEEE 802.3), Token Ring (IEEE 802.5), Fiber Distributed Datalink Interface (“FDDI”) or Asynchronous Transfer Mode (“ATM”). 
     The request messages generated by the application module  110  on the client computer  102  are processed by the SNMP module  112  and then forwarded to the SNMP agent module  136  on the server computer  104 . The modules  136 ,  134 ,  130  and  132  on the server computer  104  process the request messages and send response messages back to the client computer  102 . 
     II. The Synchronous Communication Interface 
     FIG. 2 illustrates a conceptional view of the operation of the SNMP module  112 . The SNMP module  112  conceptionally provides a synchronous communication interface  200  while supporting the asynchronous communication  202  of the SNMP network  106 . The synchronous communication interface  200  appears to transform certain asynchronous data gathering operations of the SNMP module  112 , into synchronous communication operations. The asynchronous communication block  318  then operates to provide asynchronous communication on the SNMP system. 
     The synchronous communication interface  200  allows the application module  110  on the client computer  102  to generate synchronous requests. These synchronous requests are then converted into asynchronous requests. 
     For example, the application module  110  can send data requests to the SNMP module  112  using standard synchronous communication techniques. The SNMP manger module  112  then obtains the desired data from the server computer  104  via asynchronous communication  202 . Once the SNMP module  112  obtains the desired data from the server computer  104 , the SNMP module  112  forwards the desired data in a synchronous manner back to the application module  110 . While one embodiment implements the synchronous interface  200  into the SNMP module  112 , the synchronous interface  200  could be incorporated into the applications module  110 . 
     In one embodiment, the application module  110  includes network management software, however, it is contemplated that the application module would be any module which initiates a synchronous request. For example, an application module  110  for monitoring network components could make a synchronous request for information about a component such as a cooling fan. The SNMP module  112  then obtains the data about the cooling fan by initiating an asynchronous request on the network  106 . 
     Furthermore, in one embodiment, the application modules  110  take advantage of multithreading. Multithreading, is a technique which allows the simultaneous execution of different tasks. Multithreading is a special form of multitasking in which tasks originate from the same process or program. Thus an application module  110  may simultaneous execute multiple tasks in different treads. Furthermore, other application modules  110  will execute in their assigned threads. 
     In one embodiment, each thread contains an SNMP module  112 . Because the system creates a new SNMP module  112  for each new application thread, multiple SNMP modules  112  can exist at any given time. When the SNMP module  112  is instantiated it is assigned a unique identifier which is commonly referred to as a handle. Thus, one or more SNMP modules  112  provide the synchronous interfaces for multiple application modules  110 . 
     Additional detail regarding the structure of one embodiment of the modules in the client computer  102  is illustrated in FIG.  3 . The start state  300  indicates that the SNMP system is operational. The SNMP system on the client computer  102  includes a variety of modules including a MIB manager module  310 , the application module  110 , a windows module  320  and a network communications library  340 . In one embodiment, the SNMP system is Maestro Central from NetFrame Systems Inc. As described in more detail below, when the SNMP system is operational, the various modules communication with each other to send network messages to the server computer  104 . 
     When initiating a synchronous request for data, the request includes an identifier  302 , a command  304  and one or more buffer(s)  306 . The identifier  302  in one embodiment uniquely identifies different network components. For example, the identifier  302  will identify components such as fans, slots, adapters, processors, power supplies, canisters, interface cards, memory, etc. 
     The command  304 , in one embodiment, identifies the type of information to obtain about the identified component. For example, the command  304  can direct the server computer  104  to obtain data about a fan&#39;s speed, a fan&#39;s location, a temperature reading, a slot&#39;s power status, a slot&#39;s location, a slot&#39;s bus connection, an adapter&#39;s bus number, an adapter&#39;s vendor identification, whether an adapter supports hot plugability, a driver&#39;s name, a driver&#39;s version, a driver&#39;s type, a canister&#39;s location, a canister&#39;s name, a canister&#39;s serial number, a canister&#39;s power state, a power supply&#39;s status, a power supply&#39;s location, a CPU&#39;s clock frequency, a CPU&#39;s location or a voltage level at a particular point in a server, etc. 
     The buffer  306  is used to store the obtained data. Thus the buffer  306  can hold a wide variety of data structures including text, variables, tables, numerical values, flags, etc. Thus, requests by the application module  110  can include a wide variety of data types and values. Furthermore, the requests may include other commands  304  which may or may not include data values. 
     The MIB manager module  310  accesses the unique identifier  302  of each component in the server computers  104  stored in the Management Information Base (“MIB”) data  114 . When the application module  110  desires information about a particular component, the application module  110  requests the identifier  302  of the desired component from the MIB manager module  310 . The MIB manager module  310 , in turn, accesses the MIB data  114  and returns the desired identifier  302  to the application module  110 . 
     The windows module  320  is used to pass messages among different modules. In one embodiment, the window module  206  is a standard Microsoft window for passing messages. The window module  206  includes a notify flag  322  which notifies the SNMP module  112  that the requested data has been received. If multiple SNMP modules  112  exist, the window module  206  contains notify flags  322  which identify each SNMP module  112 . 
     The network communications library  340  in one embodiment of the invention is a standard WinSNMP Library. One such standard WinSNMP Library is distributed by ACE Communications. The network communications library  340  facilitates communication over the network  106  by providing a plurality of function calls. Relevant function calls include a SendMsg function  342 , an SnmpSendMsg function  344 , a Receive function  346  and an SnmpReceiveMsg function  348 . 
     As explained in more detail below, the SendMsg function  342  determines whether the network  106  is functional. If so, the SendMsg function  342  executes the SnmpSendMsg function  344 . The SnmpSendMsg function  344  uses standard routines to initiate an SNMP asynchronous request. The Receive function  346  determines whether data has been obtained. If so, the Receive function  346  executes the SnmpReceiveMsg function  348 . The SnmpReceiveMsg function  348  executes standard routines to ensure that the obtained data is loaded in to the proper data buffer  306 . 
     It is contemplated that the synchronous transaction interface described herein may operate with libraries other then the WinSNMP Library. The WinSNMP Library is but one of many libraries available which provide a standardized collection of asynchronous computer software functions. Similarly, the present synchronous transactions claimed herein need not obtain information from or operate in conjunction with such libraries. Other asynchronous software routines may be used. 
     Referring now to the SNMP module  112 , the SNMP module  112  contains a number of methods (also called functions or routines) which support the synchronous interface  200 . In an object-oriented environment, routines for performing various functions are commonly called methods. Throughout this detailed description the term method is used generally to refer software or hard components including functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, data structures, tables, arrays, variables, etc. 
     In one embodiment, the SNMP module  112  includes the GET method  350 , the GETNEXT method  352 , the SET method  354  and the Task Loop method  356 . In other embodiments, the functionality of the GET method  350 , the GETNEXT method  352 , the SET method  354 , and the Task Loop method  356  could be collectively or independently implemented in different modules. For example, the functionality of the GET method  350 , the GETNEXT method  352 , the SET method  354  or the Task Loop method  356  could be incorporated into the application module  110 . 
     The GET method  350  is used to synchronously request the values of one or more data values. The GETNEXT method  352  synchronously sequentially obtains one ore more organized values, such as values in a table while the SET method  354  sets a component variable to a desired value. The Task Loop module  356  provides synchronous functionality. The Task Loop module  356  begins operation when the application module  110  invokes the GET method  350 , the GETNEXT method  352  or the SET method  354 . 
     As described in additional detail below, the Task Loop module  356  includes a timer which monitors the time duration required to obtain a response from the server computer  104 . If a predetermined time duration is exceeded, the Task Loop module  356  responds that the requested data is unavailable. In one embodiment, the Task Loop module  356  also re-executes requests which have exceeded the desired time limit. 
     III. The Synchronous Emulation Process 
     FIG. 4 illustrates a flow chart of one embodiment of the synchronous emulation process. FIG. 4 is divided into four sections to more clearly delineate the operation and interaction of each module of the disclosed embodiment. In particular, FIG. 4 is divided vertically from left to right to display the operation, of the application module  110 , the SNMP module  112 , the network communications library  340 , and the windows module  320 . 
     D. Typical Computer System 
     FIG. 6 shows an exemplary computer system  600  that implements one embodiment of the invention. The computer system  600  includes at least one processor  610  that is configured to access at least one memory circuit  620 . As noted above, the at least one processor  610  may include multi-processor Pentium-based processors. The at least one memory circuit  620  may comprise a conventional storage device, such as a hard disk, or a random access memory. The computer system  600  further comprises a network communication interface  630  that asynchronously sends and receives data to and from a network, such as the network  106 . In one embodiment of the invention, the memory circuit  620  may store and the processor  610  may execute an application module and an accept request module. 
     Beginning in a start state  410 , the application module  110  is invoked and begins an execution thread. Furthermore, an SNMP module  112  is also created. If other application modules  110  are invoked, additional SNMP modules  112  are also created. Each SNMP module  112  is assigned its own handle. 
     For illustrative purposes, the process states of an exemplary application module  110  are shown. In this example, the application module  110  displays a number of data values about the operation of the server computers  104  on the screen of the client computer  102 . Proceeding to state  524 , the application module  110  creates a display window on the screen of the client computer  102 . 
     For example, assume that the application module  110  desires to display the operational status of a server fan. In state  410 , the application module  110  creates a window for displaying the status of the server fan. 
     Proceeding to state  428 , application module  110  initiates a request for data. To generate the request, the application module  110  creates a variable identifier list. The application module  110  obtains the desired identifiers  302  from the MIB manager module  310  and allocates the data buffer  306  for storing the desired data. 
     For example, if the application module  110  desires to obtain the status of a server fan, in state  428 , the application module  110  obtains the identifier  302  of the server fan from the MIB manager module  310 . While in state  428 , the application module  110  also allocates a data buffer  306  which will be used to store the data regarding the server fan. 
     Proceeding to state  432 , the application module  110  initiates a synchronous information request. In one embodiment, the application module  110  initiates the synchronous information request by calling the GET method  350 , the GETNEXT method  352  or the SET method  354  in the SNMP module  112 . While only one GET, GETNEXT or SET method  350 ,  352  or  354  is called at any given time, the methods  350 ,  352  and  354  perform similar functions and are discussed collectively throughout this detailed description. 
     When calling either the GET, GETNEXT or SET method  350 ,  352  or  354 , the application module  110  passes 1) the desired identifier(s)  302 , 2) the desired command  304  and 3) a pointer to the allocated data buffer  306 . For example, if the application module  110  wishes to obtain the status of a server fan, the application module  110  synchronously calls the GET method  350  and passes a fan identifier  302 , a fan status request command  304  and a pointer to a fan buffer  306 . If the application module  110  desires to obtain the status of a server fan and the status of a server power supply, the application module  110  synchronously calls the GET method  350  and passes a fan identifier  302 , a power supply identifier  302 , a fan status request command  304 , a power supply status command  304 , a pointer to a fan buffer  306  and a pointer to a power supply buffer  306 . The application module  110  then suspends execution until the application module  110  receives a response containing all of the requested data. 
     Proceeding to state  440 , the SNMP module  112  executes the synchronous request from the applications module  110 . That is, the SNMP module  112  executes the GET, GETNEXT or SET method  350 ,  352  or  354 . In the server fan example mentioned above, the SNMP module  112  executes the GET method  350 . 
     Proceeding to state  444 , the GET, GETNEXT or SET method  350 ,  352  or  354  initiates an asynchronous request. In one embodiment, the methods  350 ,  352  or  354  execute the SendMsg function  342  in the network communications library  340 . When executing the SendMsg function  342 , the methods  350 ,  352  or  354  pass the handle of the SNMP module  112 , the identifier  302 , the command  304  and the pointer to the data buffer  306 . The SendMsg function  342  then queries the network  106  and identifies whether the network  106  is operational. 
     In the server fan example, the GET method  350  executes the SendMsg function  342 . When executing the SendMsg function  342 , the GET method  350  passes the handle of the SNMP module  112 , the identifier  302  of the fan, fan status command  304  and the fan buffer  306 . 
     When multiple data values are requested, such as information about the fan and information about the power supply, the GET method  350  passes the handle of the SNMP module  112 , the corresponding identifiers  302 , commands  304  and buffers  306  to the SendMsg function  342 . 
     Proceeding to state  448 , if the network  106  is operational, the SendMsg function  342  executes the SnmpSendMsg function  344  existing in the network communications library  340 . When the SendMsg function  342  executes the SnmpSendMsg function  344 , it passes the identifier  302 , the command  304  and the pointer to the data buffer  306 . The SnmpSendMsg function  344  then performs an asynchronous transaction on the network  106 . If multiple data values are requested the SnmpSendMsg function  344  generates an asynchronous request for multiple data values. 
     In the server fan example, the SendMsg function  342  executes the SnmpSendMsg function  344  and passes to the SnmpSendMsg function  344 , the handle of the SNMP module  112 , the fan identifier  302 , the fan status command  304  and the pointer to the fan buffer  306 . 
     Referring now to state  446 , the Task Loop module  356  monitors the time needed to obtain a response from the server computer  104 . The Task Loop module  356  is further described in the section entitled “The Operation Of the Task Loop Module.” In the server fan example, the Task Loop module  356  monitors the time needed to obtain the requested fan status data. 
     Proceeding to state  452 , when the requested information returns from the server computer  104 , the SnmpSendMsg function  344  uses the handle of the SNMP module  112  to set the notify flag  322  in the windows module  320  indicating that the requested data for that SNMP module  112  has been obtained. When the notify flag  322  is set, the windows module  320 , in turn, notifies the identified SNMP module  112  that the data has been obtained. Thus, windows module  320  identifies the proper SNMP module  112  which initiated a particular request. 
     In the server fan example, when the fan status data is obtained, the SnmpSendMsg function  344  uses the handle of the SNMP module  112  to set the proper notify flag  322  in the windows module  320 . The windows module  320 , in turn, notifies the identified SNMP module  112  that the fan data has been obtained. Thus the windows module  320  can provide notification to multiple SNMP modules  112 . 
     In another embodiment, instead of setting a notification flag in the windows module  320 , the SnmpSendMsg function  344  sets a task complete indicator. The Task Loop module  356  may monitor the task complete indicator to determine when to execute the SnmpReceiveMsg function  348  to thereby retrieve the data from the network communications library  340 . 
     Proceeding to state  456 , the SNMP module  112  obtains the data using the SnmpReceiveMsg function  348 . The SnmpReceiveMsg function  348  transfers the data to the data buffer  306 . The SnmpReceiveMsg function  348  then transfers the pointer to the data buffer  306  back to the SNMP module  112 . In the server fan example, the SnmpReceiveMsg function  348  transfers the requested fan information to the fan buffer  306 . A pointer to the fan buffer  306  is then transferred back to the SNMP module  112 . 
     Proceeding to state  460 , the SNMP module  112  then forwards the data buffer  306  back to the application module  110 . In our server fan example, the GET method  350  returns the pointer to the fan buffer  306  back to the application module  110 . Proceeding to state  464 , the application module  110  can now continue execution. In this example, the application module  110  proceeds to state  468  and displays the data in the fan buffer  306  in a window on the client computer  102 . 
     A. Operation Of The Task Loop 
     FIG. 5 illustrates a flow chart of one embodiment of the Task Loop module  356  existing within the SNMP module  112 . The Task Loop module  356  emulates a feature of a synchronous network system by ensuring that a request is completed within a maximum time duration. If the request is not complete within the maximum time duration, the Task Loop module  356  notifies the application module  110  that the desired data is not available. 
     Beginning in state  446 , the Task Loop module  356  proceeds to state  502 . In state  502 , the Task Loop module  356  monitors the time duration needed to obtain a response to the asynchronous transaction. In one embodiment, the Task Loop module  356  monitors the time duration with a timer. The timer is designed to count to a maximum time duration. After reaching the maximum duration, the Task Loop module  356  is said to have “timed out.” 
     For example, if a request for data about the operation of a server fan is sent with the SnmpSendMsg function  344 , the Task Loop module  356  monitors the duration needed to obtain the data about the fan. If the time to obtain the fan data exceeds a set time limit, the Task Loop module  356  notifies the application module  110  that the fan data is not available. 
     If the data from the server computer  104  is obtained prior to reaching the maximum time duration, the SNMP module  112  proceeds to state  506 . In state  506 , the GET, the GETNEXT or the SET method  350 ,  352 , or  354  call the Receive function  346  in the network communications library  340 . When calling the Receive function  346 , the GET, the GET NEXT or the SET method  350 ,  352 , or  354  pass the handle of their SNMP module  112  to the network communications library  340 . The Receive function  346 , in turn, passes the handle to the SNMP module  112  to the SnmpReceiveMsg function  348 . The received data exists in the data buffer  306  and the SnmpReceiveMsg function  348  returns the data buffer  306  back to the GET, GETNEXT or SET method  350 ,  352  or  354 . 
     For example, if the GET method  350  initiated the SnmpSendMsg function  344  to obtain the data about a server fan, upon notification, the GET method  350  calls the Receive function  346  and passes the handle of its SNMP module  112 . The Receive function  346 , in turn, passes the handle of the SNMP module  112  to the SnmpReceiveMsg function  348 . The SnmpReceiveMsg function  348  then uses the handle to passes a pointer to the fan data buffer  306  back to the GET method  350 . 
     Proceeding to state  456 , the GET, GETNEXT or SET method  350 ,  352  or  354  have now obtained the requested data. Proceeding to state  460 , the GET, GETNEXT or SET method  350 ,  352  or  354  return the pointer to the filled data buffer  306  to the application module  110 . 
     For example, when the GET method  350  obtains the pointer to the fan buffer  306 , the GET method  350  passes the pointer back to the application module  110 . The application module  110  can then resume operation and access the fan data in the fan data buffer  306 . 
     B. Timer Operation 
     One aspect of emulating a synchronous transaction includes monitoring the duration required to process an asynchronous request. In an asynchronous system, at the time an asynchronous request is initiated, it is not known how long it will take to obtain a response. In many synchronous systems, however, long delays create problems. 
     For example, in a synchronous system, after an application generates a request, the application suspends operation until the application obtains the desired response. If a response is not obtained in a timely manner, the application can appear to “hang.” That is, the application may appear to have ceased functioning when the application suspends operation for an excessive amount of time. 
     One embodiment of the invention overcomes such “hang” problems by monitoring the time associated with obtaining an asynchronous response. When this embodiment has not received a response within a predefined time limit, this embodiment of the invention provides a response back to the client application that the requested data is unavailable. Providing a predefined time limit allows the application program to resume operation before it appears to “hang.” 
     For example, assume that the application module  110  initiates a synchronous request for data. After initiating the request, the application module  110  suspends operation. In one embodiment, the synchronous interface  200  of the SNMP module  112 , receives the synchronous request for data and initiates an asynchronous request on the network  106 . In addition, the SNMP module  112  monitors the time duration of the pending synchronous request. 
     If a response is not received within a predetermined time duration, the SNMP module  112  notifies the suspended application that the response has not been received. This allows the application module  110  to resume operations. In such a situation, the application module  110  can communicate to the user that the desired data is not available. 
     Returning now to state  502 , in some situations, the requested data will not be obtained within a desired time duration. The time duration in state  502 , is set by a user. In one embodiment, the timer period may be set from 1 milliseconds to 20 seconds. In an alternative embodiment, the timer is set from 50 milliseconds to 10 seconds. In yet another embodiment, the timer is set at 5 seconds. 
     The timer operation is a software routine which will monitor the time until an event occurs. The timer operation can be configured to periodically or continuously monitor a flag or event. In one embodiment, the timer in state  502  awaits notification from the notification window in state  504 . In an alternative embodiment, the timer continuously monitors the notification flag in the windows module  320 . 
     If notification is not provided, that is, if the requested data is not obtained from the server computer  104 , within the maximum time duration, the Task Loop module  356  proceeds to state  520 . 
     C. The Retry Query Operation 
     In one embodiment, the SNMP module  112  also can re-executing failed requests. As explained above, in an asynchronous system some requests may take an excessive time to process. In addition, networking components may cease functioning and consequently fail to process certain requests. 
     To ensure that requests are properly processed, one embodiment of the SNMP module  112  re-executes failed or delayed requests. Furthermore, the number of repeated attempts can be selectively configured. 
     For example, assume that one embodiment of the SNMP module  112  is configured to re-execute failed requests two times. When the application module  110  generates a synchronous request, the SNMP module  112  will in turn, initiate an asynchronous request. If a response is not received within a desired time limit, the SNMP module  112  will execute another synchronous request. If, after the second time, a response has not been received, the SNMP module  112  will notify the application module  110  that the data is not available. 
     More particularly, in state  520 , the Task Loop module  356  can attempt to resend an asynchronous request for data which has not been obtained within the maximum time duration. Thus, if data is not obtained within a desired time limit, the Task Loop module  356  can send another request for the data. 
     In state  520 , the Task Loop module  356  counts the number of attempts to obtain the data (also called retry queries). Advantageously, the maximum retries value may be set by the network administrator or computer operator. In one embodiment, it is contemplated that the maximum number of retries may be set from 0 to 100. In another embodiment, the maximum number of retries may be set from 0 to 10. In yet another embodiment, the maximum number of retries is set at 2. 
     If the number of attempts does not exceed a maximum number, the Tasks Loop module  356  proceeds again to state  448  and re-executes the SendMsg function  342  and SnmpSendMsg function  344  thereby resubmitting another request to the server computer  104 . The SendMsg function  342  and SnmpSendMsg function  344  cancel the previous pending request when initiating a new request. 
     For example, assume that the maximum number of retries is set to two. If a first request to obtain the fan data times out, the Task Loop module  356  re-initiates another request. 
     Returning to state  520 , if the maximum number of retries is exceeded, the Task Loop module  356  proceeds to state  522 . In state  522 , the GET, GETNEXT or SET method  350 ,  352 , or  354  send an “information not available” message to the application module  110 . This allows the application module  110  to resume operation within a predetermined time limit when data is unavailable. 
     For example, if the second request to obtain fan data times out, the GET method  350  returns an “information not available” message to the application module  110 . The application module  110  can then display to the user that the requested fan data is unavailable. 
     IV. Exemplarary Advantages 
     The unique synchronous interface allows the application module  110  to execute synchronous transactions in an asynchronous environment. Because the invention supports synchronous transactions, the complexity of the application module  110  is greatly reduced. The application module  110  does not need to monitor the status of multiple pending asynchronous transactions. Furthermore, the application module  110  does not need to match each request with its corresponding response. 
     This reduces errors, simplifies the development of new application modules  110 , and simplifies the upgrading and modification of existing application modules  100 . In addition, this allows programmers who are not skilled at monitoring asynchronous transactions, to create synchronous application modules  110 . As can be appreciated, the synchronous interface decreases the costs and provides an incentive for third parties to develop application modules  110 . 
     Advantageously, one embodiment of the invention provides synchronous support by providing a timer which monitors when an asynchronous transaction has exceeded a time limit. Such a timer allows the synchronous interface to provide a response to a synchronous request within a set time limit. As explained above, when the application module  110  initiates a synchronous transaction, the application module  110  may suspend execution. If the asynchronous transaction exceeds a certain amount of time, the application module  110  can appear to freeze or hang. Thus, the timer ensures that a long delay in processing a transaction will not suspend the application module  110  beyond a desired time duration. 
     Furthermore, one embodiment of the invention provides a retry query feature. The retry query feature allows a user to define the number of times to re-execute a data request. Thus, if a data request is not obtained within a desired time duration, the data request can be resent as many times as desired. If the data has not been obtained after repeated attempts, the application module  110  which initiated the data request can be notified that the data is unavailable. 
     Yet another advantage of one embodiment of the invention is that the application module  110  can rely on the orderly processing of data requests. In an asynchronous system, data requests are processed individually and thus the order of receiving the responses is not guaranteed. In contrast, the synchronous transactions in one embodiment of the invention, ensures that the responses to the data requests are obtained in an orderly manner. 
     V. Conclusion 
     While the above detailed description has shown, described and pointed out the fundamental novel features of the invention as applied to a preferred embodiment, it will be understood that various omissions, substitutions and changes in the form, and details of the illustrated device may be made by those skilled in the art without departing from the spirit of the invention. Consequently, the scope of the invention should not be limited to the foregoing discussion but should be defined by the appended claims. 
     Appendix A 
     Incorporation by Reference of Commonly Owned Applications 
     The following patent applications, commonly owned and filed Oct. 1, 1997, are hereby incorporated herein in their entirety by reference thereto: 
     
       
         
           
               
               
               
             
               
                   
                   
               
               
                   
                 Title 
                 Application No. 
               
               
                   
                   
               
             
            
               
                   
                 “System Architecture for Remote Access 
                 08/942,160 
               
               
                   
                 and Control of Environmental 
               
               
                   
                 Management” 
               
               
                   
                 “Method of Remote Access and Control of 
                 08/942,215 
               
               
                   
                 Environmental Management” 
               
               
                   
                 “System for Independent Powering of 
                 08/942,410 
               
               
                   
                 Diagnostic Processes on a Computer 
               
               
                   
                 System” 
               
               
                   
                 “Method of Independent Powering of 
                 08/942,320 
               
               
                   
                 Diagnostic Processes on a Computer 
               
               
                   
                 System” 
               
               
                   
                 “Diagnostic and Managing Distributed 
                 08/942,402 
               
               
                   
                 Processor System” 
               
               
                   
                 “Method for Managing a Distributed 
                 08/942,448 
               
               
                   
                 Processor System” 
               
               
                   
                 “System for Mapping Environmental 
                 08/942,222 
               
               
                   
                 Resources to Memory for Program Access” 
               
               
                   
                 “Method for Mapping Environmental 
                 08/942,214 
               
               
                   
                 Resources to Memory for Program Access” 
               
               
                   
                 “Hot Add of Devices Software 
                 08/942,309 
               
               
                   
                 Architecture” 
               
               
                   
                 “Method for The Hot Add of Devices” 
                 08/942,306 
               
               
                   
                 “Hot Swap of Devices Software 
                 08/942,311 
               
               
                   
                 Architecture” 
               
               
                   
                 “Method for The Hot Swap of Devices” 
                 08/942,457 
               
               
                   
                 “Method for the Hot Add of a Network 
                 08/943,072 
               
               
                   
                 Adapter on a System Including a 
               
               
                   
                 Dynamically Loaded Adapter Driver” 
               
               
                   
                 “Method for the Hot Add of a Mass 
                 08/942,069 
               
               
                   
                 Storage Adapter on a System Including a 
               
               
                   
                 Statically Loaded Adapter Driver” 
               
               
                   
                 “Method for the Hot Add of a Network 
                 08/942,465 
               
               
                   
                 Adapter on a System Including a Statically 
               
               
                   
                 Loaded Adapter Driver” 
               
               
                   
                 “Method for the Hot Add of a Mass 
                 08/962,963 
               
               
                   
                 Storage Adapter on a System Including a 
               
               
                   
                 Dynamically Loaded Adapter Driver” 
               
               
                   
                 “Method for the Hot Swap of a Network 
                 08/943,078 
               
               
                   
                 Adapter on a System Including a 
               
               
                   
                 Dynamically Loaded Adapter Driver” 
               
               
                   
                 “Method for the Hot Swap of a Mass 
                 08/942,336 
               
               
                   
                 Storage Adapter on a System Including a 
               
               
                   
                 Statically Loaded Adapter Driver” 
               
               
                   
                 “Method for the Hot Swap of a Network 
                 08/942,459 
               
               
                   
                 Adapter on a System Including a Statically 
               
               
                   
                 Loaded Adapter Driver” 
               
               
                   
                 “Method for the Hot Swap of a Mass 
                 08/942,458 
               
               
                   
                 Storage Adapter on a System Including a 
               
               
                   
                 Dynamically Loaded Adapter Driver” 
               
               
                   
                 “Method of Performing an Extensive 
                 08/942,463 
               
               
                   
                 Diagnostic Test in Conjunction with a 
               
               
                   
                 BIOS Test Routine” 
               
               
                   
                 “Apparatus for Performing an Extensive 
                 08/942,163 
               
               
                   
                 Diagnostic Test in Conjunction with a 
               
               
                   
                 BIOS Test Routine” 
               
               
                   
                 “Configuration Management Method for 
                 08/941,268 
               
               
                   
                 Hot Adding and Hot Replacing Devices” 
               
               
                   
                 “Configuration Management System for 
                 08/942,408 
               
               
                   
                 Hot Adding and Hot Replacing Devices” 
               
               
                   
                 “Apparatus for Interfacing Buses” 
                 08/942,382 
               
               
                   
                 “Method for Interfacing Buses” 
                 08/942,413 
               
               
                   
                 “Computer Fan Speed Control Device” 
                 08/942,447 
               
               
                   
                 “Computer Fan Speed Control Method” 
                 08/942,216 
               
               
                   
                 “System for Powering Up and Powering 
                 08/943,076 
               
               
                   
                 Down a Server” 
               
               
                   
                 “Method of Powering Up and Powering 
                 08/943,077 
               
               
                   
                 Down a Server” 
               
               
                   
                 “System for Resetting a Server” 
                 08/942,333 
               
               
                   
                 “Method of Resetting a Server” 
                 08/942,405 
               
               
                   
                 “System for Displaying Flight Recorder” 
                 08/942,070 
               
               
                   
                 “Method of Displaying Flight Recorder” 
                 08/942,068 
               
               
                   
                 “Synchronous Communication Emulation” 
                 08/942,004 
               
               
                   
                 “Software System Facilitating the 
                 08/942,317 
               
               
                   
                 Replacement or Insertion of Devices in a 
               
               
                   
                 Computer System” 
               
               
                   
                 “Method for Facilitating the Replacement 
                 08/942,316 
               
               
                   
                 or Insertion of Devices in a Computer 
               
               
                   
                 System” 
               
               
                   
                 “System Management Graphical User 
                 08/943,357 
               
               
                   
                 Interface” 
               
               
                   
                 “Display of System Information” 
                 08/942,195 
               
               
                   
                 “Data Management System Supporting Hot 
                 08/942,129 
               
               
                   
                 Plug Operations on a Computer” 
               
               
                   
                 “Data Management Method Supporting 
                 08/942,124 
               
               
                   
                 Hot Plug Operations on a Computer” 
               
               
                   
                 “Alert Configurator and Manager” 
                 08/942,005 
               
               
                   
                 “Managing Computer System Alerts” 
                 08/943,356 
               
               
                   
                 “Computer Fan Speed Control System” 
                 08/940,301 
               
               
                   
                 “Computer Fan Speed Control System 
                 08/941,267 
               
               
                   
                 Method” 
               
               
                   
                 “Black Box Recorder for Information 
                 08/942,381 
               
               
                   
                 System Events” 
               
               
                   
                 “Method of Recording Information System 
                 08/942,164 
               
               
                   
                 Events” 
               
               
                   
                 “Method for Automatically Reporting a 
                 08/942,168 
               
               
                   
                 System Failure in a Server” 
               
               
                   
                 “System for Automatically Reporting a 
                 08/942,384 
               
               
                   
                 System Failure in a Server” 
               
               
                   
                 “Expansion of PCI Bus Loading Capacity” 
                 08/942,404 
               
               
                   
                 “Method for Expanding PCI Bus Loading 
                 08/942,223 
               
               
                   
                 Capacity” 
               
               
                   
                 “System for Displaying System Status” 
                 08/942,347 
               
               
                   
                 “Method of Displaying System Status” 
                 08/942,071 
               
               
                   
                 “Fault Tolerant Computer System” 
                 08/942,194 
               
               
                   
                 “Method for Hot Swapping of Network 
                 08/943,044 
               
               
                   
                 Components” 
               
               
                   
                 “A Method for Communicating a Software 
                 08/942,221 
               
               
                   
                 Generated Pulse Waveform Between Two 
               
               
                   
                 Servers in a Network” 
               
               
                   
                 “A System for Communicating a Software 
                 08/942,409 
               
               
                   
                 Generated Pulse Waveform Between Two 
               
               
                   
                 Servers in a Network” 
               
               
                   
                 “Method for Clustering Software 
                 08/942,318 
               
               
                   
                 Applications” 
               
               
                   
                 “System for Clustering Software 
                 08/942,411 
               
               
                   
                 Applications” 
               
               
                   
                 “Method for Automatically Configuring a 
                 08/942,319 
               
               
                   
                 Server after Hot Add of a Device” 
               
               
                   
                 “System for Automatically Configuring a 
                 08/942,331 
               
               
                   
                 Server after Hot Add of a Device” 
               
               
                   
                 “Method of Automatically Configuring and 
                 08/942,412 
               
               
                   
                 Formatting a Computer System and 
               
               
                   
                 Installing Software” 
               
               
                   
                 “System for Automatically Configuring 
                 08/941,955 
               
               
                   
                 and Formatting a Computer System and 
               
               
                   
                 Installing Software” 
               
               
                   
                 “Determining Slot Numbers in a 
                 08/942,462 
               
               
                   
                 Computer” 
               
               
                   
                 “System for Detecting Errors in a Network” 
                 08/942,169 
               
               
                   
                 “Method of Detecting Errors in a Network” 
                 08/940,302 
               
               
                   
                 “System for Detecting Network Errors” 
                 08/942,407 
               
               
                   
                 “Method of Detecting Network Errors” 
                 08/942,573