Hi
> >>>> To make it worse if I go back and forth to the same packet it will be
> >>>> dissected one more time.
> >>>> With complex protocols like DRS (directory replication for Active
> >>>> directory)
> >>>> it's really a problem as the UI freeze for a while.
> >>> Is the protocol really so complex that dissecting a single packet of
> >>> it takes a user-visible amount of time? That seems suspect to me.
> >> So what I did is that I'm dissecting the deferred RPC pointers only if tree
> >> != NULL the dissection of pointers takes a while because there is ~ 1700 top
> >> level pointers and each of them have a lot inner pointers, DRS is a very
> >> complicated protocol.
> > Fair enough, that's quite a bit of data to process. The packets must
> > be enormous.
> The reassembled packet payload is 300K but it's compressed, after
> decompression it's 2MB of data.
Did you profile the code or can you share a capture?
Problem could be elsewhere, like in dfilter_macro_build_ftv_cache (a usual
culprit)...
om the second pass, but we would have to calculate in advance which
> >>> packets are visible, which may or may not be easy.
> >> Pardon my wireshark ignorance but it really look like the 2nd and the 3rd
> >> pass are recreating the thing from scratch.
> > Every time we do a dissection it is more-or-less "from scratch". The
> This kind of massive DRS is spread on ~300 1500 bytes TCP packets.
That's not a big packet :)
Didier