Blocking and non-blocking traffic

Java EE Development of various types of resources download list, the history of the most complete IT resources, personal collection summary.

synchronous, asynchronous, blocking, and non-blocking are some basic sockets calling methods, and one of the basic concepts that need to be understood and differentiated when doing network programming. There are a wealth of articles and discussions on this topic, which focus on two of the more easily confusing two, that is, non-blocking and asynchronous relationships.

Let's start with a simple list of common explanations for several ways of calling:

Sync: The function is not finished executing, the thread is suspended;

Blocking: The data function is not returned and the thread is suspended;

Asynchronous: The function returns immediately, notifying the caller by event or signal;

Non-blocking: function returns immediately, notify caller by Select

Synchronization and blocking are relatively easy to understand, but in actual programming, the concept of asynchrony and non-blocking is not visually distinguishable from the literal interpretation of "notifying callers by an event or signal" and "notify the caller by select".

Blocking traffic means that communication methods block access to sockets when they attempt to access sockets or read or write data. Prior to JDK 1.4, the way to bypass blocking restrictions was to use threads indefinitely, but this often resulted in a large amount of threading overhead, which had an impact on the performance and scalability of the system. The Java.nio package changes this situation, allowing the server to efficiently use I/O flow to handle the client requests that are serviced within a reasonable time.

There is no non-blocking communication, as I like to say, "Do whatever you want". Basically, the process is to send and read anything that can be sent/read. If there is nothing to read, it aborts the read operation and does other things until it can be read. When the data is sent, the procedure attempts to send all the data, but returns what is actually sent. It could be all data, some data, or no data at all.

Congestion does have some advantages over non-blocking, especially when it comes to error control problems. In blocking socket traffic, if an error occurs, the access automatically returns the code that flags the error. The error may be caused by a network timeout, a socket shutdown, or any type of I/O error. The only error that the method can handle in non-blocking socket traffic is the network timeout. To detect a network timeout using non-blocking traffic, you need to write slightly more code to determine how long it has been since the last time the data was received.

Which method is better depends on the application. If you are using synchronous communication, blocking traffic is better if the data does not have to be processed before reading any data, and non-blocking traffic provides an opportunity to process any data that has already been read. Asynchronous communications, such as IRC and chat clients, require non-blocking traffic to avoid freezing sockets.

A discussion on the pros and cons of blocking and non-blocking IO packages in Java

The cornerstone behind the design of NIO: Reactor mode, an architecture pattern for event multiplexing and allocation.

Reactor (reactor): An architectural pattern for event multiplexing and allocation

Typically, there are two ways to work with a file or device that is specified for a file descriptor: blocking and non-blocking. Blocking means that when attempting to read and write to the file descriptor, if there is nothing to read at the time, or is temporarily not writable, the program goes into the waiting state until something is readable or writable. For non-blocking states, if nothing is readable or writable, the read-write function returns immediately without waiting.

A common practice is to create a new thread to communicate with the socket separately (in blocking mode) each time a socket connection is established. This way has a very high response speed, and control is very simple, when the number of fewer connections is very effective, but if each connection to create a thread is undoubtedly a waste of system resources, if the number of connections will be a shortage of resources.

Another more efficient approach is to save a list of socket connections on the server side and then poll the list, and call the corresponding read operation of the socket connection if it finds that there is data readable (read-ready) on a socket port; if you find a When there is data writable on the socket port (write-ready), the corresponding write operation for that socket connection is invoked; If a socket connection to a port has been interrupted, the corresponding destructor is called to close the port. This can make full use of server resources, efficiency has been greatly improved.

Traditional blocking IO, each connection must be opened by a thread to handle, and the thread can not quit after processing.

Non-blocking IO, due to the reactor mode, is used for event multiplexing and allocation of the architecture pattern, so the thread pool can be used to deal with. When the event comes, it is processed, and the thread is returned when it is finished. Traditional blocking methods cannot be handled using a thread pool, assuming that there are currently 10,000 connections, non-blocking may be done with a thread pool of 1000 threads, while the traditional blocking methods need to be opened 10,000 to handle. If there are many connections, there will be a shortage of resources. The core advantage of non-blocking is right here.

Why do they do this, the following for their further detailed analysis of the specific:

