Electrical computers and digital processing systems: multicomput – Computer-to-computer protocol implementing – Computer-to-computer data transfer regulating
Reexamination Certificate
1997-10-01
2001-04-17
Rinehart, Mark H. (Department: 2756)
Electrical computers and digital processing systems: multicomput
Computer-to-computer protocol implementing
Computer-to-computer data transfer regulating
C709S218000, C709S230000, C709S246000, C709S248000
Reexamination Certificate
active
06219711
ABSTRACT:
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 there
Knobbe Martens Olson & Bear LLP
Micron Electronics Inc.
Rinehart Mark H.
Romero Almari
LandOfFree
Synchronous communication interface does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Synchronous communication interface, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Synchronous communication interface will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2540052