On Tue, 2008-11-18 at 13:04 -0700, Stephen Fisher wrote: > Excellent! Could you please open a bug (https://bugs.wireshark.org) and > mark it as an enhancement request and then attach your patches to it?
Done: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3070 Review is appreciated :) > It would be appreciated if you could figure out a better way to handle > the VNC dissection. The problem I ran into writing the bulk of the VNC > dissector was that you don't know how much more data there is until you > go further along in the packet. Basically: you find out you need X more > bytes of data, so you request them, then you find out you need Y more > bytes of data after reading the X bytes of data and so on. I stared at > the VNC dissector so much that I may have just overlooked a better way > to handle things. Any input/code is appreciated :). Yeah, it's a pretty ad-hoc protocol :) I think we just need to do this: - Add some finer-graned states, such as a RECT state for "I'm in the middle of handling a bunch of rectangles". - Handle each state in two passes. The first pass only computes how much data it will need to dissect in order to go to the next state. The second pass actually expects a desegmented tvb; it re-parses the buffer and adds the info to the protocol tree. *Then* it actually moves the machinery to the next state. Having the finer-grained states (in particular for rectangles) should help avoid O(n^2) reparsing when we have a long list of rectangles and we must request desegmentation a bunch of times. I may start implementing this rather soon, as I really need to be able to compare TightVNC runs versus gtk-vnc's :) Federico _______________________________________________ Wireshark-dev mailing list [email protected] https://wireshark.org/mailman/listinfo/wireshark-dev
