Ethereal-dev: Re: [Ethereal-dev] [Patch] revised: tap-tcp_close

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Jason House <jhouse@xxxxxxxxx>
Date: Tue, 03 Dec 2002 11:17:16 -0500
Guy Harris wrote:
> 
> On Mon, Dec 02, 2002 at 09:23:56AM -0500, Jason House wrote:
> > Per Ronnie's suggestions, I have updated packet-tcp.c and tap-tcp_close
> It's a bit ugly to have "td" be static; I suppose it's not a problem in
> most cases, but one could imagine TCP-over-IP-over-X.25-over-TCP
> captures in which there's more than one TCP header per packet.
> 
> Unfortunately, as a pointer to it is passed to "tap_queue_packet()", it
> can't be local to "dissect_tcp()".


Proposed solution:

 * In Tapping Core:
  convert register_tap to:
    int register_tap(char *name, void (deallocate)(void*))
  Have dissect_tcp allocate a new copy of "td" each time it is run
  Have tap_queue_packet call deallocate if data won't be used.
  And have tap_push_tapped_queue call deallocate after data is used

 * In tap-tcp_close.h: (actually it should be relocated to packet-tcp.h)

 * In currently existing taps
  add extra parameter "NULL" to register_tap

 * Packet-tcp and future protocols requiring dynamic tap_specific_data:
  make td a pointer
  create a deallocate function (discussed below)
  pass function pointer to deallocate in with register_tap

 * Proposed Memory management in packet-tcp.[ch]
  add the field "gboolean inuse" to tcp_tap_data_t
  add "GList *td_list = NULL;" to top of packet-tcp
  in dissect_tcp:
    set td to point to a tcp_tap_data_t with inuse==0
    (if none exist, allocate a new one)
    td->inuse = 1;
    (do normal dissection/tap preperation)
  in deallocate
    ((tcp_tap_data_t*)(void_pointer))->inuse = 0;



99.999% of the time, dissect_tcp will allocate one copy of td.
In rare cases that Guy mentioned, 2 copies will be allocated and so,
occasionally dissect_tcp will have to look for a second element in the
list.

This approach avoids allocation/deallocation and uses up a minimal
amount of memory.  Memory optimization is left up to the dissector.

How does this approach sound?  Any better approaches?  Comments? etc...