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

[Adam Dunkels]

Hi Kieran!

On Wednesday 23 January 2002 17.38, you wrote:
> 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:

Ok! Thanks for the explanation, now I get it :-)

The reason why tcp_ack() is called in tcp_recved() is that an ACK should be 
sent when the receiver's window is updated. In fact, calling tcp_ack() isn't 
really the right way to do it: instead, it should check if an ACK is 
scheduled for sending and if not, an ACK should be scheduled.

A short term workaround is to insert a call to tcp_output(pcb) in 
tcp_recved(), but perhaps the whole delayed ACK stuff should be reworked. The 
TF_ACK_NEXT flag could get a partner flag: TF_ACK_NOW which would be set when 
an ACK should be sent directly. tcp_output() would look at this flag to see 
if any ACK should be sent.

About your comment on the tcp_segs and starvation: I reworked the tcp_input.c 
functions so that they use a statically declared tcp_seg instead of 
dynamically allocating one. If the incoming segment has to be queued, a 
tcp_seg is dynamically allocated for it. (This is how it really should have 
been done from the start.) Thanks for your comment!

/adam
-- 
Adam Dunkels <address@hidden>
http://www.sics.se/~adam
[This message was sent through the lwip discussion list.]