Linux 7th Day

Ways to avoid zombie processes on the server side: 1 ) by ignoring SIGCHLD signal to resolve zombie processes Signal (SIGCHLD, sig_ign)

2 ) by Wait method to resolve the zombie process Signal (SIGCHLD, HANDLE_SIGCHLD); Wait (NULL)

3 ) by Waitpid method to resolve the zombie process Signal (SIGCHLD, HANDLE_SIGCHLD); Wait ( -1, NULL, Wnohang)

11 states of TCP/IP

When a connection is made, TCP B is first in the listen state, a sends a request for SYN A, B receives the connection, and then sends a B and a + 1, where B represents a connection to B request a, and A + 1 represents a request for success. Last a responds to B a+1, which represents the success of B's request

Look a bit abstract, for example, a for boys, b for girls boys call Girls open room, girl Reply said, the boy entered established state, the girl asked the boy is not like himself, the boy said is, the girl into the established state.

This is the three-time handshake process.

When disconnected, a active close socket, will send a fin x field (0 bytes, b can generally pass the return value of read to determine whether a socket), B received after the TCP will silently respond to a an X + 1, on behalf of B has received a exit message, a in Fin_wait_ 2 status, b in Close_wait state,

If b also closes the socket at this point, then a will be in the TIME_WAIT state and will be eliminated for some time. b also eliminated.

Image of the example, male and female friends break up, the man said I want to break up, and the woman gave the man's things back to the woman, the woman received after said I know. At this time the man in Fin_wait_2 state (semi-connected), the woman is in close_wait state (waiting for the determination to completely put down the man),

The woman after the thought struggle, said to the man, I agreed to break up, and the man gave the woman's things back to the man, at this time, the man is in Time_wait state, has been watching women leave.

Understanding 0: What is an active socket and what is a passive socket? The service port is an active socket before listen, and then becomes a passive socket

Understanding 1: Why is TCP/IP three-time handshake, and four disconnects? since TCP/IP is a reliable connection, frequent handshake and disconnection are for information stability.

Understanding 2: Client state pushes forward process, server side state forward process

Understanding 3: Perform the active shutdown at the end, enter the TIME_WAIT state

Understand how long the 4:time_wait time is 2MSL (twice times the maximum lifetime time)

Cause: (ACK y+1) If the send failed can be re-sent.

The server side is in the closed state, not equal to the client is also in the closed state.

Understanding 5: There are several states on the graph and a closing state

Both ends will produce a closing state, and finally both sides enter the TIME_WAIT state.

If the other socket is closed and the data is written again, the sigpipe signal will be generated.

Sigpipe signal causes the process to terminate (man 7 signal, read sigpipe Default Act)

It is permissible to write to a socket that has received fin, and receiving fin just means that the other person no longer sends the data.

After receiving the RST segment, if you call write again, the sigpipe signal will be generated, and the processing of this signal is usually ignored.

Signal (Sigpipe, sig_ign);

Close terminates the two directions of data transfer.

The shutdown can have the option of terminating data transfer in a direction or terminating data transmission in two directions.

Shutdown How=1 guarantees that the peer receives an EOF character, regardless of whether another process has already opened the socket. The close cannot be guaranteed until the socket reference count is reduced to 0 o'clock. That is, until all processes have closed the socket.

Blocking I/O

Illustration 1: When the upper application App1 calls the RECV system call, if the peer does not send data (the buffer has no data), the upper application App1 will block (default behavior, blocked by the Linux kernel);

Illustration 2: When the peer sends the data, the Linux kernel recv the buffer, the kernel will copy the data to the user space after the data is available. Then the upper application App1 unblocked and performs the next steps.

Non-blocking I/O

Illustration 1: The upper-level application APP2 the socket to non-blocking mode.

Illustration 2: The upper-level application APP2 polling calls the Recv function to accept the data. If the buffer does not have data, the upper program APP2 will not block, the recv return value is-1, the error code is ewouldblock.

Illustration 3: The upper-level application constantly polls for no data coming. Will cause the upper application to be busy waiting. Consumes CPU heavily. Rarely used directly. The application scope is small, the general and the Selectio multiplex uses together.

I/O Multiplexing

