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? > Is there a reason why we don't have "tcp:::closed"? I'm sure Alan can address that. > 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. Adam -- Adam Leventhal, Fishworks http://blogs.sun.com/ahl _______________________________________________ opensolaris-arc mailing list [email protected]
