Winsock Theory Question

I've been working on learning about socket programming using the windows api and have a question about winsock. Ive made an application the spawns a thread and sits and listens for connections. Once an incoming connection as been accepted it spawns a new thread and transmits data back and forth between the server and the client, and ends the thread once the client finishes sending data. My question was if this is the correct way to do this. At first when I accepted multiple connections, it spiked the cpu extremely high because it sat in an endless loop waiting for messages, but then I found a way to limit how much cpu the thread could use so it didnt eat up cpu resources. How is it that real sockets accept so many clients. Even if you could limit each thread to only using 5% cpu, what if hundreds of connections occured at once, that would be over 100% of the cpu. Has anyone worked with sockets before and know the correct implementation for accepting a large amount of clients or know a resource that explains it? Sorry for the long post I just had a lot to include in the question. Any help would be greatly appreciated.

Quote:

---

Originally Posted by rkennedy9064

I've been working on learning about socket programming using the windows api and have a question about winsock. Ive made an application the spawns a thread and sits and listens for connections. Once an incoming connection as been accepted it spawns a new thread and transmits data back and forth between the server and the client, and ends the thread once the client finishes sending data. My question was if this is the correct way to do this.

---

This is a "one thread per connection" architecture, and is OK so long as there you do not expect a large number of connections. As a rough guide, below around 100 connections/threads it should work OK, but above that the performance will be poor owing to thread switches etc.

Quote:

---

At first when I accepted multiple connections, it spiked the cpu extremely high because it sat in an endless loop waiting for messages, but then I found a way to limit how much cpu the thread could use so it didnt eat up cpu resources.

---

This behavior means that your code is polling for new activity on each socket. Polling for activity is always a bad architecture and should be avoided at all costs. You should re-write the code to take advantage of one of the asynchronous notification architectures that Windows/Winsock provides. See below.

Quote:

---

How is it that real sockets accept so many clients. Even if you could limit each thread to only using 5% cpu, what if hundreds of connections occured at once, that would be over 100% of the cpu. Has anyone worked with sockets before and know the correct implementation for accepting a large amount of clients or know a resource that explains it? Sorry for the long post I just had a lot to include in the question. Any help would be greatly appreciated.

---

Some architectures for you to consider:
- in your one-thread-per-connection architecture, use of blocking sockets and the select() function, which blocks until there is new activity on the socket, without using any significant CPU. This architecture is good for maybe 100 connections
- in a one-thead-for-many-connections architecture, use of WSAAsyncSelect and/or WSAEventSelect. This architecture is good for a few hundred connections
- in a high-volume (several thousands of connections) environment, use of I/O completion ports (IOCP). IOCP is a complicated topic.

Mike