-
July 18th, 2012, 09:18 PM
#1
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.
-
August 3rd, 2012, 06:33 PM
#2
Re: My send() socket call iis taking its own sweet time
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
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|