My send() socket call iis taking its own sweet time

Hi,

I have a TCP server that handles more than 100 clients.
I keep getting bottlenecks and i narrowed it down to the send() winsock function.
A send() winsock call sometimes takes 100~300ms to finish.
I i have no clue why but this block from other clients to be served.

Socket initialization code

Code:

---

int ret = WSAStartup(MAKEWORD(2,2), &wsaData);
if(ret != 0)
{
        printf("Winsock failed to start.\n");
        system("pause");
        return;
}

server.sin_family = AF_INET;
server.sin_addr.s_addr = INADDR_ANY;
server.sin_port = htons(52000);

sock = socket(AF_INET, SOCK_STREAM, 0);
if(sock == INVALID_SOCKET)
{
        printf("Invalid Socket.\n");
        system("pause");
        return;
}

if(bind(sock, (sockaddr*)&server, sizeof(server)) != 0)
{
        printf("error");
        return;
}

if(listen(sock, 5) != 0)
{
        printf("error");
        return;
}

---

Accepting code

Code:

---

sockaddr_in from;
int fromlen = sizeof(from);
SOCKET sTmpSocket = accept(ServerSock, (struct sockaddr*)&from, &fromlen);

---

Send function caller

Code:

---

void CClient::SendPacket(BYTE* pPacket, DWORD Len)
{
        DWORD ToSendLen = Len;
        while (ToSendLen)
        {
                int iResult = send(this->ClientSocket, (char*)(pPacket + Len - ToSendLen), ToSendLen, 0);
               
                if (iResult == SOCKET_ERROR)
                        return;

                ToSendLen -= iResult;
        }
}

---

I would like to know how i can fix the delay.

Thank you very much.

Your code suggests that your architecture uses blocking sockets.

If so, well, blocking sockets by their very nature will block. The block can be frustrating, but it allows you to write code with a very simple and serialized flow logic.

If you cannot tolerate the block, there are two options: re-write using non-blocking sockets, or maintain the use of blocking sockets but re-write into a multithreaded code, with one thread per client.

Both will introduce complications, and you are in the best position to know which one might be more appropriate. For example, if there is significnat coordination amongst the clients, then multithreading might be too difficult.

Without knowing more, with only around 100 clients, the multithreaded approach might be easier than non-blocking sockets. As you start to exceed a few hundred threads, the context switching among threads makes the multithreaded approach impractical, so this architecture would not be easily extensible if you suddenly find that you need to service 1000 clients simultaneously.

Mike