> My thought was to inexpensively perform something like
> tvb_add_to_composite(composite, position, tvb, offset, len)
> This would cause composite to reference tvb, thus tvb would stay around
> until composite was deallocated.
The tvbuff may stay around, but that doesn't guarantee that the data to
which it refers stays around!
The initial tvbuff for a frame is created by "dissect_packet()", which
creates a new REAL tvbuff using the raw-data pointer it was handed.
"dissect_packet()" is called from "epan_dissect_new()".
On the first pass through the capture file, "epan_dissect_new()" is
passed a pointer to the buffer into which Wiretap read the packet; that
is currently a buffer attached to a "wtap" structure for an open capture
file.
The *buffer* stays around when a new packet is read - but its contents
are overwritten with the contents of the next packet, so, whilst the
tvbuff may stay around, it no longer points to what it pointed to when
it was created!
> At least all g_malloc()+memcpy() would be eliminated.
They might be eliminated - but the consequence of that would be that the
tvbuffs won't point to the right data! The reason why the "g_malloc()"
and "memcpy()" are done is that the data you get from Wiretap does *not*
stay around when a new packet is read, so you *have* to make a copy of
it.
You could only eliminate the "memcpy()" if you instead arranged that a
new buffer be allocated for *every* packet you read in, and that Wiretap
read into that buffer; that gets rid of the "memcpy()", but it doesn't
get rid of the memory allocation for the buffer.
> > An application to map *ALL* segments in a TCP sequence into a COMPOSITE
> > tvbuff will, no matter *HOW* you do it, require that all those segments
> > fit into memory. I have little doubt that there are capture files on
> > which that will fail even if you *don't* create a single contiguous
> > buffer containing all of them - capture files that currently *can* be
> > read by ethereal.
>
> Yes, all referenced tvbuffs as well as the real_data buffers for them will
> effectivly be locked into memory until the composite is freed.
Which means that TCP reassembly that reassembles the *entire* TCP stream
into a *single* tvbuff is unacceptable; at one point, we got an
11-megabyte capture file that consisted of *one* TCP connection, and I
could imagine that there might be considerably larger captures like
that.
Besides, I don't *want* to see the entire client side, or the entire
server side, of a connection when I click on the last TCP segment in the
capture; I want to see *only* the higher-level PDUs the last of whose
data either arrived in that segment or the last of whose data followed
that segment in the data stream - i.e., the higher-level PDUs that were
finally completely available to the protocol when that segment arrived.