Illustration 1: The upper-level application APP3 calls the select mechanism, which has the Linux kernel support to avoid app3 busy waiting. ) to poll for a change in the state of the file descriptor.

Illustration 2: When the Select managed file descriptor has no data (or the state does not change), the upper-level application APP3 also blocks.

Illustration 3: Benefits Select mechanism can manage multiple file descriptors

Note 4:select can be seen as a manager, with Select to manage multiple IO.

Once detected by an I/O or multiple io, there is our sense of events, occurs, the Select function will return, the return value is the number of detected events. You can then use select-related API functions to manipulate specific events.

Description 5:select function can set the wait time, avoid the upper application app3, long-term zombie.

Illustration 6: Compared to the blocking IO model, the SELECTI/O multiplexing model is equivalent to early blocking. When there is data coming, the call to Recv will not block.

Signal-driven I/O

Illustration 1: The upper-level application APP4 establishes the Sigio signal processing program. When the buffer has data coming, the kernel sends a signal to tell the upper application to APP4.

Illustration 2: The upper-level application APP4 receives the signal, calls the RECV function, because the buffer has data, the RECV function generally does not block.

Note 3: This is used for the model is relatively small, belonging to the typical "pull mode." That is: the upper application app4, need to call the RECV function to pull the data in.

asynchronous I/O

Illustration 1: The upper-level application APP5 calls the Aio_read function, and commits an application-tier buffer buf; After the call is complete, it is not blocked. The upper-level application APP5 can continue other tasks.

Illustration 2: When the TCPIP protocol buffer has data, Linux actively copy the kernel data to the user space. Then send a signal to the upper application app5, tell APP5 the data is there, and deal with it quickly!

Illustration 3: A typical "push mode"

Illustration 4: One of the most efficient forms, the upper-level application APP5 has the ability to process asynchronously (with the support of the Linux kernel, the implication: while processing other tasks, it can also support IO communication). What does asynchronous I/O mean?

The upper-level application APP5 can receive data (accepting asynchronous communication events) when it can also do other work. = = =) The source of the asynchronous command). With the signal-driven IO model, the upper-level application APP5 does not need to call the Recv function.

int Select(int n, fd_set *readfds, Fd_set *writefds, Fd_set *exceptfds, struct timeval *timeout);

If successful, returns the number of descriptors in all sets, returns 0 if time-out, or 1 if an error occurs.

• Monitor Readfds to see if read is blocked, and note that even end-of-file,fd is readable.
• Monitor Writefds will not be blocked if you read and write.
• Monitor for EXCEPTFD If an exception has occurred. Primarily used to read OOB data, exceptions do not refer to errors.
• Note that when a set of interfaces goes wrong, it becomes both readable and writable.
• If there is a state change, the other FD is zeroed out, and only those that have changed are kept in place to indicate which of the set has changed state.
• Parameter n is the value of the FD with the maximum value plus 1 for all FD in all set

Fd_set

Four macros are used to manipulate the Fd_set:

FD_CLR (int fd, fd_set *set);

Fd_isset (int fd, fd_set *set);

Fd_set (int fd, fd_set *set);

Fd_zero (Fd_set *set);

• Fd_zero is used to empty set;
• Fd_set and FD_CLR are used to add and delete a FD to a set;
• Fd_isset is used to indicate whether an FD is not part of a set. He is useful to see which FD is available after the select.

Time_out

Timeout is the maximum wait time that is experienced before the call starts to the select return.

Two special cases: if the value is 0, it returns immediately.

If timeout is null, it will block the wait.

struct Timeval {

Long tv_sec; /* seconds */

Long tv_usec; /* microseconds */

};

Some calls use 3 empty sets, n is zero, and a non-empty timeout to achieve a more accurate sleep.

In Linux, the Select function changes the timeout value to indicate the time remaining, but many implementations do not change the timeout.

For better portability, timeout needs to be re-assigned to the initial value in the loop.

• timeout== NULL

– Infinite Waiting

– Return 1 when signal is interrupted, errno set to Eintr

• Timeout->tv_sec = = 0 && tvptr->tv_usec = 0

– Do not wait for immediate return

• Timeout->tv_sec! = 0 | | Tvptr->tv_usec! = 0

– Wait for a specific length of time, time-out returned 0

Linux 7th Day