(Previous)
DCOM implementation distributed application (3)
Bandwidth and potential problems
Distributed applications use the advantages of the network to combine components together. In theory, DCOM hides components to run this in different machines. In fact, the application must take into account the two main limits resulting from the network connection:
Bandwidth: The size of the parameters pass to the method call directly affect the time of the completion method.
There is a problem: physical distance and associated network devices (such as route transmission lines) can even make minimal packets have been significantly delayed.
How do DCOM helps apply these limitations? The DCOM minimizes network cycle time so that potential congestion in the network is possible. DCOM sees no connected UDP protocol in the TCP / IP protocol suite as its own transport protocol. The connectionless characteristics of the protocol allow DCOM to mix many low-level confirmation packages and actual data and address legality check (pinging) information to improve performance. Even on the connection-oriented protocol, DCOM is also superior to traditional protocols facing special applications.
Sharing connection management between applications
Most application level agreements need some kind of management from beginning to end. When the client has a serious hardware failure or network connection interrupt between customers and components has been fed for a certain period of time, it should be notified in time. A universal method for solving this problem is a time (pinging) to send a keep-alive message. If the server does not receive a ping message in a certain time interval, it concludes 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 of the PING messages allows all of these client connections to be active. In order to combine all PING messages, DCOM minimizes the size of these ping messages using the Delta pinging mechanism. For this 100 connections, it is not to send 100 customer identifiers, but create a variable identifier to repeat the 100 references representative. When the reference set changes, only the part of the intersection of the two sets is exchanged. Finally, DCOM translates all ping messages to normal messages. Only when a client is completely idle, it is scheduled to send a ping message (once every two minutes).
Figure 9 Combined Life Management
DCOM allows multiple applications (even from different sellers) to share a simple and optimized life-ascation management and network error detection protocol, which can significantly reduce bandwidth. If you run 100 different applications using 100 different traditional protocols on a server, each application on each customer is connected to each app, the server should receive a ping message. Only when these protocols work together on their pinging strategies, the overhead of the entire network is likely to decrease. And DCOM automatically provides this collaboration in any DCOM-based protocol.
Optimize the ringback of the network
A universal problem for designing distributed applications is to reduce the number of excessive returning windings on the network between components on different machines. On the Internet, each network winding will introduce 1 second or more delay. Even on a fast-fast local area network, the rotary time is also calculated in microseconds - it exceeds the level of time required for local operations.
A universal method of reducing the number of network windings is to bundle multiple methods. DCOM extends this technique to address the tasks such as connecting an object or creates an object to query objects. This technique is that it is too large to program model models in local and remote conditions.
Example: A database component provides a method that can branch or multi-line display results. In the local case, developers only need to use this method to add a list of results to the list box. In the remote situation, each of each line will cause a certain network aversion. Using a bulk method requires developers to assign all columns that can accommodate all columns out, and then retrieve it in one call and add one column to the list box. Because the programming model changes very large, developers need to make great changes to design so that applications can work effectively in distributed environments. DCOM enables component developers to easily perform batch techniques without having to use a client to use a bulk form. The Marshling mechanism of the DCOM allows the component to add the code to the client, called "proxy object", which can block multiple method calls and bundled it into a remote call.
Example: Because the needs of the logical structure of the application system (the requirements of the list box API), the developer of the above example still requires one way to list the method. However, in order to list the first call applications of the query result, it has all columns (or a batch of columns) and caching them into the proxy object. Later calls are issued from this cache, avoiding the network aversion. Developers still use a simple programming model, and the entire application is optimized.
Figure 10 Component Model: Client Cache
DCOM also allows valid guidelines from one component to another. If a component saves an index of a component on another machine, it can pass it to a customer process running on a third-party machine (assuming this customer process is using another component running on another machine. ). Customer Process Use this index to communicate directly and the second component. DCOM shortens this index and makes the first component and machine can be detached from this process. This makes it possible to provide an indexed conventional directory service for remote components.
Example 1: A chess application system enables users who are waiting for the opponent to log in to a chess directory service. Other users can browse and query the list of users who are waiting for the opponent. When a user selects his own opponent, the chess directory service system returns the opponent's client component index to the user. DCOM automatically connects two users, and the directory service system does not need to involve any other transaction process.
Example 2: A "broker" component monitors 20 servers running the same component, which monitors the server's load and the server's joining and deletion. When a customer needs to use the component, it is connected to the "broker" component, which returns the index of a component on the lightest server. DCOM automatically connects to customers and servers. At this time, "brokers" components are independent of the future process.
Figure 11 Index indication
If desired, DCOM even allows the component to insert any of any of the traditional protocols, which can be used in the DCOM functionality. Components You can use traditional configuration methods to place any proxy objects in the customer process, which can return information to the component using any protocol.
Example 1: A server-side component can communicate with an ODBC connection and a SQL Server database. When the customer gets the object, the client directly and the SQL Server database (using ODBC) is more effective than using DCOM and server communication, while the server and SQL Server database communications are more effective. In the traditional configuration of DCOM, database components can copy themselves to the client and connect themselves with SQL Server, and at this time, customers are not realized that they are no longer connected to the database components on the server, but And a local copy of the component is connected.
Example 2: A commercial system requires two communication mechanisms, one is identified from the client to a central system, which is used to issue and undo command; the other is a distributed channel, which is used To send command information simultaneously to customers connected to the system. Synchronous connection methods using DCOM can be easily and efficiently operating channels between clients / servers, while broadcast channels require a more cutting-edge mechanism, which uses multipoint broadcast technologies to accommodate a large number of listeners. DCOM allows traditional protocols ("Reliable Broadcast Protocol") to seamlessly insert into the architecture of the application system: A data receiving component can encapsulate this protocol and make it completely transparent to customers and servers. When the number of users is small, the standard DCOM point to point protocol is sufficient; and for sites with many users, advanced broadcast protocols need to be used. DCOM will provide a standard multi-channel broadcast transmission protocol that can be seamlessly ported to the application system. Figure 12 Replace DCOM with a Custom protocol
(Next)
