Blocking vs. Non-Blocking Socket efficiency?
-
What kind of server and connection?
I probably didn't ask a true question (according to the title). I am designing a socket server. Some clients will connect to it and transfer data to and from this server. Connections must be kept alive for long times and there will probably be as much as hundreds of connections. I was comparing different ways to do it and was asking myself which one is better. There are blocking vs. non-blocking solutions. To use blocking API calls and keep server ready for more accepts, a common approach seems to be having one or more threads or processes per connection. Blocking calls like Receive and Send will be handled in those threads/processes. On the other hand many people suggest that this method is not efficient so a better approach is to use asynchronous APIs like
BeginSend. This raised the question in my mind that which one is really more efficient?"I hope you live a life you're proud of. If you find that you're not, I hope you have the strength to start all over again."
- I wish I knew who is this quote from -
Almost in every site that I searched today, it is advised that
BeginSendis more efficient on server than having a separate thread for each connection. MSDN on the other hand says: "When your application callsBeginSend, the system will use a separate thread to execute the specified callback method" Now if each call will create a new thread, how is it more efficient than having just one thread available for send? Thanks a lot in advanced."I hope you live a life you're proud of. If you find that you're not, I hope you have the strength to start all over again."
- I wish I knew who is this quote from -
How much different is that considering resource consumption? Is there a good benchmarking for that?
"I hope you live a life you're proud of. If you find that you're not, I hope you have the strength to start all over again."
- I wish I knew who is this quote from -
How much different is that considering resource consumption? Is there a good benchmarking for that?
"I hope you live a life you're proud of. If you find that you're not, I hope you have the strength to start all over again."
- I wish I knew who is this quote from -
How much different is that considering resource consumption? Is there a good benchmarking for that?
"I hope you live a life you're proud of. If you find that you're not, I hope you have the strength to start all over again."
- I wish I knew who is this quote from -
In my experience, using BeginReceive etc does not cost you any throughput (at reasonable speeds) - but that's all I know, I don't do much socket programming
Thabks harold. Your help is appreciated. :)
"I hope you live a life you're proud of. If you find that you're not, I hope you have the strength to start all over again."
- I wish I knew who is this quote from -
Almost in every site that I searched today, it is advised that
BeginSendis more efficient on server than having a separate thread for each connection. MSDN on the other hand says: "When your application callsBeginSend, the system will use a separate thread to execute the specified callback method" Now if each call will create a new thread, how is it more efficient than having just one thread available for send? Thanks a lot in advanced."I hope you live a life you're proud of. If you find that you're not, I hope you have the strength to start all over again."
- I wish I knew who is this quote fromWhen you use your own threads, you are in charge. You can do whatever pleases you; the price for that is the expense of a thread. Each thread needs its own context, consisting mainly of a stack, which by default takes 1MB of memory. When you use asynchronous operation, you are relying on how they implemented that. .NET asynchronous operations use ThreadPool threads, which is a pool of threads with certain characteristics. The big advantage in using ThreadPool is you can get the same activity covered with fewer actual threads, which is great especially when you would need hundreds or thousands of them, e.g. because you have that number of sockets, or timers, or serial ports. There are disadvantages too, of course. You can't change most of the ThreadPool characteristics, e.g. stack size, thread priority, etc. And you can't change the dynamic behavior of the ThreadPool; it will start with only a few active threads, and the way they implemented it, it will detect heavy load and add more threads at a fixed rate of only 2 per second. There are some parameters one can set, but they are few because the ThreadPool is used by .NET itself, hence it needs to get launched long before your first line of managed code executes. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
-
A TCP socket server and socket connections to it. Probably many connections.
"I hope you live a life you're proud of. If you find that you're not, I hope you have the strength to start all over again."
- I wish I knew who is this quote fromPersonally, I prefer to use my own threads. I have never used the Begin... methods.
-
When you use your own threads, you are in charge. You can do whatever pleases you; the price for that is the expense of a thread. Each thread needs its own context, consisting mainly of a stack, which by default takes 1MB of memory. When you use asynchronous operation, you are relying on how they implemented that. .NET asynchronous operations use ThreadPool threads, which is a pool of threads with certain characteristics. The big advantage in using ThreadPool is you can get the same activity covered with fewer actual threads, which is great especially when you would need hundreds or thousands of them, e.g. because you have that number of sockets, or timers, or serial ports. There are disadvantages too, of course. You can't change most of the ThreadPool characteristics, e.g. stack size, thread priority, etc. And you can't change the dynamic behavior of the ThreadPool; it will start with only a few active threads, and the way they implemented it, it will detect heavy load and add more threads at a fixed rate of only 2 per second. There are some parameters one can set, but they are few because the ThreadPool is used by .NET itself, hence it needs to get launched long before your first line of managed code executes. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
Thank you so much. Detailed and informative. For what I'm doing right now, using saync functions seems to be good enough. Truth is that we don't want connections for the sake of just connections. So after connections established and when data transfer starts there will be threads and all those context switching stuff. If the only benefit is that it uses thread pool, I think we can use it if we needed. Although they probably have better performance in their thread pool. They most probably use WinSock async APIs and those native calls must be very fast. Your answer helped me a lot. Thank you again.
"I hope you live a life you're proud of. If you find that you're not, I hope you have the strength to start all over again."
- I wish I knew who is this quote from -
Thank you so much. Detailed and informative. For what I'm doing right now, using saync functions seems to be good enough. Truth is that we don't want connections for the sake of just connections. So after connections established and when data transfer starts there will be threads and all those context switching stuff. If the only benefit is that it uses thread pool, I think we can use it if we needed. Although they probably have better performance in their thread pool. They most probably use WinSock async APIs and those native calls must be very fast. Your answer helped me a lot. Thank you again.
"I hope you live a life you're proud of. If you find that you're not, I hope you have the strength to start all over again."
- I wish I knew who is this quote fromyou're welcome. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).