From: Joshua Blanton (jblanton@masaka.cs.ohiou.edu)
Date: 03/06/06
Date: Mon, 6 Mar 2006 09:57:14 -0500 From: Joshua Blanton <jblanton@masaka.cs.ohiou.edu> Subject: tcptrace-bugs [Fwd: Support for Large Trace Files] Message-ID: <20060306145714.GB10914@mauser.ipx.ath.cx>
This dude sent an email to tcptrace@, but wasn't subscribed - I no
longer remember how to authorize forwarding, but I thought that
somebody might want to take a stab at this. I actually think that
tcptrace handles large files assuming it's built correctly, but I
haven't looked into it - perhaps he's using windows, with a
non-largefile-supported binary?
--jtb
attached mail follows:
Subject: Support for Large Trace Files Date: Mon, 6 Mar 2006 09:39:59 -0500 Message-ID: <53A3844C59F7484E98EBD0F3E7AB565BE829B1@GORD14QBE01.mi.ds.army.mil> From: "Johnson, Scott CTR USA 513th \(GD\)" <james.s.johnson@us.army.mil>
Hi folks,
I was wondering if it would be possible to get some support for updating
tcptrace to support large trace files? It looks like there are 32 bit
operations in the source. As a user of tcptrace, I have seen large
trace files apparently get wrapped and a large portion of the tcptrace
output goes away. For example if I pass tcptrace a snoop created trace
of a 500 MB ftp, tcptrace does provide the output I expect. However, if
I pass the trace of a large ftp get, say a 2 - 5 GB file, then tcptrace
provides almost 0 output. To the user, it appears as if I wrapped a 32
bit counter.
I'm am not sure how many folks would find a need for this. I ran into
the problem when I was using Bruce Mah's pchar (based on VJ's pathchar)
to look at bottleneck links. I was trying to see what was occurring at
the bottleneck link but generally the file sizes being transferred
resulted in trace files that "blew out" tcptrace.
Regards,
Scott Johnson
This archive was generated by hypermail 2.1.7 : 03/06/06 EST