Wireshark · Ethereal-dev: Re: [Ethereal-dev] IP defragment, enjoy, please consider this for cvs

[Guy Harris <gharris@xxxxxxxxxxxx>]

On Mon, Apr 02, 2001 at 11:41:55PM -0700, Guy Harris wrote:
> You shouldn't - and don't have to - do anything whatsoever with the
> widget set to do that; you merely have to add a preference item in the
> dissector.  This adds an additional item in the "IP" tab of the
> "Edit->Preferences" dialog box, and also allows you to specify it on the
> command line with the "-o" flag.  See the attached patch to
> "packet-ip.c".
> 
> However, if I then enable the "Reassemble fragmented datagrams" the new
> preference item adds, and click "Apply" in the dialog box, it doesn't
> reassemble anything - it just shows the first fragment as a fragment
> rather than an Echo or Echo Reply packet.

This also means that "ip_defragment_cleanup()" should probably be
renamed "ip_defragment_init()", and registered as an "init routine",
using "register_init_routine()", as it should probably be called not
only when a new capture is read, but also whenever the current capture
is rescanned - for example, if any of the protocol preference items is
changed.

It should then do something such as

static void
ip_defragment_init(void)
{
	if (ip_fragment_table != NULL) {
		/*
		 * The fragment hash table exists.
		 *
		 * Remove all entries from the hash table, and free
		 * them.
		 */
		g_hash_table_foreach_remove(ip_fragment_table,free_all_fragments,NULL);
	} else {
		/*
		 * The fragment hash table doesn't exist; create it.
		 */
		ip_fragment_table = g_hash_table_new(ip_fragment_hash,
					ip_fragment_equal);
	}
}

However, you may want to use the GLib "memory chunk allocator" to
allocate "ip_fragment_key" and "ip_fragment_data" structures.  That
allocator calls the system allocator ("malloc()" - or, rather the
"g_malloc()" wrapper around it) to allocate blocks capable of holding
multiple structures, and parcels structures out from those blocks; if
you free a block, it gets added to a per-chunk free list.

This speeds up allocation and freeing, reduces the memory-allocator
overhead (it's per-chunk, not per-structure), and might, in some cases,
provide more locality of reference to main memory.

It also means you can free all objects allocated in the chunk with one
call, which may be a bit faster.

However, you still have to free the mallocated packet *data* chunks one
at a time, so that may or may not be the right thing to do for now.

Unfortunately, doing that still didn't clear up the problem with turning
the "defragment IP packets" option on after reading in a capture.