Static, extern, tcp

1. static

The description of global variables (external variables) is preceded by static to form a static global variable. Global variables are static storage, and static global variables are also static storage.

The two are not different in storage methods. The difference between the two lies in that the scope of non-static global variables is the entire source program. When a source program is composed of multiple source files, non-static global variables are valid in each source file. The static global variable limits its scope, that is, it is valid only in the source file defining the variable, and cannot be used in other source files of the same source program. Because the scope of static global variables is limited to one source file, they can only be shared by functions in the source file. Therefore, errors in other source files can be avoided. From the above analysis, we can see that after a local variable is changed to a static variable, its storage mode is changed, that is, its survival time is changed. After changing a global variable to a static variable, it changes its scope and limits its scope of use.

What is the difference between a static function and a common function?

Only functions used in the current source file should be declared as internal functions (static). Internal functions should be described and defined in the current source file. For functions that can be used outside the current source file, it should be described in a header file that the source files to use these functions must contain this header file.

2. extern

Extern can be placed before a variable or function to indicate that the definition of a variable or function is in another file, prompting the compiler to find its definition in other modules when it encounters this variable or function. In addition, extern can be used to specify links.

That is to say, extern has two functions. First, when it is connected with "C", for example, extern "C" void fun (int a, int B ); the compiler will tell the compiler to translate the corresponding function name instead of the C ++ name according to the C rule when compiling the function name fun, when translating this function name, the C ++ rule will make the name "fun" completely invisible. It may be fun @ aBc_int_int # % $ or something else, this depends on the "temper" of the compiler (the methods used by different compilers are different). Why does this happen because C ++ supports function overloading, I will not discuss this issue too much here. If you are interested, you can search for it online. I believe you can get a satisfactory explanation!
When extern is not modified with "C", for example, extern int g_Int in the header file, it declares the keyword of the function or global variable scope, the declared functions and variables can be used in other modules in this module. Remember that it is a declaration, not a definition! That is to say, if Module B (compilation unit) references the global variables or functions defined in module A, it only needs to include the header file of module A. During the compilation phase, although Module B cannot find this function or variable, it does not report an error. It will find this function from the target code generated by module A during connection.

3. extern and static

(1) extern indicates that the variable has been defined elsewhere. The variable must be used here.
(2) static is a static variable. When memory is allocated, it is stored in the static zone and not on the stack.

The scope of static is the relationship between internal connections, which is somewhat different from extern. it is stored separately from the object itself, and extern is also stored separately. However, extern can be referenced by other objects using extern, but static cannot. It only allows the object to use it. first of all, static and extern are a pair of "fire cannot be" guys, that is, extern and static cannot modify a variable at the same time. Second, the static modified global variables are declared and defined at the same time, that is to say, when you declare the global variable using static in the header file, it is also defined. Finally, the scope of static modification to the global variable can only be its own compilation unit, that is to say, its "global" is only valid for the current compilation unit, but not for other compilation units, such:
(1) test1.h:
# Ifndef TEST1H
# Define TEST1H
Static char g_str [] = "123456 ";
Void fun1 ();
# Endif

(2) test1.cpp:
# Include "test1.h"
Void fun1 () {cout <g_str <endl ;}
(3) test2.cpp
# Include "test1.h"
Void fun2 () {cout <g_str <endl ;}
The above two compilation units can be connected successfully. When you open test1.obj, you can find the strings "123456" in it, and you can also find them in test2.obj, the reason why they can be connected successfully without repeatedly defining errors is that although they have the same content, they store different physical addresses, just as two different variables assigned the same value, the two variables act on their respective compilation units. Maybe you are more serious. You secretly track and debug the above Code. As a result, you find that the memory address of g_str of two compilation units test1, test2 is the same, so you can conclude that static modified variables can also be applied to other modules, but I want to tell you that your compiler is deceiving you, and most compilers have optimized functions for the code, in order to achieve the generation of the Target Program, the memory is reduced and the execution efficiency is higher. When the compiler connects to each compilation unit, it will copy only one copy of the memory with the same content, for example, in the above "123456", the variables in the two compilation units are the same content, so it will only exist in the memory during the connection, if you change the code above to the following, you can immediately crack the lies of the compiler:
(1) test1.cpp:
# Include "test1.h"
Void fun1 ()
{
G_str [0] = ''a '';
Cout <g_str <endl;
}

(2) test2.cpp
# Include "test1.h"
Void fun2 () {cout <g_str <endl ;}
(3) void main (){
Fun1 (); // a23456
Fun2 (); // 123456.
}
At this time, when you track the code, you will find that the g_str address in the two compilation units is not the same, because you modified it in one place, so the compiler is forced to restore the original memory, there are two copies in the memory to use the variables in the two modules. It is precisely because static has the above features that, when defining static global variables, it is usually put in the original file rather than the header file, so that it will not cause unnecessary information pollution to other modules, remember this principle!

4. extern and const

The global constants modified by const in C ++ have the same characteristics as static, that is, they can only act on this compilation module, however, const can be connected to extern to declare that this constant can be applied to other compilation modules, such as extern const char g_str [];
Do not forget to define const char g_str [] = "123456 ";

So when the const is used independently, it is the same as static, and when it is used together with extern, its features are the same as extern! So I can't describe const too much. I just want to remind you that const char * g_str = "123456" is different from const char g_str [] = "123465, the previous const modifier is char * instead of g_str. Its g_str is not a constant, and it is regarded as a defined global variable that can be used by other compilation units ), therefore, if you want char * g_str to follow the global constant rules of const, it is better to define const char * const g_str = "123456 ".

