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 ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
