On Fri, Jul 14, 2000 at 03:44:58AM -0500, Neil Hunter wrote:
>
>
> Hi all,
> The WAP dissector is coming along nicely now - I've fixed a few things in
> Ben's
> initial implementation, expanded the WTP support and started the WSP
> support.
> Its been an interesting learning exercise and I thought I'd drop a few
> thoughts
> to the list:
>
> 1. I find the current layout difficult to use on my monitor, so I've hacked
> in
> an "alternative layout" flag in the preferences file. This is checked in
> the
> main window creation code and if set to true it places the packet list and
> tree
> view windows side-by-side with the byte view underneath. I find that easier
> to
> use - let me know if anyone else would like the code.
Great! I thought about doing this a while back because this "double-wide"
format would work a lot better on my 1600x1200 resolution monitor at work,
where I have the pixels for it. At home I still need the "classic" format.
> 2. The WSP protocol uses a byte encoding scheme that uses the msb to
> indicate
> whether the value continues into the next byte and the remainder of the
> octet to hold the value. If set, the value should be shifted left 7 places
> and
> the next octet parsed. To do this I've written a tvb function similar to
> the tvb_get_guint functions that returns the value *and* the number of
> octets
> read to get the final value. At the moment I've put this function in
> tvbuff.c,
> but it occurs to me that it may be a WSP-specific method. Any thoughts on
> whether it should stay there or move to the WSP file?
Does anyone know if any other protocol needs this? What about the ASN.1-derived
protocols? Even if no other protocols use it, I'd say leave it in tvbuff.c,
as long as it has a sensible name (not someting WSP-specific, like
tvb_get_wsp_guint()).
> 3. In WSP, strings are stored *without* their trailing 0x00 - any thoughts
> on
> whether it should be the application that is responsible for appending a
> missing null before displaying a string, or whether Ethereal should insert
> a
> null at the end of the requested length of string if one is missing? (At
> the
> moment I'm doing it).
Do they have an initial byte representing their length, or are the of
a pre-determined length?
Guy - what are your thoughts? How's your work on the FT_STRING additions?
(FT_NSTRING would be good for this, although I can't remember now if
that's what you were working on, or if it was FT_STRINGZ. I think
you were working on FT_STRINGZ, and I thought to myself that FT_NSTRING
would be a good idea, too.)
> Cheers,
> Neil
--gilbert