5. TCP three-way handshake

In TCP/IP, TCP provides reliable connection services and uses three handshakes to establish a connection, as shown in figure 1. (SYN packets indicate the flag syn = 1, ACK packets indicate the flag ack = 1, SYN + ACK packets indicate the flag syn = 1, ack = 1)

(1) first handshake: when A connection is established, client A sends the SYN Packet (SEQ_NUMBER = j) to server B and enters the SYN_SEND status. Wait for server B to confirm.

(2) second handshake: When server B receives the SYN packet, it must confirm that customer A's SYN (ACK_NUMBER = j + 1) and send A SYN Packet (SEQ_NUMBER = k) by itself ), that is, the SYN + ACK packet. At this time, server B enters the SYN_RECV state.

(3) third handshake: Client A receives the SYN + ACK packet from server B and sends A confirmation packet to server B.

ACK (ACK_NUMBER = k + 1). After the package is sent, Client A and server B enter the ESTABLISHED status and complete three handshakes.

After three handshakes are completed, the client and the server start to transmit data.

6. TCP 4-way handshake disconnection Protocol

Because the TCP connection is full-duplex, each direction must be closed separately. This principle is that when one party completes its data sending task, it can send a FIN to terminate the connection in this direction. Receiving a FIN only means that there is no data flow between the two parties. a tcp connection can still send data after receiving a FIN. First, the party that closes the service will take the initiative to close the service, and the other party will passively close the service.

1) Client A sends a fin to disable data transmission from client A to server B (packet segment 4 ).

2) When server B receives the FIN, it sends back an ACK and confirms that the serial number is 1 (packet segment 5 ). Like SYN, a FIN occupies a sequence number.

3) server B Closes the connection with client A and sends A FIN to Client A (packet segment 6 ). 4) Client A sends back the ACK message for confirmation, and sets the confirmation sequence number to receive the serial number plus 1 (packet segment 7)

7,TCP connection status

CLOSED: indicates the initial state. LISTEN: indicates that a SOCKET on the server is in the listening status and can be connected. SYN_SENT: After the server listens, when the client SOCKET executes the CONNECT connection, the client sends the SYN packet, and the client enters the SYN_SENT status. Wait for the server to confirm SYN_RCVD: indicates that the server receives the SYN packet, under normal circumstances, this status is an intermediate status of the server SOCKET during the three-way handshake session when a TCP connection is established, which is very short, basically, you can hardly see this status with netstat unless you write a client test program and deliberately disable the last ACK packet from the three TCP handshakes. Therefore, when an ACK packet is received from the client, it enters the ESTABLISHED status. ESTABLISHED: indicates that the connection has been ESTABLISHED. FIN_WAIT_1: After a connection is established, one Party requests to terminate the connection and wait for the other party's FIN message. FIN_WAIT_1 is in the FIN_WAIT_1 status when the SOCKET is in the ESTABLISHED status, it wants to actively close the connection and send the FIN packet to the other party. At this time, the SOCKET enters the FIN_WAIT_1 status. When the other Party responds to the ACK packet, it enters the FIN_WAIT_2 status. Of course, under normal circumstances, the other party should immediately respond to the ACK packet, regardless of the situation, therefore, the FIN_WAIT_1 status is generally difficult to see, while the FIN_WAIT_2 status is often seen using netstat. FIN_WAIT_2: in fact, the SOCKET in the FIN_WAIT_2 State indicates a semi-connection, that is, one party requires a close connection, but also tells the other party that I still have some data to send to you, close the connection later. TIME_WAIT: indicates that the FIN packet of the other party is received, and the ACK packet is sent concurrently, so that 2MSL can return to the CLOSED available status. If FIN_WAIT_1 receives a message with both the FIN mark and ACK mark, it can directly enter the TIME_WAIT status without passing through the FIN_WAIT_2 status. CLOSING: this is a special exception that is rare in actual situations. Normally, when you send a FIN packet, you should first (or simultaneously) receive the ACK packet from the other party and then receive the FIN packet from the other party. However, the CLOSING status indicates that after you send the FIN packet, you have not received the ACK packet from the other party, but have also received the FIN packet from the other party. Under what circumstances will this happen? In fact, it is not difficult to come to the conclusion that if both parties close a SOCKET at the same time, both parties may send FIN packets at the same time, that is, the CLOSING status may occur, both parties are closing the SOCKET connection. CLOSE_WAIT: the meaning of this state is actually waiting to be closed. How can this problem be solved? When the other party closes a SOCKET and sends a FIN packet to itself, your system will undoubtedly respond to an ACK packet to the other party, and then enters the CLOSE_WAIT status. Next, in fact, what you really need to consider is to check if you still have data to send to the other party. If not, you can close the SOCKET and send the FIN packet to the other party, that is, close the connection. So what you need to do in CLOSE_WAIT is to wait for you to close the connection. LAST_ACK: this status is easy to understand. It passively closes a side and waits for the other side's ACK packet after sending the FIN message. After receiving the ACK message, you can enter the CLOSED available status.

8. View TCP network connections

Command: netstat-n | awk '/^ tcp/{++ S [$ NF]} END {for (a in S) print, S [a]} 'return result example: Cmd code LAST_ACK 5 SYN_RECV 30 ESTABLISHED 15 FIN_WAIT1 51 FIN_WAIT2 5 TIME_WAIT 10