From stackoverflow:
Answer 1:
There are three ways to communicate with sockets in async way:
-
Open regular socket, but do not read from it (because read()
blocks) until you know there it something to be read. You can useselect()
or poll()
to check whether there are data to read from socket(s), and if there is something, read it, asread()
won't block.
-
Switch socket to non-blocking I/O, by settingO_NONBLOCK
flag with fcntl()
function. In this case read()
won't block.
-
Set socket's O_ASYNC
flag usingFIOASYNC
option of ioctl()
(seeman 7 socket
for details). In this case you will receiveSIGIO
signal when there is something to read from socket.
Third approach is async socket.
Answer 2:
In many circumstances they are different names for the same thing, but in some contexts they are quite different. So it depends. Terminology is not applied in a totally consistent way across the whole software industry.
For example in the classic sockets API, a non-blocking socket is one that simply returns immediately with a special "would block" error message, whereas a blocking socket would have blocked. Youhave to use a separate function such as select
orpoll
to find out when is a good time to retry.( work as async style)
But asynchronous sockets (as supported by Windows sockets), or the asynchronous IO pattern used in .NET, are more convenient. You call a method to start an operation, and the framework calls you back when it's done. Even here, there are basic differences. Asynchronous Win32 sockets "marshal" their results onto a specific GUI thread by passing Window messages, whereas .NET asynchronous IO is free-threaded (you don't know what thread your callback will be called on).
So they don't always mean the same thing. To distil the socket example, we could say:
- Blocking and synchronous mean the same thing: you call the API, it hangs up the thread until it has some kind of answer and returns it to you.
- Non-blocking means that if an answer can't be returned rapidly, the API returns immediately with an error and does nothing else. So there must be some related way to query whether the API is ready to be called (that is, to simulate a wait in an efficient way, to avoid manual polling in a tight loop).
- Asynchronous means that the API alwaysreturns immediately, having started a "background" effort to fulfil your request, so there must be some related way to obtain the result.
General way to implement tcp servers is “one thread/process per connection”. But on high loads this approach can be not so efficient and we need to use another patterns of connection handling. In this article I will describe how toimplement tcp-server with asynchronous connections handling using epoll() system callof Linux 2.6. kernel.
epoll is a new system call introduced in Linux 2.6. It is designed to replace the deprecated select (and also poll). Unlike these earlier system calls, which are O(n), epoll is an O(1) algorithm – this means that it scales well as the number of watched file descriptors increase. select uses a linear search through the list of watched file descriptors, which causes its O(n) behaviour, whereas epoll uses callbacks in the kernel file structure.
Another fundamental difference of epoll is that it can be used in an edge-triggered, as opposed to level-triggered, fashion. This means that you receive “hints” when the kernel believes the file descriptor has become ready for I/O, as opposed to being told “I/O can be carried out on this file descriptor”. This has a couple of minor advantages: kernel space doesn’t need to keep track of the state of the file descriptor, although it might just push that problem into user space, and user space programs can be more flexible (e.g. the readiness change notification can just be ignored).
Blocking
The default mode of socket calls is blocking. A blocking call does not return to your program until the event you requested has been completed
Nonblocking
Nonblocking calls return to your program immediately to reveal whether the requested service was completed.
An error number may mean that your call would have blocked had it been a blocking call.
If the call was, for example, a recv() call, your program might have implemented its own wait logic and reissued the nonblocking recv()
call at a later time. By using this technique, your program might have implemented its own timeout rules and closed the socket,
failing receipt of data from the partner program, within an application-determined period of time.
Asynchronous
Like nonblocking calls, asynchronous calls return control to your program immediately.
But in this case, there is no need to reissue the call. Asynchronous calls are available with the macro API.
For more information, see Task management and asynchronous function processing.
补充:
POSIX definition: