Sorry to be following up again, but I think it would
be helpful if I make a specific proposal wrt the
additional probes required, especially the tcp
close-related probes. I think adding the following
set of probes to the original proposal should hopefully
address shortcomings in this area in a manner
consistent with the connect-* and accept-* probes:
tcp:::close-request
Fires when a FIN segment is sent to a peer, either
as initiation of a graceful shutdown or in response
to a shutdown request from a peer.
tcp:::close-established
Fires when an ACK is received to a previously-sent
FIN segment. This probe firing may simply indicate
a half-close - i.e. the peer connection may not close
from it's side.
tcp:::close-accepted
Fires when a FIN segment is received from a peer.
If tcp:::close-accepted and tcp:::close-established
fire, the connection has shut down both sides but
may linger of course.
tcp:::reset-request
Fires when a RST segment is sent to a peer connection
to forcibly close (e.g. when we close and SO_LINGER is
set to 0). This is distinguished from a RST|ACK segment,
the sending of which is covered by the tcp:::accept-refused
probe.
tcp:::reset-accepted
Fires when a RST segment is received from a peer
connection.
With these probes in hand, we can ask questions like:
- how long do connections take to close down?
- which side initiated the close?
- how many half-closed connections are there?
- how many connections close gracefully? how many
close forcefully?
etc.
The naming of the probes is consistent with the
connect-* and accept-* probes, and like those
probes they supply the IP/TCP headers associated
with the control segment they represent. The
addition of these probes also means we have
coverage for all the connection control segments
(SYN, FIN, RST) and their related acknowledgments.
We should also add:
tcp:::socket-opened
Fires when a TCP socket is opened.
tcp:::socket-closed
Fires when a TCP socket is closed.
In addition to these, we also have the
tcp:::state-change probe which covers the
"closed" pseudo-state.
For UDP, as Darren suggests, it would be helpful
to have equivalents for the
accept-refused/connect-refused probes so that
users can detect cases where they attempt
to connect to nonexistent services. I think it
may make sense to stay away from
connect-refused/accept-refused for names as
these terms imply a connection, so I suggest
(the rather unwieldy):
udp:::port-unreachable-send
Fires when an ICMP port unreachable message
is sent in response to a UDP datagram heading
for a port with no UDP server. It is true that
an ICMP DTrace provider should cover this event,
but it might be helpful to have a probe point
within the UDP provider for such an event also.
udp:::port-unreachable-receive
Fires when an ICMP port unreachable message
is received in response to a UDP datagram.
Thanks!
Alan
On 01/04/2010 20:53, Alan Maguire wrote:
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]
