Question

I’m trying to learn UDP, and make a simple file transferring server and client.
I know TCP would potentially be better, because it has some reliability built in. However I would like to implement some basic reliability code myself.

I’ve decided to try and identify when packets are lost, and resend them.

What I’ve implemented is a system where the server will send the client a certain file in 10 byte chunks. After it sends each chunk, it waits for an acknowledgement. If it doesn’t receive one in a few seconds time, it sends the chunk again.

My question is how can a file transfer like this be done quickly? If you send a file, and lets say theirs 25% chance a packet could be lost, then there will be a lot of time built up waiting for the ACK.

Is there some way around this? Or is it accepted that with high packet loss, it will take a very long time? Whats an accepted time-out value for the acknowledgement?

Thanks!

Answer 1

There are many questions in your post, I will try to address some. The main thing is to benchmark and find the bottleneck. What is the slowest operation?

I can tell you now that the bottleneck in your approach is waiting for an ACK after each chunk. Instead of acknowledging chunks, you want to acknowledge sequences. The second biggest problem is the ridiculously small chunk. At that size there’s more overhead than actual data (look up the header sizes for IP and UDP).

In conclusion:

What I’ve implemented is a system where the server will send the
client a certain file in 10 byte chunks.

You might want to try a few hundred bytes chunks.

After it sends each chunk, it waits for an acknowledgement.

Send more chunks before requiring an acknowledgement, and label them. There is more than one way:

• Instead of acknowledging chunks, acknowledge data: “I’ve received
  5000 bytes” (TCP, traditional)
• Acknowledge multiple chunks in one message. “I’ve received chunks 1, 5, 7, 9” (TCP with SACK)