> according to a Wireshark trace, it drives things so hard that Wireshark > detects a TCP Window Full condition. Consequently, a few seconds after that > condition is recognized we see a RST packet from the Windows side that > closes the connection.
The TCP window full is quite normal. > I noticed that the code was setting the TCP_NODELAY option which disables > "Nagling" which I don't think is a good thing in this environment. However, > even after I got rid of it we'd still get the same condition. NODELAY shouldn't really be set except for specialist latency sensitive cases or apps that are doing their own framing management very carefully. > Two questions: > > 1. Why isn't the write blocked to allow the congestion to resolve? It is. The window indicates how much data may be sent at this point. When it hits zero its asserting a flow control stop. > 2. How is Wireshark able to detect the condition but the application gets no > indication that things are bad or that the TCP stack tries to resolve the > situation? The RST from the windows size sounds like the windows client is using some kind of timeout mechanism in the client app and it forcibly closed the link. You'd need to look at the trace in more detail and match it with app syscall traces on the client. Alan ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
