[Top][All Lists]
[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.]
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lwip-users] Re: [lwip] tcp_ack query,
Adam Dunkels <=