Re: [lwip-users] TCP performance in receiving

[Wei Bo-Er \(Jason\)]

Hi all,

  if (!(pcb->flags & TF_ACK_DELAY) &&
     !(pcb->flags & TF_ACK_NOW)) {
    /*
     * We send an ACK here (if one is not already pending, hence
     * the above tests) as tcp_recved() implies that the application
     * has processed some data, and so we can open the receiver's
     * window to allow more to be transmitted.  This could result in
     * two ACKs being sent for each received packet in some limited cases
     * (where the application is only receiving data, and is slow to
     * process it) but it is necessary to guarantee that the sender can
     * continue to transmit.
     */
    tcp_ack(pcb);
  } else if (pcb->flags & TF_ACK_DELAY && pcb->rcv_wnd == TCP_WND) {
    tcp_ack_now(pcb);
  }

This way a duplicate ack is sent only when the senders window is empty.
I can't tell how it behaves with small chunks of continuous data, but
with bursts of large chunks it works pretty well. Someone with a
different kind of an environment might like to test it also.
                                                                               

I don't know why Atte's approach or other method which sends ack directly as TF_ACK_DELAY  flag is set

will increase duplicate acks. Since TF_ACK_DELY is set means there must be some acks pending and

tcp_output will always clear flags of  TF_ACK_DELY &TF_ACK_NOW after sending out an ack, duplicate acks

would be sent only as TF_ACK_DELY &TF_ACK_NOW is not set. Of coures,there may be some other reason

 I missed will increase duplicate acks.

 

 

Regards,

 

Bo-Er