Apologies, I misstated something below....
On 01/04/2010 18:30, Alan Maguire wrote:
On 01/04/2010 08:33, Darren Reed wrote:
On 03/31/10 22:49, Adam Leventhal wrote:
Darren,
I'm not sure that enough detail is provided for
this to be "automatic" and there is also the problem
of the missing UDP probes... see below.
If you scroll down, you'll find the udp provider probes listed.
If we do simple trackng of accept-established and
connect-established, we're able to count how many
active connections there are but to properly adjust
the counter when things close requires tracking
state-change and understanding enough of TCP
to know how to adjust your stats correctly.
True. With respect to tcp close issues, I guess there's
a few ways to handle close events:
1. a socket-oriented close probe "tcp:::socket-close" (and
for consistency tcp:::socket-open). Adding these seems
reasonable to me, especially given the fact that it would
be consistent with the udp provider, as you note below.
2. a close probe in the style of the connect-* and
accept-* probes - "tcp:::connection-closed" perhaps?
This could fire when tcp reaches the fictional
closed state for one of the following reasons:
- when the TIME_WAIT timeout on a closing connection
has expired
- when we receive the LAST_ACK for a passive close
- when we time out in SYN_SENT state
- when we send or receive a RST segment aborting
the connection, or we receive a RST|ACK.
3. a state-change probe for the closed state
(tcp:::state-change where the new state argument is
"state-closed"). This was discussed a while back, and the
consensus was not to use the closed state since it is described
as fictional in RFC793. Jim describes this here:
http://mail.opensolaris.org/pipermail/dtrace-discuss/2006-September/002456.html
So my proposal would be to add 1 and 2 above to the
provider specification. Does this seem reasonable?
Actually, we already have 3 - tcp:::state-change where
the new state is "state-closed". Apologies for the confusion -
I was writing from memory. So the question is if we should
add 1 and 2 I guess.
Alan
_______________________________________________
opensolaris-arc mailing list
[email protected]
