SUMMARY:
The bad network behavior was due to shared irqs somehow screwing
things up. This explained most but not all of the problems.
DETAILS:
Many people emailed me that they were experiencing similar problems.
Even though the cause of my problem is not kernel related, I'm hoping
my narrative
In order to figure out what this problem is I'm going to add some
printk statements in the networking code on the client machine.
Hopefully, this will show me what's going on. My goal is to trace the
receipt of the datagram by tcp, see why/how it's deciding to ack or
not ack, and then trace the s
First a little more data on the problem.
1) I've never seen it with the client and server program on the same
computer.
2) It only repros on some systems. If I can repro it on some systems
and then make the client the server and the server the client the
bug will often fail to repro.
A couple people have requested a test case.
The problem first showed up in a very large java app. Since then I
wrote a small perl program to duplicate the behavior of the large app
by sending the same data, in the same order, in the same sized blocks,
from the server to the client.
If you want
On 13 Jun 2001, Andi Kleen wrote:
> The packet likely doesn't fit into the socket buffer and is silently
> dropped. The TCP stack doesn't force an ACK in this case, but it
> probably should, although it wouldn't solve the deadlock. The deadlock
> will be only solved if the local application reads
I have a client server program that opens a tcp connection between two
machines. Everything is fine until a certain type of data is sent
across the socket at which point the client refuses to ACK and the
server continues to resend the packets to no avail.
I've verified that the client is blockin
6 matches
Mail list logo
