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.
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.
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?
Given this, it would be appreciated if some text
mentioned whether the above are actually aliases
or not.
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 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.
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"?
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?
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?
No comments are provided about udps_addr or tcps_addr.
Is their behaviour the same as cs_addr - NULL?
Darren
_______________________________________________
opensolaris-arc mailing list
[email protected]
