xthread: (Default)
[personal profile] xthread
Practical networking question -
Posit a server and a client. The client is running a set of clients of the server, essentially performance testing the server. In their infinite wisdom, the clients and servers believe that the appropriate way to close TCP sessions is send TCP RSTs in response to the first TCP FIN they get from the other side. Charming, I know. Anyway, netstat is reporting the window size being ratcheted down to zero on a lot of the sessions between the client and server, which is making me wonder if the RSTs are somehow leading to wonky buffer behavior on the other sessions between the two talkers. (I know, this is not an adequately formulated idea, I'm thinking the behavior through, thought I'd see if anyone else had seen something specific, like known reporting behavior of netstat or yeah, the kernel tries to be helpful like that)

On an entirely unrelated note, the correct way to close a TCP session is not to send a RST. That will abort the session, but that's the whole point: it will abort it, and it is expected that the other side will do whatever cleanup it does of an abnormally terminated session. It's like ending all phone conversations with just hanging up on the other party: sure, it works, but it's not good practice.

Date: 2010-05-22 01:32 am (UTC)
From: [identity profile] xthread.livejournal.com
Yeah, I thought of that.
BEA WebLogic on Solaris, actually. From what I've seen in the wireshark data, I'm convinced that the application level is borked on both the client side and server side, just in their own unique ways.

Date: 2010-05-22 01:40 am (UTC)
From: [identity profile] docstrange.livejournal.com
Weird. I know Windows did that as a way to preserve resources against slow closing sessions. Borked a lot of proxy firewalls when it first was rolled out in 1999 or 2000 (don't remember). I imagine the idea is similar with WebLogic, which I last used in 2002, so I can't really say. It is perhaps configurable?

Date: 2010-05-22 01:50 am (UTC)
From: [identity profile] xthread.livejournal.com
Almost certainly. Not in my control at all, I'm just trying to describe the problem in sufficient detail in the writeup that the people who do control the resources can track the problem down.

Profile

xthread: (Default)
xthread

July 2014

S M T W T F S
  12345
6789101112
13141516171819
20212223242526
27282930 31  

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 23rd, 2025 11:37 pm
Powered by Dreamwidth Studios