But isn't beginaccept and endaccept the System.net.socket encapsulated asynchronous socket?
If you do it with multithreading, it's not called Async.
1, again stressed, asynchronous is the purpose, multithreading is a means.
The so-called Async is relative to the concept of synchronization. The so-called synchronization, that is, "when a function call is made, the call does not return until the result is obtained." "That is, you have to do one thing, and then you can do the next thing before you finish it." Async is the opposite.
Multithreading is one of many ways to achieve asynchrony. However, it is important to note that async can be done by multithreading, but it is not necessarily asynchronous to use multithreading. In order to achieve "quench thirst" for this purpose, you can use the "water" this means, but the use of "water" this means, its purpose is not necessarily to "quench thirst", may also be "eat salty understanding Salty", "mouthwash" and so on.
So "if you do it with multithreading, it's not called async" is completely wrong.
2, BeginAccept is a AsyncCallback method (delegate callback methods), the Socket class provides the callback method itself to use the ThreadPool class, so beginaccept is essentially a multi-threaded. The disadvantage of this method is that the thread cannot be managed, the default maximum concurrency is only 25, and the callback write bad main thread is easily blocked.
3, the better way is to write their own thread pool to manage threading with sockets. Accept implementation.
[Reference]
http://blog.csdn.net/awinye/article/details/537264
http://blog.csdn.net/kingfox/article/details/7233350
Gjm:c# Development Asynchronous processing is the purpose, multithreading is a means