[lwip-users] Re: [lwip] ACK query

[Kieran Mansley]

> The delayed ACK should be sent out the second time tcp_ack() is
> invoked.  I have been scanning through the code, but haven't really
> found why tcp_output() isn't called in this case.
>
> When a TCP segment is received, tcp_input() is invoked by ip_input().
> tcp_receive() is called by tcp_process() to enqueue the incoming data
> and dequeue any ACKed data. tcp_ack() is called in tcp_process().
>
> When tcp_process() returns to tcp_input(), the registered recv()
> callback is called. If this function returns an ERR_OK (i.e., no
> error), tcp_output() should be called. If tcp_ack() had enqueued an
> ACK, it should be sent now.

That sounds ok.  The pattern that I see is pretty much what you
describe - something like this...

(this is all from memory btw - I can't check it at the moment, so there
might be an error in my reasoning).

tcp_input, tcp_receive, tcp_process get invoked.  tcp_ack is called at
this point as you say, but this is the case where it just sets a flag, it
doesn't actually enqueue anything.  tcp_process returns to tcp_input and
recv()  is called as you describe.  tcp_output is then called, but
critically, as tcp_ack has only been called once so far, no ACK has yet
been enqueued (just the TF_ACK_NEXT flag has been set), and tcp_output
has nothing to send.

Then, before the fast timer goes off, tcp_recved() is called, and it calls
tcp_ack().  This is the second case that I described, so it now enqueues
an ACK using tcp_send_ctrl, and clears the flag, but doesn't call
tcp_output.

The fast timer then goes off, and checks the TF_ACK_NEXT flag, but this
has just been cleared, so it doesn't call tcp_output() either.

Now we have an ACK enqueued, but it's not going anywhere fast!

Kieran

[This message was sent through the lwip discussion list.]