2006 has come, looking back just past 2005, Hearts filled with emotion. In the purpose of life and life, with a clear and clear positioning, and finally know what kind of life they like, what kind of lifestyle, in technology, a lot of maturity, and a lot of open horizons, from object-oriented to components, from. NET to Java, from Microsoft to open source, quite a harvest. It is particularly worth mentioning that knowing Rod Johnson, the Daniel, has finally been developed in his own project using the Spring.net framework, which is indeed an excellent framework. And in the coming 2006, I have a main goal is B/s application development, to fill their own in the enterprise development of the other half of the gap.
Before very want to own in the TCP communication layer development experience, experiences share out, but has not realized, investigates its reason, or oneself is too lazy. Today, I finally find a time to write this article, but also for the 2005 of another form of memory.
The vast majority of C/s (including multi-layer) structure of the system, terminal and server communications are carried out through TCP (there are some of the use of UDP, but it is relatively simple compared to TCP, so not here in the list). Typically, such a C/s system needs to handle a great deal of concurrency, that is, thousands of users can be online at any time, and hundreds of users may be on-line/offline every minute. Because each user has a TCP connection to the server, how to manage all of these connections and make our TCP communication layer work stably and efficiently is the primary goal of this "tcptcp communication layer" design that I developed.
Since the beginning of the September 2004, I have been responsible for a C/s system server-side architecture design, and responsible for the implementation of the entire communication layer, in the process of exploration, gradually formed a reusable "TCP Communication Layer Framework" ("framework" the word is really scary, hehe), It is located in the Enterpriseserverbase.network namespace of the Enterpriseserverbase class library. The design/development experience I have in the communications layer is recorded here for future review. Also the period everybody to enlighten.
I expect the "TCP communication layer" is not only to accept connections, manage connections, forwarding user requests so simple, in order to build a highly reusable, flexible, pluggable TCP communication layer, need to define a lot of rules, interfaces, contracts, which requires a lot of work. The "TCP communication layer" is by no means just TCP protocol communication, due to the close connection between communication and message, it is unavoidable to include "message of communication" into our analysis, for example, based on the characteristics of TCP transmission, we may need to split, reorganize and so on to receive the message (the latter text will explain why, And how to do it). Allow me to clarify here that if only the "just" TCP communication problem is resolved, I just need to introduce the TCP component, but if you want to solve the "entire TCP communication layer" problem and make it highly reusable, you need to introduce a lot of extra stuff, such as the "message" mentioned above, and the "message" The communication protocol involved.
In our communication layer, there are several components at the core of the TCP component that collaborate with each other to build/implement a highly reusable TCP communication layer. The relationship between these components is simply illustrated as follows:
Let me explain the above picture first. When a network (TCP) component receives a request from a TCP connection, the request is forwarded to the message dispatcher, which obtains the type of the request message through the Idatastreamhelper component, and then requires the processor factory to create the corresponding type of request processor according to this type. Requests the processor to process the request and return the result. The result is then returned to the end user by the network component. Before the message dispatcher makes a request message dispatch, it may involve a series of operations, such as message encryption/decryption, message splitting/reassembly, message authentication, and so on. And, according to the different applications, there may be other message conversion requirements, and these operations may be diverse and, in order to accommodate this diversity and accessibility, this requires that the message dispatcher provide an insertion point that allows us to insert custom preprocessing and reprocessing of the request/reply message at will.
The pluggable operations in the message dispatcher above are necessary in addition to message splitting (using a solid wireframe), and message encryption and message validators (using dashed boxes) are optional and should be determined based on the actual circumstances of your application. The functional role of these typical pluggable components is described later in this article. Before continuing to introduce the implementation of the TCP component, it is necessary to mention the role of the Idatastreamhelper interface, which is used to abstract our actual communication protocols and to extract metadata about this message from any request/reply message, such as the Information such as the length, type, and so on of the message. The specific application must implement the Idatastreamhelper interface according to its own message protocol. The definition of the interface is also given in the following article.
For the above illustration, it is necessary to be reminded that the flow of the entire message is driven by the TCP component! This article organizes the implementation of the entire reusable TCP communication layer with the TCP component and the message Dispatcher component as the index. First, let's dive into the concrete implementation of the TCP component.
[1] [2] [3] [4] [5] [6] Next page