First, let's analyze the bottleneck of traditional blocking IO. In the case of few connections, traditional IO writing is easy to use. But as the number of connections increases, the problem of traditional IO is not. As mentioned earlier, the traditional IO processing each connection consumes a thread, and the efficiency of the program when the number of threads is increased as the number of threads increases, but after a certain number of threads, it decreases with the increase of the number of thread. Here we conclude that the bottleneck of traditional blocking IO is the inability to handle too many connections.

Then, the purpose of non-blocking IO is to address this bottleneck. Instead of blocking IO, how does that happen? The number of threads in the non-blocking IO process connection is not related to the number of connections, which means that processing 10,000 connections non-blocking IO does not require 10,000 threads, and you can use 1000 or 2000 threads to handle it. Because the non-blocking IO processing connection is asynchronous. When a connection sends a request to the server, the server treats the connection request as a request "event" and assigns the "event" to the corresponding function processing. We can put this handler in a thread to execute it and return it to the thread. Such a thread can handle multiple events asynchronously. Blocking IO threads spend most of their time waiting on requests.

Reprint statement: This article turns from http://blog.csdn.net/liuzhengkang/archive/2008/12/20/3562115.aspx

===========================================================================

non-blocking Socoket programming

In the Internet is quite popular today, chatting on the internet for a lot of "net worm" is already a commonplace. Chat Room program can be said to be the most simple on the internet, the multi-point communication program. There are many ways to implement the chat room, but they use the so-called "multi-user space" to exchange information, with a typical multi-channel I/O architecture. A simple chat room, from the programmer's point of view, is to implement many-to-many communication between multiple I/O endpoints. Its architecture is shown in figure one. This realization in the user's eyes is the chat room any one person enters a paragraph of characters, other users can get this sentence. This "multi-user space" architecture is widely used in other multicast programs, and its core is multi-channel I/O communication. Multi-Channel I/O communication is also known as I/O multiplexing (i/omultiplexing) is generally used in the following situations:

The client program needs to handle the I/O multiplexing problem while simultaneously processing the interactive input and the network connection with the server;

Clients need to respond to multiple network connections at the same time (rarely seen);

The TCP server needs to simultaneously process the socket in the listening state and multiple connection states;

The server needs to handle multiple network protocol sockets;

Servers need to handle different network services and protocols at the same time.

What the chat room needs to face is the first and 32 cases. We will build a simple chat room on top of the TCP/IP protocol to give you a better understanding of multiple I/O and how it is implemented. We want to discuss the chat room function is very simple, interested friends can expand its function, developed into a more complete function of the chat room, such as user authentication, user nickname, secret information, Semote and other functions.

First it is a CLIENT/SERVER structure program that starts the server first, and then the user connects using the client. The advantage of the client/server structure is that it is fast, and the disadvantage is that when the server updates, the client also needs to be updated.
　
Network initialization

The first is to initialize the server to allow the server to enter a listening state: (For simplicity, the following referenced program is slightly inconsistent with the actual procedure, hereinafter)

SOCKFD = socket (af_inet,sock_stream, 0);
First set up a socket, the family is af_inet, the type is sock_stream.
Af_inet = ARPA Internet protocols that uses the TCP/IP protocol family
The Sock_stream type provides a sequential, reliable, Full-duplex connection based on a byte stream.
Because there is only one protocol in the Protocol family, the third parameter is 0

Bind (SOCKFD, (struct sockaddr *) &serv_addr, sizeof (SERV_ADDR));
The socket is then bound to an address.
SERV_ADDR includes sin_family = af_inet protocol family with socket
SIN_ADDR.S_ADDR = All other accepted by HTONL (inaddr_any) server
The connection that the address request establishes.
Sin_port = port on which htons (serv_tcp_port) server is listening
In this program, the server's IP and listening ports are stored in the config file.

Listen (SOCKFD, max_client);
After the address binding, the server enters the listening state.
Max_client is the total number of CLIENT connections that can be established at the same time.

After the server enters the listen state, it waits for the client to establish a connection.

The client side will first need to initialize the connection to establish the connection:

SOCKFD = socket (af_inet,sock_stream,0));
Similarly, the client first creates a socket with the same parameters as the server.

Connect (SOCKFD, (struct sockaddr *) &serv_addr, sizeof (SERV_ADDR));

