Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > Software - Troubleshooting and Discussion > Developer Center > TCP Question

TCP Question
Thread Tools
Ghoser777
Professional Poster
Join Date: Dec 2000
Location: Chicago, Illinois
Status: Offline
Reply With Quote
Mar 25, 2006, 03:11 PM
 
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
Mac Elite
Join Date: Sep 2000
Location: in front of the keyboard
Status: Offline
Reply With Quote
Mar 25, 2006, 05:40 PM
 
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?
signatures are a waste of bandwidth
especially ones with political tripe in them.
     
Ghoser777  (op)
Professional Poster
Join Date: Dec 2000
Location: Chicago, Illinois
Status: Offline
Reply With Quote
Mar 25, 2006, 07:32 PM
 
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
Mac Elite
Join Date: Sep 2000
Location: in front of the keyboard
Status: Offline
Reply With Quote
Mar 28, 2006, 11:22 PM
 
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.
signatures are a waste of bandwidth
especially ones with political tripe in them.
     
   
Thread Tools
 
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Top
Privacy Policy
All times are GMT -4. The time now is 06:25 PM.
All contents of these forums © 1995-2017 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.8 © 2000-2017, Jelsoft Enterprises Ltd.,