No, I understand now.
Any holes in the new type of COMPOSITE would not cause any problem
different from what a dissector would see anyway with too short packets.
I think it would be useful if it would be possible to activate a feature so
that every
single TCP segment would be placed in a COMPOSITE. With one COMPOSITE for
every
{srcip,srcport,dstip,dstport} that the TCP dissector sees.
For this to be realistic, the additional memory and cpu consumtion this
would cause has to bee
neglible. I think that requirement is possible to fulfill.
But there is another problem which I think must be solved.
Example: assume a RPCoverTCP command spans several TCP packets (e.g. NFS
Read/Write)
One might want the RPC dissector to delay handing the RPC payload up to the
NFS (or similar) layer
until sufficient TCP segments have been received to be able to dissect the
entire RPC command.
That is probably not too difficult. (though there are issues, like RPC layer
will normally not be involved for
other than the first segment, some sort of mechanism to handle this would be
required.)
So assume we have received all the segments for the entire RPC packet and it
is held in a new COMPOSITE.
We cant hand this COMPOSITE to the NFS dissector since that dissector
assumes the data in the tvb starts at offset==0.
Since rewriting all dissectors which might (in the future be a lot of them?)
see these COMPOSITES is not realistic,
perhaps there is a need to make sure that a SUBSET tvbuff can be created
ontop of a COMPOSITE.
To keep the implementation sane and simple, we will then need to disallow a
COMPOSITE to contain a SUBSET
(to prevent COMPOSITE->SUBSET->COMPOSITE-> loops ad infinitum).
This would impose the following rules for tvbuff:
* One can create a SUBSET of a COMPOSITE.
* A tvbuff can be added anywhere in the 4Gb address range for a COMPOSITE.
The current prepend and append
functions would only be special cases of that.
* COMPOSITES can only contain REAL_DATA tvbuffs.
* One can add REAL_DATA tvbuffs to a COMPOSITE.
* One can add a SUBSET to a COMPOSITE, but only if the backing store for the
SUBSET is REAL_DATA
and in that case what really gets added is the backing REAL_DATA tvbuff
and not the SUBSET.
One additional point I would argue would be that since the offset in a
COMPOSITE would not really be meaningful anymore,
one might require that a SUBSET is created before any accessors can get to
the data. This is to prevent useage errors.
By creating a SUBSET, one really defines what is offset==0. I argue to
disallow accessors to operate on COMPOSITES.
(None is using COMPOSITES today anyway so this new restriction would not
affect any existing dissectors)
Additional point, make the program exit if someone tries to do tvb_get_prt()
on a range larger than ,say, 1Mb.
(I see very very large COMPOSITES in my applications)
The following requirements would be a must if the extension is to be useful:
* Adding new tvbuffs to a COMPOSITE must be very efficient. It may not
affect memory or cpu useage in any noticeable
amount even if someone really wants to put every single packet inside a
COMPOSITE.
(If its not useful for large captures, it is pointless to implement it)
* Creating a SUBSET from a COMPOSITE must be efficient, though not critical.
Createing SUBSETs are likely only done when
a dissector wants to do something special. This may not consume any
noticeable amount of memory.
----- Original Message -----
From: "Guy Harris" <guy@xxxxxxxxxx>
To: "Ronnie Sahlberg" <rsahlber@xxxxxxxxxxxxxx>
Cc: "Guy Harris" <gharris@xxxxxxxxx>; <ethereal-dev@xxxxxxxxxxxx>;
<andreas.sikkema@xxxxxxxxxxx>
Sent: Thursday, May 24, 2001 11:11 AM
Subject: Re: [Ethereal-dev] RFC: new TVBUFF type
> > > However, if the rule is
> > >
> > > accessors throw an exception if *any* of the data they need is
> > > missing, for *any* reason
> > >
> > > then if a dissector tries to fetch stuff from a region that includes
the
> > > hole, an exception will be thrown - and any dissector that misbehaves
if
> > > an exception is thrown at any place where it calls an accessor is
> > > *already* broken.
> >
> > See above.
>
> Umm, the "above" doesn't, in any way, shape, or form, indicate that
> throwing an exception is insufficient to make COMPOSITES-with-holes as
> safe as any other type of tvbuff.
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
