[Guy Harris <gharris@xxxxxxxxxxxx>]

On Wed, Feb 14, 2001 at 09:33:47PM -0600, David Frascone wrote:
> I just realized this won't work either.  It'd be impossible to find the start
> of the next packet.

"Next packet" as in the subsequent frames in the TCP stream?  You
*would* need that for that "nifty make new tvb call" to work - the calls
to construct a composite tvbuff are

	"tvb_new_composite()", which creates a new empty composite
	tvbuff;

	"tvb_composite_append()", which takes a composite tvbuff and
	another tvbuff as an argument, and glues the latter tvbuff to
	the end of the composite tvbuff;

	"tvb_composite_prepend()", which takes a composite tvbuff and
	another tvbuff as an argument, and glues the latter tvbuff to
	the front of the composite tvbuff.

This means that to make a new tvbuff that includes stuff from one frame
in a TCP connection and stuff from a later frame, you'd need tvbuffs
that refer to *both* frames - not just a tvbuff referring to the current
frame.

I.e.:

		nifty_make_new_tvb_call(tvb, difference in length);

is, as presented, unimplementable, as "nifty_make_new_tvb_call()" is not
being passed any information about where to get the additional data to
make up the difference in length.