lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Adam Dunkels
Subject: [lwip-users] Re: [lwip] tcp_ack query
Date: Wed, 08 Jan 2003 22:23:29 -0000

Hi Kieran!

On Wednesday 16 January 2002 18.07, you wrote:
> I've been seeing some less than optimal behaviour of ACKs when there is
> data going in one direction only, and having had a look at the code I'm a
> little unsure about whether or not they're being sent in a sensible way.

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_input() calls tcp_process() to do the TCP state transitions. 
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.

I'll keep looking at the code to see if I find anything and get back if 
(when) I do.

> Another related problem is the receipt of ACKs!  If one machine has used
> up all the tcp segments available from the memp (ie. there are a few
> packets in flight and it's waiting for an ACK before sending some more)
> then when the ACK arrives it is dropped because there are no more
> available segments.  This means the whole thing grinds to a halt.  I can
> easily avoid this by ensuring MEMP_NUM_TCP_SEG is defined to be larger,
> but it took me a long time to work out what was going on!  I don't think
> there's anything wrong with the code (although I find dropping acks just
> because you've got a lot of outgoing traffic a little unsettling - maybe
> memory for incoming segments and outgoing segments should be done
> separately so one direction doesn't starve the other), just that I'd
> chosen duff values in lwipopts.h.  Perhaps what I'm suggesting here is to
> have the constraints and relationships between the MEMP_* constants
> documented in the same way as TCP_SND_QUEUELEN is.  Just a thought anyway.

You are right - ACKs should *not* be dropped when the TCP queues are full 
with segments. Perhaps a new MEMP type should be added, MEMP_TCP_ACK, that 
shoyld be used for pure ACKs. It could also be used when sending pure ACKs, I 
guess. I'll have to ponder this some more...

/adam
-- 
Adam Dunkels <address@hidden>
http://www.sics.se/~adam

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]