Client uses connect to establish a connection.
The variables in SERV_ADDR are set to:
sin_family = af_inet protocol family with socket
SIN_ADDR.S_ADDR = inet_addr (SERV_HOST_ADDR) address is server
The address of the computer on which it resides.
Sin_port = htons (serv_tcp_port) port is the port that the server listens on.

When the client's request to establish a new connection is sent to the server side, the server uses accept to accept the
Connection:

Accept (SOCKFD, (struct sockaddr*) &cli_addr, &cli_len);
When the function returns, the CLI_ADDR retains the information of the connection.
Include each other's IP address and the port used by the other.
Accept returns a new file descriptor.

After the server has entered the listen state, because more than one user is online, the program needs to operate on these users at the same time and exchange information between them. This is called I/O multiplexing technology in implementation. Multiplexing is generally available in the following ways:

Non-blocking communication method: The file pipeline through Fcntl () to the non-blocking communication mode, at each end of the time they are polled to determine whether read and write operations can be. The disadvantage of this approach is that the costs are too high and most resources are wasted on polling.

Subprocess Method: Applies multiple child processes, each communicating to a single worker blocking mode. All child processes communicate through the IPC and the parent process. The parent process is in charge of all information. The disadvantage of this approach is that it is complex to implement, and because IPC is not completely consistent on the platform of each operating system, portability is reduced.

Signal-driven (Sigio) asynchronous I/O methods: First, asynchronous I/O is based on signaling mechanisms and is unreliable. The second single signal is not sufficient to provide more sources of information. or need to assist by other means, to achieve a very high degree of difficulty.

Select () Method: A Method--select () is provided in BSD to provide a blocking query to multiple I/O. It provides a method of blocking queries for multiple I/O descriptors at the same time, which makes it easy to implement multiplexing. POSIX also uses this approach in accordance with the Protocol for Unified UNIX specifications, so we can use the Select method in most operating systems.

Using specialized I/O multiplexer: In "UNIX?" System V Programmer ' s guide:streams describes in detail how to construct and use a multiplexer. This is no longer in detail here.
　
Here are two ways to implement multiple I/O:

1. Non-blocking communication methods

There are two ways to work with a file or device that you specify for a file descriptor: blocking and non-blocking. Blocking means that when attempting to read and write to the file descriptor, if there is nothing to read at the time, or is temporarily not writable, the program goes into the waiting state until something is readable or writable. For non-blocking states, if nothing is readable or writable, the read-write function returns immediately without waiting. By default, the file descriptor is in a blocked state. When the chat room is implemented, the server needs to take turns querying the socket established with each client, reading the characters in the socket and sending it to all other client as soon as it is readable. Also, the server has to check to see if a new client is trying to establish a connection, so that if the server blocks anywhere, other client-sent content can be compromised and the server's response is not immediately available. New client attempts to establish a connection can also be affected. So we can't use the default blocked file working mode here, and we need to make the file work in a non-blocking way. Under UNIX, Function Fcntl () can be used to change the way file I/O operations work, as described in the function:

Fcntl (SOCKFD, F_SETFL, O_nonblock);
SOCKFD is the file descriptor to change the state.
F_SETFL indicate that you want to change the state of the file descriptor
O_nonblock indicates that the file descriptor becomes non-blocking.

To save space, we use natural language to describe the chat room server:

while (1)

If there is a new connection then the new connection is established and recorded;
For (all valid connections)
Begin
If there are characters readable in this connection then
Begin
Read into the string;
For (all other valid connections)
Begin
Send the string to the connection;
End
End
End
End.

Whether or not it is readable is non-blocking because of the decision as to whether there is a new connection, so each judgment, whether or not, will be returned immediately. In this way, any client sending characters to the server or attempting to establish a new connection will not affect other client activities.

For client, after a connection is established, only two file descriptors are processed, one is the socket descriptor for the connection, and the other is standard input. As with the server, if you use blocking, it's easy to affect another read because one of them is temporarily out of the way. So they all become non-blocking, and then the client does the following actions:

While (do not want to exit)
Begin
if (the connection to the server has characters to read)
Begin
Read from the connection and output to the standard output.
End;
if (standard input readable)
Begin
Read from the standard input and output to the connection to the server.
End;
End.

