Data processing: measuring – calibrating – or testing – Measurement system in a specific environment – Earth science
Reexamination Certificate
1996-10-24
2001-03-27
Harrell, Robert B. (Department: 2152)
Data processing: measuring, calibrating, or testing
Measurement system in a specific environment
Earth science
C709S236000, C709S228000
Reexamination Certificate
active
06208952
ABSTRACT:
TECHNICAL FIELD
The present invention relates generally to computer-based methods and systems for communications, and, more particularly, to a method and system for registration of communication protocols.
BACKGROUND OF THE INVENTION
Computer systems typically have operating systems that support multitasking. A multitasking operating system allows multiple tasks (processes) to be executed concurrently. For example, a database server process may execute concurrently with many processes, which request services of the database server process. A client process (client) may request services by issuing a remote procedure call (RPC). A remote procedure call allows the server process (server) to invoke a server procedure on behalf of the client. To issue a remote procedure call, the client packages the procedure name and the actual in-parameters for the procedure into an interprocess communication message and sends the message to the server. The server receives the message, unpackages the procedure name and any actual in-parameters, and invokes the named procedure passing it the unpackaged in-parameters. When the procedure completes, the server packages any out-parameters into a message and sends the message to the client. The client receives the message and unpackages the out-parameters. The process of packing parameters is known as marshaling, and the process of unpacking parameters is known as unmarshaling. The marshaling and unmarshaling processes in general and the marshaling and unmarshaling of interface pointers in particular are described in U.S. Pat. No. 5,511,197, entitled “Method and System for Network Marshaling of Interface Pointers for Remote Procedure Calls,” issued on Apr. 23, 1996, which is hereby incorporated by reference.
When a client issues a remote procedure call to a server, it designates a network address of the computer system upon which the server is executing, designates an endpoint (e.g., port) that has been allocated to the server, and designates a communications protocol by which the message is to be sent. In order for the server to receive the message, it needs to be listening on that endpoint for messages sent using the designated protocol. To start listening on an endpoint for messages sent using a protocol, a server typically registers the protocol with an RPC component that is loaded as a dynamic link library as part of the server. To start the server listening, the RPC component loads a dynamic link library that contains routines for processing the protocol, allocates an endpoint for the server, and typically creates a dedicated thread in the server to process messages received at that endpoint according to the protocol. The RPC component assigns an endpoint for the server for that protocol. When a message is received at that endpoint, the loaded routines interpret the message using the protocol and provides the message to the server.
Many different communication protocols have been defined for sending messages between two processes that are either executing on the same computer system or executing on different computer systems. These protocols include LRPC, TCP/IP, SPX, IPX, NetBios, ADSP, named pipes, and UDP. These various protocols have been developed to handle efficiently different communication environments. For example, LRPC (Local Remote Procedure Call) was developed to handle communications between processes executing on the same computer system, and the TCP/IP (“Transmission Control Protocol/Internet Protocol”) protocol was developed to handle communications between processes executing on different computer systems. A system administrator typically would install various protocols on a computer system so that the programs (e.g., clients or servers) can communicate with a wide range of other programs on other computer systems. The identification of the installed protocols is generally stored in a system registry that is accessible by each executing computer program. When NRPC/DCOM server is launched, it typically checks the system registry to determine which protocols have been installed. (“DCOM” refers to the Distributed Component Object Model that allows COM objects to communicate with components and objects across network boundaries.) It then registers each protocol with the RPC component. As described above, the RPC component loads a dynamic link library containing an implementation of the protocol, allocates an endpoint, and typically creates a thread for each protocol. In addition, kernel mode drivers may be loaded and the endpoint may be registered with routines and other servers. This initialization process may take several seconds. Thus, there is a considerable overhead both in time and in use of system resources to register each communication protocol for a server. However, if a communications protocol is not registered, then the server cannot receive a message on that protocol from a client. For example, if a client can only transmit a message using the TCP/IP protocol and server has not registered that protocol, then the client and server cannot communicate. Thus, servers typically register every protocol that has been installed in their computer system so that they can communicate with as many clients as possible. However, as a result of each server registering each protocol, a substantial and possibly unacceptable overhead is placed on the computer system.
FIG. 1
illustrates the interconnection of clients with servers. The server
120
includes server application portion
121
and an RPC component
122
. When the server is launched, it accesses the registry
130
to determine which protocols are installed on the computer system. Then for each of the protocols, the server registers that protocol with the RPC component. The RPC component creates the threads, loads the dynamic link libraries, and allocates the endpoints
123
-
127
. The clients
110
either execute on the same computer system as the server or on a different computer system. A client includes a client application portion
111
and an RPC component
112
. When the client attempts to send a message on a protocol, it registers that particular communication protocol that it will use to communicate with the RPC component. The RPC component creates a thread, loads the dynamic link library for the protocol, and allocates an endpoint
113
. When the client is notified of the network address and the endpoint for the server that supports the protocol, the client can then send messages to the server. The combination of network address, protocol, and endpoint is referred to as a “string binding.” Thus, a client needs to know the string binding of a server to send a message to the server. The particular endpoint that is allocated to a server for a protocol can either be specified by the server when the protocol is registered or assigned by the RPC component and provided to the server. If the server specifies the endpoint, then this endpoint is considered to be well known in that clients can be notified of the protocol and the endpoint even before the server is launched. Thus, clients can be programmed to communicate with the server over this wellknown endpoint. If, however, the RPC component assigns an endpoint, then the server needs to notify its clients of that endpoint before they can send messages to the server via that endpoint. In some implementations, the server computer system may have an endpoint mapper process that provides the endpoints of the various servers executing on the server computer system. In such a case, the client itself need not actually know the endpoint of the server. Instead, the client RPC component can retrieve the identification of the endpoint from the endpoint mapper process in a manner that is transparent to the client.
As discussed above, there is a substantial overhead involved in registering a protocol, which, of course, is unnecessary if no client communicates with the server using that protocol during the execution of the server. Moreover, this overhead is incurred on a per-server basis. That is, each server needs to register each protoco
Goertzel Mario C.
Hill Richard D.
Mitchell Alexander A.
Shah Bharat
Harrell Robert B.
Klarquist Sparkman Campbell & Leigh & Whinston, LLP
Microsoft Corporation
Vu Thong
LandOfFree
Method and system for delayed registration of protocols does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and system for delayed registration of protocols, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for delayed registration of protocols will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2482596