Folks-
Many thanks for the replies, here are my responses:
From: Stephen Fisher <steve@xxxxxxxxxxxxxxxxxx>
On Thu, Oct 21, 2010 at 03:29:36PM -0500, Craig Votava wrote:
I wrote a Perl script that feeds pcap data to an instance of tshark
running in a child process, then takes the decoded output to present
to the user.
The problem is that I don't know when tshark is done sending output
back to me.
How about using "pdml" or "psml" with the -T option.
Stephen: Thanks for the suggestion! I actually played around with
these a bit, and although it would work, I decided not to use it for
performance reasons.
My tool is a real-time GUI for analyzing trace output. When the user
clicks on a message, I want a selected portion of the ASCII tshark
output (the meat of the message without the IP headers) slapped up in
a window quickly. When I used pdml, it increased the lag time in
getting the data up for the user. I'm guessing because it's more CPU
intensive to have tshark format the data and then for my program to
unformat it. The difference wasn't much, but it was noticeable, and
annoying.
...especially given that the default ("-T text") output of TShark is
designed for humans, not programs, to read. If your program can
read it, great, but if it's easier for it to read PSML or PDML....
Since the end result is to be displayed for humans, I'm hoping I can
avoid the additional pdml->ascii iteration. It seems to me that a new
tshark option to help me avoid this is a reasonable compromise. What
are your thoughts?
From: Mark Landriscina <mlandri1@xxxxxxx>
Using -T with pdml/psml would probably be the best approach if you
want text output. However, if that doesn't work for you, then you
could consider doing what some programs like SCAPY do. Save your
packets in a temp pcap file and pass the file name to your tshark
child process when you are spawning it.
Mark: Another good suggestion as well. This was how my first version
was written, however the delay time for quickly slapping the output
into the window for the user was too much. By holding a single tshark
co-process up and running all the time, I get a very fast turnaround
from supplying input and getting output. This really works well,
except for knowing when to stop reading.
Since my first post, I've discovered a bunch of techniques for doing
non-blocking reads on Windows. All of them seem more complicated to
me, than just having tshark add an end-of-decoding indication to the
ASCII output. Thoughts?
Thanks
-Craig