Thread: 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

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.

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...

Yea thanks I will definitly try that

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.

Originally Posted by FusionFox

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.