[Ghoser777]

This is more of a general networking question, but I don't think anyone in the Network forum would be able to help with this. I'm implementing some basic TCP functionality over UDP for my grad program, but I'm running into a problem when the following happens:

A) My window size gets large (say 100)
B) My receiver drops about 20 packets for whatever reason (network congestion, over running the receiver, etc)

So when that happens, I expect my program to deal with the situation gracefully... but it does not. The dilemma is this: If I send packets 1-100, and the receiver gets packets 1-80, it will ACK 1-80, causing my sender to also send packets 101-180. Now my sender is going to receive 80/3 = 26 duplicate ACK messages requesting packet 81. So my sender will then send packet 81 26 times to the receiver, causing the receiver to send the receiver to send 25/3 = 8 duplicate ACK messages asking for packet 80. As you hopefully can tell, by packet 85 or so, the receiver actually won't be generating any more duplicate ACKs.

Now my program doesn't stop running - instead, my sender starts having transmission time outs for the sent packets and resends packets 85-100. The problem is, the timeout interval doubles each time, and so it can take a really really long time to retransmit those packets.

There seems to be something really wrong here... does anyone see the flaw or something I'm overlooking?

[Kristoff]

I am confused about what you are really doing.

You are saying that you are trying to implement TCP but you are using UDP as the underlying transport?

So, you are just sending UDP datagrams, and then your program itself is going to worry about delivery guarantee? In other words, your app is doing flow control and error correction?

If that's the case, then why are you asking us? It's your code. :-P

Am I missing something?

[Ghoser777]

LOL. Yes, you've got everything correctly.

What I'm confused about is how a tcp implementation should deal with losing consecutive packets. I've found when the receiver has a large gap in reception, the way that I understand tcp handles flow/congestion control doesn't provide a good solution for the problem. Because I know every tcp implementation I've ever used work well:

1) Has that problem never occurred before? or (more likely)
2) What the hell are they doing that avoids/fixes the problem I'm encountering.

[Kristoff]

sorry, can't really help you without looking at the code.

Conceptually, you are responsible for the error correction and flow control (as we decided above) so you need to make sure that you have a sound method for tracking acks and a good falloff algorithm so that you're not constantly re-requesting packets due to overwhelming congestion.