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?
Futher to this, if I look at tcp:::connect-request
and tcp:::state-change, is that enough or do I also
need the other tcp:::connect's to detect when a
connection request is refused? The state of the
TCP socket should go from SYN-SENT to
CLOSED for connect-refused. Similarly,
connect-established should just be a alias for
the transition of SYN-SENT to ESTABLISHED
and accept-established a change from
SYN-RECEIVED to ESTABLISHED.
I'll flesh out the details in the provider specification
a bit more. Is the following is what you're looking
for?
tcp:::connect-request
Fires when the initial SYN is sent as a result of
a connect(3SOCKET). The state then changes to SYN_SENT.
tcp:::connect-refused
Fires when a RST|ACK connection refusal is received
in response to a SYN segment.
tcp:::connect-established
Fires when the final ACK in the three-way handshake has
been sent - the state then changes from SYN_SENT to ESTABLISHED.
tcp:::accept-established
Fires when the final ack in the three-way handshake has
been received - the state then changes from SYN_RCVD to ESTABLISHED.
tcp:::accept-refused
Fires when sending a RST|ACK connection refusal.
Is that all correct? Will a dtrace script that
gathers connect-established and state-change
have both of those probes activated for the
same event?
Yes.
Given this, it would be appreciated if some text
mentioned whether the above are actually aliases
or not.
Sure. The rationale isn't quite that they are
aliases - the connect-* and accept-* probes
are oriented towards representing not just
the internal TCP state as it changes, but also
the TCP segments we send or receive that drive
those changes. More concretely, for the tcp:::state-change
probes, the ipinfo_t * and tcpinfo_t * (representing
IP and TCP headers associated with the probe
event) are NULL, whereas for the tcp:::connect-*
and tcp:::accept-* probes they point at the IP and
TCP headers associated with the event.
With all of those state-change aliases available
on the connect side, I'm curious about why the
close side has been ignored.
It sounds like you're raising an issue of documentation and you have a question
about how a specific query would be phrased. Is that accurate?
Yes. More information is required about how the state-change
probe relates to all of the other TCP probes that involve state
changes of the socket.
Is the above description sufficient? If so, I'll update
the provider specification accordingly.
Is there a reason why we don't have "tcp:::closed"?
I'm sure Alan can address that.
I suppose that answer should also address where there is no
tcp:::socket-open and tcp:::socket-closed.
See above.
Furthermore, whilst the case is titled "DTrace
TCP and UDP providers", I only see TCP ones
presented but an example with UDP. The materials
need to be updated to specify which UDP ones are
being introduced.
Again, I think a thorough reading of the case will reveal that that information
was indeed included.
Ah, they just weren't where I expected them to be.
Apologies.
Was there any consideration given to supporting both
"udp:::connect-request" and "udp:::connect-refused"?
Hmm, it's a good idea but I'm not sure if we should have
connect-request as a probe point in UDP. It would definitely
be useful to have a probe point for when we issue or receive
ICMP port unreachable errors - perhaps we should stay
away from the "connect-" terminology though, since UDP
is a connectionless protocol. Maybe
udp:::port-unreachable-send
udp:::port-unreachable-receive
?
It seems that the architecture being presented is that the UDP
probes fit around UDP sockets (socket-open & socket-closed)
whereas TCP probes fit around something else - presumably
TCP connections?
That was true, but I think you've raised some good points
that move us to a more consistent architecture across
providers.
This case updates csinfo_t but makes no mention of what
the role of cs_addr is... is it safe to assume it is still NULL?
Apologies - I should have specified that cs_addr is a pointer
to the ip_xmit_attr_t which we translated into a csinfo_t.
No comments are provided about udps_addr or tcps_addr.
Is their behaviour the same as cs_addr - NULL?
These will be pointers to the udp_t and tcp_t used to translate
into the udpinfo_t/tcpinfo_t.
Thanks!
Alan
_______________________________________________
opensolaris-arc mailing list
[email protected]
