Hi all, In looking at a trace, I see that TCP sends an ACK for every incoming segment, never piggy-backing the acknowledgment despite the existence of 2 way traffic. I see that this is due to the function tcp_recved(), specifically its logic which sends an immediate ACK if one is pending and the newly updated rcv_win is above a threshold. The comment indicates that this is an attempt to refrain from sending an ACK for each window update. However, it appears that the only way an ACK WILL NOT be sent is if the application reads data significantly slower than the incoming segment arrival rate such that a call to tcv_recved() finds rcv_wnd under the threshold, even after being updated. As this is not the case in my application, every incoming segment results in an outgoing ACK-only segment. It seems to me that the logic should take into account the amount of accumulated window updates pending communication to the peer, in order to strike a balance between minimizing ACKs and not stalling the peer. If I understand the spirit of the comment, the idea would be to send an ACK only when the amount by which the window has opened since the last ACK reaches some threshold (MSS, fraction of window, etc.). That is, the amount of unadvertised window has grown "significantly" since we last sent an ACK. To test this, I added a new receive variable, rcv_wnd_owed, which is incremented in tcv_recved() and reset to zero each time an ACK is sent. I changed the threshold comparison in tcp_rcved() to use this variable instead of rcv_wnd, thereby using the unadvertised window as the threshold criterion.This works well for me, but maybe I've only solved my scenario: slow GSM link with bidirectional traffic. From the mail list archives, it appears that this was added for the scenario of unidirectional reception over Ethernet, but I think my change would be applicable, apart from possible tuning of the threshold. I'd welcome comments, as I may have misunderstood the intent of this logic. Should my changes be of interest, I'll post a patch. Tim Butler _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
