All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: Wireshark Dissector
       [not found] <5328DDAB.3050606@kevincox.ca>
@ 2014-03-19  0:04 ` Sage Weil
  2014-03-19  3:24   ` Kevin Cox
  0 siblings, 1 reply; 2+ messages in thread
From: Sage Weil @ 2014-03-19  0:04 UTC (permalink / raw)
  To: Kevin Cox; +Cc: yehuda, ceph-devel

Hi Kevin,

On Tue, 18 Mar 2014, Kevin Cox wrote:
> Hello Sage,
> 
> I was finishing up my proposal to write the wireshark dissector and was
> wondering how I should segment my work.  In order to ensure I stay on
> track I will set goals for every couple of weeks but am unsure of how to
> slice the work up.
> 
> I have looked that the files suggested by Patrick and some of the
> implementation behind them but I haven't got a solid grasp of the full
> protocol.  From what I can see there appears to be a "core" protocol
> which is used by all node types then there are separate client, mon,
> osd, and mds messages.  After dissecting the basic message format do you
> recommend proceeding by message "area" or is there another order which
> you would take?  Also relatively how much time do you expect each "area"
> to take, from what I have seen they are roughly the same size but I'm
> sure you have a better guess.

I think you're on the right track.  I suspect it would go something like:

 - get environment, infrastructure up and running
 - parse basic message exhcange, but not messages
 - add support for individual message types by subsystem
   - mon<->client (including authentication and such)   (small)
   - osd<->client    (small)
   - osd<->osd       (big)
   - mon<->mon       (medium)
   - client<->mds    (medium)
   - mds<->mds       (big)

The nice thing here is that the stop point is moveable.  Getting the 
basics in place will make it easy for others to add or update additional 
message decodings later, and with just the few most common messages the 
tool is immediately useful.

At some point early I would engage with the Wireshark folks too to make 
sure things are appropriate for upstreaming.  Getting the initial support 
in early and following up with support for additional message types later 
might be a good strategy as well.

> PS: Is it better to talk privately or to send these messages to the
> list?  If you think that they can be useful to others feel free to copy
> the list on your reply.

Copying the list is great as long as you're comfortable with it. :)

Thanks!
sage

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Wireshark Dissector
  2014-03-19  0:04 ` Wireshark Dissector Sage Weil
@ 2014-03-19  3:24   ` Kevin Cox
  0 siblings, 0 replies; 2+ messages in thread
From: Kevin Cox @ 2014-03-19  3:24 UTC (permalink / raw)
  To: ceph-devel

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

On Mar 18, 2014 8:04 PM, "Sage Weil" <sage@inktank.com
<mailto:sage@inktank.com>> wrote:
>
> I think you're on the right track.  I suspect it would go something like:
>
>  - get environment, infrastructure up and running
>  - parse basic message exhcange, but not messages
>  - add support for individual message types by subsystem
>    - mon<->client (including authentication and such)   (small)
>    - osd<->client    (small)
>    - osd<->osd       (big)
>    - mon<->mon       (medium)
>    - client<->mds    (medium)
>    - mds<->mds       (big)
>

Thanks, this is exactly what I was looking for.

> The nice thing here is that the stop point is moveable.  Getting the
> basics in place will make it easy for others to add or update additional
> message decodings later, and with just the few most common messages the
> tool is immediately useful.
>

I was thinking the same think.  While I think I can finish all the
protocols in the
given time I obviously don't know enough to be sure.  I'm writing my
proposal
so that even if I got hit by a bus the finished work should be a solid
foundation.

> At some point early I would engage with the Wireshark folks too to make
> sure things are appropriate for upstreaming.  Getting the initial support
> in early and following up with support for additional message types later
> might be a good strategy foundation

Sounds like a good plan.

Thanks,
Kevin



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2014-03-19  3:24 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <5328DDAB.3050606@kevincox.ca>
2014-03-19  0:04 ` Wireshark Dissector Sage Weil
2014-03-19  3:24   ` Kevin Cox

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.