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

[Kieran Mansley]

Adam wrote:
> Does this sound anything like your situation?

Well, in symptom, yes, but not in cause.

I'm reasonably sure the recv function isn't returning an error (I'm using
the sockets API, so this is all internal to the stack, btw).  The reason
for it not sending the ACK is as described:

As a result of receiving the packet, tcp_ack() is called, but it just sets
a flag rather than actually enqueueing an ack, so when tcp_output()  is
called after recv() returns, there is nothing to send.  This wouldn't
normally matter too much to most people, as pretty soon the fast timer
will go off and send this delayed ack, but before this happens
tcp_recved() is called (presumably from do_recv()), which calls tcp_ack()
again. This has the effect of enqueuing an ack (but not calling
tcp_output()) and clearing the flag and so the fast timer routine does
nothing.  Therefore an ack gets enqueued, but not sent until the slow
timer goes off.  I think.  It's a bit difficult to describe in words, but
I could mail a trace of the debugging output showing the sequence of
events if you'd like.

The behaviour I'd like, is for the ack to be enqueued the first time, so
when tcp_output() is called after the recv() it gets sent then.  I'm not
sure why the data needs to be acked twice (in tcp_process() and in
tcp_recved()).

Cheers

Kieran


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