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