Timing problem in UDP

This is a discussion on Timing problem in UDP within the C Programming forums, part of the General Programming Boards category; I'm doing some quality measurements on an Internet connection and I'm having some timing problems. My code are as follows: ...

  1. #1
    Registered User
    Join Date
    May 2011
    Posts
    4

    Post Timing problem in UDP

    I'm doing some quality measurements on an Internet connection and I'm having some timing problems. My code are as follows:
    Server:
    Code:
    printf("\nMeasuring Download:\n");
    q=0;
    timeout=0;
    tsendbuffer = sendbuffer;
    while(1){
    	sendto(sock, tsendbuffer, 256,0,(struct sockaddr *)&from,sockaddrlength);
    	tsendbuffer = tsendbuffer + 256;
    	q++;
    	if(q == sendbuffsize){
    		printf("sending stop packets, q = %d\n",q);
    		sendto(sock, &stoppacket, 1, 0,(struct sockaddr*)&from 
    									,sockaddrlength);
    		do{
    			timeout=0;
    			while (((n = recvfrom(sock, &receivebuffer,1,0, 
    					(struct sockaddr *)&from ,&sockaddrlength))==-1)
    					 && (++timeout < retry)){
    				perror("down-stop");
    				printf("Timeout #%d of %d, trying again:\n", 
    									timeout,retry);
    				sendto(sock, &stoppacket, 1, 0,
    						(struct sockaddr *)&from,sockaddrlength);
    				printf("sending stop packets\n");
    			}
    			if(n<0){ 
    				perror("recvmax");
    				break;
    			}
    						
    		}while(receivebuffer[0]!='A');
    		break;
    	}
    }
    Client:
    Code:
    while(1){
        data->timeout = 0;
        while ((timeoutvar=recv(data->sock, receivebuffer,256,0))==-1){
    	    perror("recv");
    	    printf("Timeout #%d of %d, trying again:\n", data->timeout,data->retry);
    		if (++data->timeout < data->retry){
    			printf("Transfer Rate function timeout!\n");
    			return -1;
    		}
    
    	    }
    	    if( receivebuffer[0] == stoppacket[0]){
    		printf("stop pkg rec.\n");
    		printf("ko = %d\n",ko);
    		break;
    	    }
    	    ko++;
    	}
    So the server is sending data until q reaches sendbuffsize. This happens when q is equal to around 32000. The client will receive those packets and increment ko every time it receives one, however when ko is printed it is only between 32 and 21000.

    How can i ensure that all packets arrive at the client side?

    It seems to have an influence whether or not it is the fastest computer that is the client.

    Many thanks in advance!
    FusionFox

  2. #2
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,592
    > How can i ensure that all packets arrive at the client side?
    Use a TCP connection instead of a UDP connection.

    One of the properties of UDP is that packets can be lost. Some applications care more about speed of delivery, but can tolerate missing packets of data.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  3. #3
    Registered User
    Join Date
    May 2011
    Posts
    4
    Yea but I'm only testing for now so I'm doing it over a 1Gbps LAN connection so there should not be so much packet loss. An i can't switch to TCP because I'm testing the raw download rate of the Internet connection and the TCP packets are to adaptive for the purpose. So i can live with the packet loss, but I'm pretty sure that 99.9% packet loss on a 1Gbps ethernet connection is not right.

    Thanks for the reply though.

  4. #4
    Registered User
    Join Date
    Nov 2010
    Location
    Long Beach, CA
    Posts
    5,515
    It might not be the 1Gbps LAN that's causing packet loss. You said the speed of the client is a factor in packet loss. That suggests to me that the send/receive buffers on that client are getting filled too quickly or emptied too slowly. If the buffer is full, and there's no place to put a packet for processing, then it will get dropped, and since there's no retry in UDP...

  5. #5
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,592
    1Gbps is going to be no more than 100MBytes/second.

    Any modern processor is going to be able to send more than that down the pipe long before it hits 100% CPU.

    You could also add some error checking to all those sendto() calls.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  6. #6
    Registered User
    Join Date
    May 2011
    Posts
    4
    Yea thanks I will definitly try that

  7. #7
    Registered User
    Join Date
    May 2011
    Posts
    4
    in the end it turned out that the transferrate was very important for the amount of packets that where received. The UDP protocol will appernatly spam as fast as it can on the network, and if one netcard is slightly better than the other it will be able to send it faster than the receiver can receive it. This problem did ofcourse turn out to be alot worse when the client was on a wireless Internet connection and the server was on my university backbone. So the solution was to now the problem would occur and program accordingly.

  8. #8
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by FusionFox View Post
    in the end it turned out that the transferrate was very important for the amount of packets that where received. The UDP protocol will appernatly spam as fast as it can on the network, and if one netcard is slightly better than the other it will be able to send it faster than the receiver can receive it. This problem did ofcourse turn out to be alot worse when the client was on a wireless Internet connection and the server was on my university backbone. So the solution was to now the problem would occur and program accordingly.
    You can substantially improve UDP reliability by sending "ACK" packets...
    The protocal is simple...

    Server side...
    Send data blob
    Wait for ACK

    Client Side...
    Receive blob
    Send ACK

    Server Side ...
    Get ACK
    Send next packet.

    The server can then pace itself to the client's speed.

    The ACK packet is nothing... it can even be a 1 byte packet containing a 0, all it does is tell the server the client got the previous packet.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Timing-out problem
    By Finchie_88 in forum Networking/Device Communication
    Replies: 4
    Last Post: 03-06-2005, 02:06 PM
  2. Timing in C
    By nicolas in forum C Programming
    Replies: 3
    Last Post: 05-16-2004, 12:52 PM
  3. Timing in C
    By Konrad in forum C Programming
    Replies: 4
    Last Post: 06-24-2003, 01:51 AM
  4. Timing
    By Korn1699 in forum C++ Programming
    Replies: 10
    Last Post: 06-06-2002, 12:58 PM
  5. Timing~
    By Supar in forum C++ Programming
    Replies: 4
    Last Post: 01-18-2002, 05:55 PM

Tags for this Thread


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21