Viewing the difference between blocking and non-blocking sockets on the receiving buffer

Recently, I saw some posts and replies on the web, while searching some of the network's descriptions of blocking non-blocking differences, and found that many people have varying degrees of misunderstanding when describing the return of both sending and receiving and the difference in buffer handling. So I want to write an article to correct the error, and as a record convenient access, if reproduced, annotated author (jwybobo2007) and the source can be.

First, the socket is blocked by default (not referring to asynchronous operations and some other special purposes, directly by default to Non-blocking), which makes the send and receive operations in a blocking state, that is, the call does not return immediately, but enters the sleep waiting operation to complete. The discussion points below are divided into sending and receiving.

A. Send choose Send (here specifically TCP) and sendto (here specifically UDP) to describe

The first thing to note is that, regardless of blocking or non-blocking, the data is copied from the application buffer to the kernel buffer (SO_RCVBUF option declaration unless the buffer size is 0) when sent. I see some people on the web saying that blocking is really sending the data to each other, and blocking occurs when you need to send all the data in front of it and then send this again, not blocking is copying to the send buffer. I have to say that the above statement is wrong.

the send operation in blocking mode will wait for all data to be copied to the send buffer before returning.

If the current send buffer total size is 8192, has been copied to the buffered data of 8000, the remaining size of 192, now need to send 2000 bytes of data, the blocking send will wait for buffer enough to copy all 2000 bytes of data, such as the first copy into 192 bytes, When the buffer successfully sends out 1808 bytes, the remaining 1808 bytes of the application buffer are copied to the kernel buffer, and the send operation returns the number of bytes successfully sent.

It's not hard to see from the above process that the sending size of the blocked send operation is necessarily the size of the sending length in your argument.

sendto operations in blocking mode are not blocked.

The reason for this is that UDP does not really send a buffer, it does is only the application of the buffer copy to the lower protocol stack, in the process of adding UDP headers, IP headers, so there is no actual blocking.

The Send action call returns immediately in non-blocking mode.

There is no objection to the immediate return. Or take the example of blocking send, when the buffer is only 192 bytes, but it needs to send 2000 bytes, the call immediately returns, and the return value is 192. As you can see, non-blocking send is simply copying as much data as possible to the buffer, so sending send in non-blocking may return a value smaller than the length of the send in your argument.

What if the buffer does not have any space. This is definitely the return immediately, but you will get wsaewouldblock/e wouldblock error, at this point you can not copy any data to the buffer, you'd better take a break and try to send.

sendto operations are not blocked in non-blocking mode (consistent with blocking, not described).

two. Receive selected recv (here specifically TCP) and recvfrom (here specifically UDP) to describe

Recv,recvfrom operation will block in blocking mode at least one byte (TCP) or a full UDP datagram is returned to the buffer.

When no data arrives, calls to them are in a sleep state and are not returned.

the Recv,recvfrom operation will return immediately in non-blocking mode.

If the buffer has any one byte data (TCP) or a full UDP datagram, they will return the received data size. If there is no data, the error wsaewouldblock/e Wouldblock is returned.

The above is about blocking non-blocking send reception and the difference in buffer processing, hope to see this article some help. At the same time also want to correct some of the network error point of view, the article expressed if there are errors, I hope everyone correct, thank you.

Reprint please indicate the author: jwybobo2007

Original address: Http://blog.csdn.net/jwybobo2007/archive/2011/01/26/6164362.aspx

Comments:

Good, especially to send blocking instructions, may be a lot of people understand the wrong, there is a way to achieve this effect of the following.
Blocking is actually sending the data to each other, and blocking occurs when you need to send all the data in front of it, and then send this re:jwybobo2007 2013-07-17 14:23 [Reply] [citation] [report] Reply xiaoxiaozhu2010: If you want to block without entering the buffer and directly transmit data, you can set the buffer to 0
This can be done if you want to test that send will be blocked:
The server side sets the buffer to a smaller number, and the listen socket does not perform the recv operation; The client-side non-stop send, should soon appear send blocked