Re: [lwip-users] Microblaze and lwIP

[Kieran Mansley]

On Tue, 2007-05-08 at 10:41 -0300, address@hidden wrote:
> I am not sure why this modification was necessary - are there any settings in 
> either lwipopts or Winsock that I could have changed to avoid this. I think 
> the 
> problem may lie more in the PC end - because in the original implementation 
> the 
> first segment was sent without PSH and the client then maybe waited for some 
> timeout period before realising nothing more was coming, then sent the ACK at 
> which time the host responded sending the second partial segment that was 
> marked PSH.

Can you explain what modification you made to the while loop in
tcp_output() ?  I'm guessing you allowed it to send the second segment
even if there was insufficient window space for it?  It is this change
that is most likely getting the results you need.  

You are correct that it is the windows end that is causing your problem.
Most TCP stacks have a "delayed ACK" policy.  i.e. In certain conditions
they won't send an ACK in the hope that the connection involves bi-
directional traffic and the ACK will be able to piggyback on a returning
data packet.  In your case there is no returning data packet, and so the
ACK isn't sent until a timer goes off after about 200ms.  However, the
stack should acknowledge at least every other packet.  This is why if
you modify lwIP to send both packets, they get ACKed immediately.  The
windows end has received two packets and so must send an ACK straight
away.

Unfortunately, this is just a property of TCP, rather than either lwIP
or windows having a bug.  I think linux has some clever stuff in it to
notice when the delayed ACK protocol would harm performance and so is
able to turn it off in cases like this.

To find out more, have a look through the TCP RFCs for "delayed ACK".
These are relatively well documented problems!

Kieran