aboutsummaryrefslogtreecommitdiffstats
path: root/packet-range.c
AgeCommit message (Collapse)AuthorFilesLines
2011-04-27Create a new frame_data_sequence data type; it represents a denseguy1-5/+5
sequence of frame_data structures, indexed by the frame number. Extract the relevant bits of the capture_file data structure and move them to the frame_data_sequence, and move the relevant code from cfile.c and tweak it to handle frame_data_sequence structures. Have a possibly-null pointer to a frame_data_sequence structure in the capture_file structure; if it's null, we aren't keeping a sequence of frame_data structures (we don't keep that sequence when we're doing one-pass processing in TShark). Nothing in libwireshark should care about a capture_file structure; get rid of some unnecessary includes of cfile.h. git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@36881 f5534014-38df-0310-8fa8-9805f1628bb7
2011-04-26Short-term hack to fix bug 5855 - don't try to process all theguy1-145/+162
frame_data structures for all the packets if we don't actually *have* any frame_data structures for any packets, e.g. in TShark in one-pass mode. Also: Use #if 0/#endif instead of commenting out. Consistently use 4-space indentation. git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@36879 f5534014-38df-0310-8fa8-9805f1628bb7
2011-04-25Store the frame_data structures in a tree, rather than a linked list. guy1-23/+21
This lets us get rid of the per-frame_data-structure prev and next pointers, saving memory (at least according to Activity Monitor's report of the virtual address space size on my Snow Leopard machine, it's a noticeable saving), and lets us look up frame_data structures by frame number in O(log2(number of frames)) time rather than O(number of frames) time. It seems to take more CPU time when reading in the file, but seems to go from "finished reading in all the packets" to "displaying the packets" faster and seems to free up the frame_data structures faster when closing the file. It *is* doing more copying, currently, as we now don't allocate the frame_data structure until after the packet has passed the read filter, so that might account for the additional CPU time. (Oh, and, for what it's worth, on an LP64 platform, a frame_data structure is exactly 128 bytes long. However, there's more stuff to remove, so the power-of-2 size is not guaranteed to remain, and it's not a power-of-2 size on an ILP32 platform.) It also means we don't need GLib 2.10 or later for the two-pass mode in TShark. It also means some code in the TCP dissector that was checking pinfo->fd->next to see if it's NULL, in order to see if this is the last packet in the file, no longer works, but that wasn't guaranteed to work anyway: we might be doing a one-pass read through the capture in TShark; we might be dissecting the frame while we're reading in the packets for the first time in Wireshark; we might be doing a live capture in Wireshark; in which case packets might be prematurely considered "the last packet". #if 0 the no-longer-working tests, pending figuring out a better way of doing it. git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@36849 f5534014-38df-0310-8fa8-9805f1628bb7
2010-01-26Introduce "Remove Ignored packets" in Packet Range frames, which is used instig1-1/+42
Save As, Export and Print dialogs. git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@31680 f5534014-38df-0310-8fa8-9805f1628bb7
2009-09-21Rename capture_file.plist to capture_file.plist_start to make it consistent ↵krj1-8/+8
with capture_file.plist_end git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@30047 f5534014-38df-0310-8fa8-9805f1628bb7
2009-08-26(FWIW) One step towards including stdio.h & stdlib.h only when req'd.wmeier1-0/+1
git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@29568 f5534014-38df-0310-8fa8-9805f1628bb7
2006-05-21name changesahlberg1-2/+2
git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@18197 f5534014-38df-0310-8fa8-9805f1628bb7
2005-08-14Some 'no previous declararion' warning fixesjmayer1-1/+1
git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@15355 f5534014-38df-0310-8fa8-9805f1628bb7
2004-10-16Remove the fixed maximum number of subranges in a range_t; dynamicallyguy1-6/+29
allocate them to be large enough. Add checks that the numbers in the range fit in a guint32. Check the validity of a range before saving or printing, and report errors in an alert box. Clean up white space. git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@12320 f5534014-38df-0310-8fa8-9805f1628bb7
2004-10-16Make the nranges member of a range_t be the number of ranges, not theguy1-0/+1
number of ranges - 1, and update loops that iterate over all the ranges appropriately. Make "range_convert_str()" return a success/failure indication, and check it. Rewrite it to do more checks, and not to blithely ignore unknown characters. git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@12313 f5534014-38df-0310-8fa8-9805f1628bb7
2004-09-04The packet range stuff knows about capture_file structures, so it'sguy1-0/+253
really more of an Ethereal/Tethereal component than a libethereal component (nothing else in libethereal knows about capture files); move it back out of libethereal. (The range stuff doesn't; we leave it in libethereal.) git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@11898 f5534014-38df-0310-8fa8-9805f1628bb7