CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 2 of 2
  1. #1
    Join Date
    Jun 2012
    Posts
    10

    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.

  2. #2
    Join Date
    Nov 2002
    Location
    California
    Posts
    4,556

    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
  •  





Click Here to Expand Forum to Full Width

Featured