DCOM Implementation of distributed applications (III)

Bandwidth and potential problems

Distributed applications use the advantages of the network to combine components. Theoretically, DCOM hides the fact that components run on different machines. In fact, the application must take into account the two main limitations of network connection:

Bandwidth: The size of parameters passed to the method call directly affects the time when the method call is completed.

There is a problem: physical distance and related network devices (such as router-connected Transmission Lines) can even cause a significant delay to the smallest data packet.

How does DCOM help applications solve these limitations? DCOM minimizes the network cycle time to avoid potential network congestion. DCOM selects the connectionless UDP protocol in the TCP/IP protocol suite as its own transmission protocol. The connectionless feature of the Protocol enables DCOM to mix many low-level validation packages with actual data and pinging information to improve performance. Even running on connection-oriented protocols, DCOM is superior to traditional special application-oriented protocols.

Shared connection management between applications

Most application-level protocols require some management from start to end. When the client encounters a serious hardware fault or the network connection between the client and the component is interrupted for a certain period of time, the component should be notified in time. A common solution to this problem is to send an active keep-alive message for a period of time (pinging. If the server does not receive a ping message within a certain interval, it determines that the customer process is "dead ". DCOM uses a keep-alive message for each machine. Even if a client uses 100 components on a server, only one ping message can keep all these client connections active. To combine all Ping messages, DCOM uses the Delta pinging mechanism to minimize the size of these ping messages. For these 100 connections, it does not send 100 customer identifiers, but creates a variable identifier to repeat the 100 references. When the reference set changes, only the intersection of the two sets of references is exchanged. In the end, DCOM converts all Ping messages to normal messages. Only when a client is completely idle for a server, it regularly sends Ping messages (once every two minutes ).

Figure 9 life cycle management of a combination

DCOM allows multiple applications (even from different vendors) to share a simple and optimized life-cycle management and network error detection protocol, significantly reducing bandwidth. If you run 100 different applications using 100 different traditional protocols on a server, the server will receive a ping message for each application connected to each customer. Only when these protocols cooperate with each other in their pinging policies can the overhead of the entire network be reduced. DCOM automatically provides such cooperation in any DCOM-based protocol.

Optimization of network loose

A common problem in designing distributed applications is to reduce the excessive number of rounds between components on different machines on the network. On the Internet, every time the network is circled, a latency of one second or more is introduced. Even on a fast LAN, the spin time is measured in microseconds-beyond the time required for local operations.

One common way to reduce the number of network loops is to bind multiple method calls. DCOM extends the use of this technology to solve tasks such as connecting an object or creating a function for querying an object. The disadvantage of this technology for general components is that its programming model is too different in local and remote situations.

Example: A database component provides a method for Displaying results by branch or multiple rows. In the local environment, developers only need to use this method to add a column in the result to the list box. In the remote scenario, each line listed will cause a certain network spin. To use the batch method, the developer needs to allocate a buffer that can accommodate all the queried columns, and then retrieve it in one call and add one column to the list box. Because the programming model changes a lot, developers need to make major changes to the design so that the application can work effectively in a distributed environment.

DCOM allows component developers to easily execute batch technology without the need for clients to use batch APIs. The mongoling mechanism of DCOM allows the component to add code to the client, which is called a "proxy object". It can intercept multiple method calls and bind them to a remote call.

Example: Because the logic structure of the application system is required (list box API requirements), developers in the preceding example still need to list the methods one by one. However, in order to list the query results, the special proxy object in the application is called for the first time. It retrieves all columns (or a batch of columns) and caches them into the proxy object. Later calls are initiated from this cache, thus avoiding network spin. Developers still use a simple programming model, but the entire application is optimized.

Figure 10 component model: Client Cache

DCOM also allows effective guidance from one component to another. If a component is saved to an index of a component on another machine, it can pass it to a customer process running on a third-party machine (assuming that the customer process is using another component running on another machine ). The customer process can use this index to directly communicate with the second component. DCOM shortens this index and enables the first component and machine to be completely detached from this process. This makes the traditional directory service that provides indexes suitable for Remote components.

Example 1: A chess application system allows users waiting for the opponent to log on to a chess directory service. Other users can view and query the list of users waiting for the competitor. After a user selects a competitor, the chess Directory Service System returns the index of the competitor's customer component to the user. DCOM automatically connects two users. The directory service system does not need to involve any other transaction processing processes.

Example 2: A "broker" component monitors the 20 servers running the same component. It monitors the load of the server and the addition and deletion of the server. When a customer needs to use this component, it connects to the "broker" component, which returns the index of a component on the server with the least load. DCOM automatically connects the customer and server. In this case, the "broker" component has nothing to do with the subsequent process.

Figure 11 index indication

If necessary, DCOM even allows components to be inserted into any traditional protocol. This protocol can use methods that are not in the scope of DCOM functionality. The component can use the traditional configuration method to put any proxy object into the client process, which can use any protocol to send information back to the component.

Example 1: A server component can use an ODBC connection to communicate with an SQL Server database. After the customer obtains the object, the client communicates with the SQL Server database (using ODBC) more effectively than DCOM and the server. In the traditional DCOM configuration, the database component can copy itself to the client and connect itself to the SQL server, at this time, the customer does not realize that he is no longer connected to the database components on the server, but is connected to a local copy of the component.

Example 2: A commercial system requires two communication mechanisms. One is a secure and authenticated channel from the client to the central system, which is used to issue and revoke commands; the other is a distributed channel that sends Command Information to clients connected to the system at the same time. The secure and synchronous connection method of DCOM allows you to operate the channels between clients and servers in a simple and effective manner. At the same time, broadcast channels require a more advanced mechanism, it uses Multicast technology to accommodate a large number of listeners. DCOM allows the seamless insertion of traditional protocols ("reliable broadcast protocols") into the architecture of the application system: a data receiving end component can encapsulate this protocol, and make it completely transparent to customers and servers. The standard DCOM Point-to-Point Protocol is sufficient when the number of users is small and the installation volume is small. For websites with many users, advanced broadcast protocols are required. In the future, DCOM will provide a standard multi-channel broadcast transmission protocol, which can be seamlessly transplanted to application systems.

Figure 12 replacing DCOM with the m Protocol