|
From: | Atte Kojo |
Subject: | Re: [lwip-users] TCP performance in receiving |
Date: | Fri, 08 Oct 2004 13:35:07 +0300 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040927 |
K.J. Mansley wrote:
I thought that the stack should, if asked to send an ACK when one has already been delayed, send a dedicated packet out at that point. i.e.There should only be one outstanding delayed acknowledgement at once. This would mean that if as in your case the stack is only receivingdata, it would send ACKs for every other packet, rather than wait 250ms as you report. The implementation of tcp_ack() backs this up: #define tcp_ack(pcb) if((pcb)->flags & TF_ACK_DELAY) { \ (pcb)->flags &= ~TF_ACK_DELAY; \ (pcb)->flags |= TF_ACK_NOW; \ tcp_output(pcb); \ } else { \ (pcb)->flags |= TF_ACK_DELAY; \ } If the TF_ACK_DELAY flag is already set, it is cleared, and TF_ACK_NOW set instead. The call to tcp_output() should then dispatch the acknowledgement straight away. However, as this doesn't match what you are seeing, there might be something wrong. I'm not sure what though.
This is because tcp_recved() only does an ack if there are no acks pending (delayed or otherwise):
if (!(pcb->flags & TF_ACK_DELAY) && !(pcb->flags & TF_ACK_NOW)) { /* ... comment deleted ... */ tcp_ack(pcb); }This effectively nullifies the tests in tcp_ack() in this case. I resolved this problem (probably not very cleanly) by adding an extra else to above test that sends out an ack if there is already a TF_ACK_DELAY pending on the pcb and the receive window is big enough.
I had the same problem when doing an application that only receives a huge amount of data without sending out anything.
- Atte -- GARLIC GUM IS NOT FUNNY GARLIC GUM IS NOT FUNNY GARLIC GUM IS NOT FUNNY GARLIC GUM IS NOT FUNNY Bart Simpson on chalkboard in episode 7G13
[Prev in Thread] | Current Thread | [Next in Thread] |