On Fri, Jun 15, 2001 at 04:28:21PM +1000, Ronnie Sahlberg wrote:
> tvb_get_ptr() is not really compatible with COMPOSITEs since the current use
> of this function
> will guarantee that each and every COMPOSITE will be g_malloc() and memcpy()
> to a backing buffer and turned into
> a normal REAL_DATA tvbuff.
No.
That needs to happen only if the item being accessed by "tvb_get_ptr()"
crosses a tvbuff boundary; if that's not what happens now, that's just a
bug.
(Note also that "tvb_get_ptr()" is, in effect, just a wrapper around
"ensure_contiguous()", and that's the routine that calls
"composite_ensure_contiguous()", which is the routine that, *if*
"check_offset_length_no_exception()" returns "false", makes a contiguous
copy. Unless you plan to change the *other* routines that use it,
merely eliminating "tvb_get_ptr()" won't be sufficient.)
> The ugliness with the current IP reassembly is that it does a lot of
> g_malloc() and memcpy(). By using a COMPOSITE
> for the reassembled packet, all these g_malloc() and memcpy() are
> eliminated.
Other than, of course, the "g_malloc()" after the
/* If we have reached this point, the packet is not defragmented yet.
* Save all payload in a buffer until we can defragment.
* XXX - what if we didn't capture the entire fragment due
* to a too-short snapshot length?
*/
comment in "fragment_add()", as you have to have the data for *all*
fragments in a given fragmented IP datagram available when *any* frame
containing a fragment from that datagram is accessed; the only
alternative would be to read the data for that frame from the capture
file, but that might make random access to the capture file sufficiently
common that the fact that random access to frames *before* the current
frame is currently *extremely* expensive on compressed files a
significant problem.
(There are, I think, ways of making it sufficiently inexpensive,
involving replacing zlib with, say, modified zlib or gunzip code that
works similarly to the way the compressed-Sniffer code works, but they
haven't been implemented yet.)
> If you use ip reassembly on say NFS v3/UDP reading/writing large files, a
> significant number of the captured packets will be ip fragments,
> thus this would become a problem.
But the composite tvbuff in question should be freed when you're done
with the protocol tree for the reassembled packet.
> An application to map all segments in a TCP sequence into a COMPOSITE tvbuff
> (TCP reassembly, ~~treat TCP session as sequence of bytes) would make the
> backing REAL_DATA tvbuffs very long lived. That would make them live until a
> new capture was started/loaded.
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.
TCP reassembly does not, in and of itself, require that. All TCP
reassembly has to do is to pass to the subdissector in-sequence TCP
data, with no duplicate data, as it arrives; the underlying subdissector
can then carve that data into its own PDUs (which it has to do anyway),
and reassemble it itself (with the aid of, say, shared routines to do
much of the work, just as IPv4, IPv6, and CLNP reassembly share the code
in "reassemble.c").