Brendan Gregg - Sun Microsystems wrote:
G'Day Darren,
On Tue, Oct 10, 2006 at 03:21:40PM -0700, [EMAIL PROTECTED] wrote:
[...]
# ./tcpio2.d
LADDR:PORT RADDR:PORT BYTES FLAGS
192.168.1.185:79 <- 192.168.1.109:56145 0 (SYN)
192.168.1.185:79 -> 192.168.1.109:56145 0 (SYN|ACK)
192.168.1.185:79 <- 192.168.1.109:56145 0 (ACK)
192.168.1.185:79 <- 192.168.1.109:56145 2 (PUSH|ACK)
192.168.1.185:79 -> 192.168.1.109:56145 0 (ACK)
192.168.1.185:79 -> 192.168.1.109:56145 126 (PUSH|ACK)
192.168.1.185:79 <- 192.168.1.109:56145 0 (ACK)
192.168.1.185:79 -> 192.168.1.109:56145 0 (FIN|ACK)
192.168.1.185:79 <- 192.168.1.109:56145 0 (ACK)
192.168.1.185:79 <- 192.168.1.109:56145 0 (FIN|ACK)
192.168.1.185:79 -> 192.168.1.109:56145 0 (ACK)
Is this, by itself, a worthwhile goal of dtrace's TCP provider?
Why would I care to use dtrace for this when snoop/tcpdump does it?
Noone said it was a worthwhile goal. This output is from the CEC 2006
demonstration, and was used to demonstrate some of the capabilities of
the provider. Which it does nicely.
It demonstrates that one can acess IP and TCP information with the
rich programming functionality and low performance costs of DTrace.
No, it doesn't show why the provider trumps snoop - so perhaps
you are right, and I shouldn't copy-n-paste it as demonstration #1.
This was the point of my comment. Not that it can't be done,
just that it's not really an incredibly interesting thing to see.
Or to put it differently, I'd never use dtrace for this task and
I'd never suggest/recommend anyone use it for this task either.
In my mind it is (and will always be) the wrong tool for this
particular job.
Such a snoop like output is supposed to trigger the imagination for
what customisations and enhancements one can make with the DTrace
programming language.
Ahh....so when will dtrace take plugins for protocol descriptions? :)
...
And tcpaccept2.d aggregates inbound connections by hostname and
service name,
# ./tcpaccept2.d
dtrace: script './tcpaccept2.d' matched 1 probe
Tracing... Hit Ctrl-C to end.
^C
HOSTNAME PORT COUNT
marlin6 finger 1
bass login 2
marlin ssh 2
marlin telnet 2
marlin finger 3
I find this a more interesting demonstration of dtrace and TCP.
Can you tell me the average lifespan of each connection?
And that per-host?
Great idea (and it rings a bell - customers have asked me this before)
- I've added it to the website (actual screenshots),
...
What about for http, can you tell me the number of connections
my web server gets for each host, on average how long each one
takes (from accept to close) and the average number of bytes
sent by TCP?
Yes - I should add a bytes column to tcplifespan2.d. :)
These are good questions - customers have asked me for such metrics
before, and they are the exact type of questions that the provider
will answer best.
:-)
I think if you can work from here and start answering other things,
like average number of dup-ACK's per TCP connection for each host,
etc. These things are very hard to do with tcpdump/snoop (you'll
need to add some perl in there.) There is a whole host of questions
around here that we might have wanted to ask in the past but for
which we could never get an easy answer.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