These two functions are called by the above read-write, respectively:

Read (Userfd[i], line, max_line);
Userfd[i] refers to the file descriptor of the I-Client connection.
Line is the place where the read characters are stored.
Max_line is the number of characters that are read up at a time.
The return value is the number of characters actually read out.

Write (Userfd[j], line, strlen (line));
USERFD[J] is the first J-client file descriptor.
Line is the string to send.
Strlen (line) is the length of the string to send.

Analysis of the above program can be known, whether it is server or client, they are constantly taking turns querying the various file descriptors, once readable and processed. Such a program, non-stop in the implementation, as long as there is CPU resources, will not let go. Therefore, the consumption of system resources is very large. When server or client executes separately, 98% or so of CPU resources is consumed by it. Greatly consumes the system resources.

Select method Therefore, although we do not want to block the other user when a user does not respond, we should stop the operation of the program without any user's reaction, let out the preemption system resources, and enter the blocking state. Is there any way to do that? The Select method is now available in Unix systems, and is implemented in the following ways:

In the Select method, all file descriptors are blocked. Use Select to determine if there is a read (write) in a set of file descriptors, and if not, block until one is awakened. Let's look at a simpler client implementation:

Since the client only needs to handle two file descriptors, it is necessary to determine whether there are read-write file descriptors that require only two entries:

Fd_zero (Sockset);
Empty the Sockset.
Fd_set (SOCKFD, Sockset);
Add SOCKFD to the Sockset collection.
Fd_set (0, Sockset);
Add 0 (standard input) to the Sockset collection

Then the client handles the following:

While (do not want to exit)

Select (sockfd+1, &sockset, NULL, NULL, NULL);
At this point, the function blocks until there is one readable in the standard input or SOCKFD
The first parameter is the maximum value in 0 and SOCKFD plus a
The second parameter is the read set, which is the Sockset
Third, four parameters are write sets and exception sets, which are NULL in this program
The fifth argument is the timeout, which means that there is still no readable at the specified time, an error
and returns. When this parameter is NULL, the timeout time is set to infinity.
When a select is returned because it is readable, the sockset contains only the readable
Those file descriptors.
if (Fd_isset (SOCKFD, &sockset))

Fd_isset this macro to determine if SOCKFD belongs to a readable file descriptor
Read from SOCKFD and output to standard output.
}

if (Fd_isset (0, &sockset))

Fd_isset this macro to determine if SOCKFD belongs to a readable file descriptor
Read from standard input and output to SOCKFD.
}
Reset the Sockset. (soon Sockset will be emptied and SOCKFD and 0 added)
}

Look at the server situation below:

Set Sockset as follows:

Fd_zero (Sockset);
Fd_set (SOCKFD, Sockset);
For (all valid connections)
Fd_set (Userfd[i], sockset);
}
MAXFD = Largest file description symbol + 1;

Server processing is as follows:

while (1)

Select (MAXFD, &sockset, NULL, NULL, NULL);
if (Fd_isset (SOCKFD, &sockset))

There are new connections
Create a new connection and add the connection descriptor to the Sockset.
}
For (all valid connections)

if (Fd_isset (Userfd[i], &sockset))

There are characters to read in this connection
Reads the character from the connection and sends it to another valid connection.
}

}
Reset Sockset;
}

Performance comparison

Because of the select mechanism, when no characters are readable, the program is blocked, the minimum amount of CPU resources, on the same machine executing a server and several client, the system load only about 0.1, and the original Non-blocking communication method, only run a ser ver, the system load can reach about 1.5. So we recommend using SELECT.

Reference documents:

[1] UNIX network programming Volume 1 W.richard Stevens 1998 Prentice Hall
[2] Computer practical network programming Tang Yi Kennedy 1993 People's Post and telecommunications publishing house
[3] UNIX? SYSTEM V Release 4 Programmer ' s Guide:streams at&t 1990 Prentice Hall
[4] UNIX? SYSTEM V Release 4 network programmer ' s Guide at&t 1990 Prentice Hall

All the source procedures are posted on the Edoc website, if necessary can go to http://edoc.163.net download

Reprint statement: This article turns from http://dev.gameres.com/Program/Control/noSocket.htm

===========================================================================