Abstract: About the middleware, there is a very famous definition that platform communication. This is a good reflection on Tuxedo because it provides a platform for running and developing, as well as a variety of communication methods. In this variety of communication methods, the most frequent WS (Workstation) is used. WS mode uses TCP connections, in order to understand the WS mode, we combine the knowledge of TCP connections to a more in-depth analysis.
Noun description:
WSC: Workstation Client WSL: Workstation Listener
WSH: Workstation Handler Server: Calculates the server-side service processing process
The TCP connection is a C / S mode, that is, the Server terminal discloses its own IP and port number. The client establishes the two parameters, and the port used by the client is typically an OS temporary allocation.
TCP Server terminals generally have two modes, one is Itemive, a concurrent. One is a server process (application layer) to process the client's request, continue to accept the request after processing, when the server is being processed, the new request is not processed, only waiting. The following is a request to come, the Server process usually opens a process to handle this request, continue to listen to the connection request of the public port.
In this transaction system in Tuxeo, there is often a large number of requests, so the first mode is definitely not, although the second mode can achieve the purpose of simultaneously handling different requests, but because of a new process every time. The system's overhead is very large, and it will affect performance. In practice, Tuxedo's WorkStation mode uses another method to implement multiple request concurrent processing. Let's take a detailed description.
The following is the configuration parameters for WSL in UBB:
WSL SRVGRP = Group1 SRVID = 200
Clopt = "- a----// ip (server IP, here): 4050 -M 2 -M 10 -X 10"
Where IP: 4050 is the WSL address of the Tuxedo server, only one WSL process. -m parameter specifies the number of WSH when starting, -m is the maximum number (the number of users will automatically start when the number of users is greater than m * x), and the maximum of the request for each WSH can be multi-channel. Number, you can understand that the request buffer for WSH can store ten requests. This way we have the above configuration to handle 20 concurrent requests at the same time, and can process 100.
According to this configuration and related parameters, we can know that Tuxedo has been treated by Tuxedo, and Tuxedo has improved on top of TCP. The listening process is still only one (WSL), but the process (WSH) that has been processed in advance, each WSH can handle multiple requests, which guarantees that a large number of requests can be handled at the same time, and save it. Temporary open service process overhead.
For a good understanding of the entire work process, we first take a look at some of the steps when WSC comes.
Figure 1: Working diagram of WSC connection (Excerpted from Tuxedo Document: ADCF04-WS)
The above figure clearly illustrates the process of connection.
It also needs to be understood here that the relationship between the WSH and Server processes. Because everyone knows, truly handle the Client request is the Server process, all business processing, and the database-related operations are done in the Server process, which is also the main part of our Tuxedo application development. My understanding is that WSH can be seen as a proxy in the local local. WSH receives the request data of the WSC, put it on the buffer, and then it is sent to the Server process, because on the same machine, the mechanism between communication between the local process is generally high. After the server is processed, the result is returned to WSH, and WSH returns the result to the WSC. In this process, WSH and WSC are kept TCP connection, while the Server process is not directly dealing with WSC. The above process can also be refer to the figure below:
Figure 2: Connection steps and related modules of WS mode
It is necessary to explain the thick line arrow between WSH and Server. Because WSH and Server are directly multi-to-many relationships, each WSH can send requests to multiple Server, each of which can accept a number of WSHs sent.
Another problem is that the TCP application is binding with the physical port of the machine. Since WSL and WSH have to communicate with WSC, and it is likely to be simultaneous, then different ports must be used. This will be related later. For the sake of simplicity, I have implemented Server and WSC on the same machine, because it is WS mode, the TCP connection is also the same, and the situation before the two machines is the same, but the data flow will use a loopback device. But does not affect our explanation of the problem.
In conjunction with the above WSL settings, we see a WSL process and two WSH processes in the WINDOWS Task Manager.
Here we combine TCP knowledge to illustrate the connection action in the WS mode. In order to facilitate data, a change in the TCP state is given here. Limited to the space, here is not explained, please refer to the relevant books.
Figure 3: TCP state change diagram
Below is the output seen in NetStat in the Windows Command window and gives a related explanation.
Figure 4: NetStat Output 1, About WSC and WSL Connection
The front two lines of the output are connected in the Time_Wait state, which is the connection left by the previous test, and the two MAXIMUM Segment Lifetime will end.
The third is the connection between the current WSC to WSL, the host name and port number displayed here. Since WSC and WSL connectivity sets are extremely short, we did not see the WSC and WSL connected ESTABLISHED state, see connected to the FIN_WAIT_2 status (from WSC angle) and Close_Wait status (from WSL angles). This status indicates that the WSC initiates Active Close, which has sent FIN and receives ACK, but has not received the WSL Fin end request, and the connection is in the HALF-CLOSE state. Close_wait indicates that WSL receives the WSC's FIN request, and sends back ACK, which corresponds to the FIN_WAIT_2 status of the WSC above.
In the second NetStat output above the figure, we can see that the WSC connection using the port number 1544 is entered to the Time_Wait state, the same as the front connection.
Figure 5: NetStat Output 1, About WSC and WSH Connection
In Figure 4 above, we explain the connection of WSC and WSL. Now let's take a look at WSC and WSH connections. Since the TouPper service is called, the request has a short processing time, so the WSC and WSH connections are not seen in FIG. In order to observe this connection, a function called Sleep (10) is added between TPinit and TPTERM, so that WSC sleeps 10s, so that the connection is kept, in which we use NetStat to see the output above. Everyone knows that in the TCP connection, the port numbers used by the general client are temporary allocation, which is usually used. However, in addition to our designated 4050 port (WSL) and monotonous growth of the 15xx WSC port, there is a 3212 port, which is the port used by WSH. The author has repeatedly repeated the above test, found that the port number of the Server end in the connection of the ESTABLISHED state is 3212 and the 3213 in the figure below, and thus it is to speculate this is the port used in our two WSHs.
From the above figure, we analyze the connection process is, WSC first and WSL establish a connection, then WSC gets the WSH port number, and WSH establish a connection to complete transaction. Since WSL is unique, it is very short to be used by multiple WSCs, so WSC and WSL connections are very short. This is consistent with the process in Figure 1, but we have not seen the process of WSL and WSH communication in STEP2.
Figure 6: NetStat Output 1, About WSC and WSH Connection Characteristics
According to Figures 4 and 5, we analyze two processes in detail. Below we analyze the output of Figure 6.
After the WSC is connected to the port 1548 and WSL, the WSC quickly enters Time_Wait, as shown in the fifth row of the first NetStat of Figure 6. The sixth lines and seventh lines, WSC ports 1549 and WSH (port 3213) are established, and the Sleep (10) mentioned above is in the Established state. Since the WSC and WSL connections are to be delayed, the combined output We can confirm that the 1549 port is used by the WSC of the 1548 port. This means that WSC and WSH establish a connection will adopt a new port, which is determined by the nature of TCP. In many TCP implementations, ports in the 2MSL wait state cannot be used immediately, so the WSC must use a new port 1549 to connect to the WSH.
Let's take a look at another interesting place. As mentioned earlier, the WSC and WSL connections quickly entered the status of Time_Wait, then WSC and WSH connections are the same? From the second NetStat results in Figure 6, we found that it is not the case. Since the connection of 1549 and 3213 is "invisible", there is no state in other TCP state conversion graphs. At this time, 1548 is also in the Time_Wait state, indicating that there is no 2MSL time for Windows TCP / IP implementation. Other connections using 1550 ports later have also been established, and only 1549 connections are completely ended. This shows how the WSC and WSH connections use it immediately after the end. The benefits of doing this are a quick release of ports, avoiding Client's host ports being exhausted, especially when the request initiated a lot. We know that the port number of the host is between 0-65535, and many are preserved, WSC cannot be used.
After the above analysis, I believe that everyone has a relatively clear understanding of the connection process of Tuxedo's WS mode. The WS method is the most used mode in the actual use of this approach helps our application development and analysis of the relevant system status. The above assumes that you have related Tuxedo development experience, you can complete the configuration and implementation of TouPper's WS version, and also require a related understanding of the TCP protocol. I hope to learn Tuxedo or network knowledge for everyone. For more detailed analysis, such as capturing related packets, listening ports, etc. Here is some of my own understanding, I also hope that everyone is correct. postscript:
The above is recently in depth learning network knowledge. After the TCP / IP has a deeper understanding and understanding, some of the views and understandings analyzed in Tuxedo work and practices, and do related tests. I think this is a good way: combine the software that is using the software to learn the principle of the network, refer to these principles to understand the actual process. Not just remember those agreements and regulations, or develop only to know, I don't know how it is. The agreement and software are the continuous development, and a sentence in Larry Peterson is what we are more important to understand why the agreement should be implemented.
Reference:
1. Tuxedo E-DOCS official documentation.
2. TCP / IP Illustrate V1: The Protocols W. Richard Stevens
3. Computer Networks: a system approach (2nd) Larry Peterson & Bruce Davie
2003.11 HUST,
Wuhan
