[jboss-jira] [JBoss JIRA] Commented: (JGRP-324) Wireshark plugin for JGroups

Richard Achmatowicz (JIRA) jira-events at lists.jboss.org
Tue Nov 4 15:34:20 EST 2008


    [ https://jira.jboss.org/jira/browse/JGRP-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12436881#action_12436881 ] 

Richard Achmatowicz commented on JGRP-324:
------------------------------------------

Some changes recently made to the jgroups wireshark plugin:
(i) moved from port-based dissectors to heuristic dissectors
(ii) added in checks for supported JGroups wireformats

Heuristic dissection

Wireshark determines the function to be called to dissect the payload of a packet in one of two ways: 
(i) port-based dissection: a dissector is associated with a port - any packet sent/received from that port will use the dissector
(ii) heuristic dissection: a dissector is associated with a packet format - any payload which matches the format uses that dissector

Because JGroups packets can contain a variety of address/port combinations for source and dest of JGroups messages, port-based
dissection does not work well. Thus, the JGroups plugin uses heuristic dissection: the JGroups dissector is registered with
both the UDP and TCP Wireshark plugins as a heuristic dissector - each time a UDP/TCP packet is processed, the UDP/TCP plugin will
call the JGroups heuristic dissector. The dissector will check if the payload is a JGroups message. If it is, it will dissect it and 
return true; if it is not, it will return false.

With this change, now all packets captured which contain JGroups payloads get processed by the jgroups dissector. This was not happening 
previously with port based dissection as so many different address/port combinations could turn up in the JGroups packets: multicast address/port
destinations, source address/port combinations for every peer, etc. Now, there is no need to specify any ports in order to get packets dissected. 

FYI: I was getting this notion of determining which packets contain JGroups payloads (and so need to be dissected with the JGroups dissector) 
confused with the notion of a conversation (identifying and processing together packets exchanged by two peers). It turns out that they are 
completely unrelated. In fact, we need to determine first if a packet contains a JGroups payload. If it does, then we may consider (based on its 
source and dest address/port combinations) whether it should be in a conversation.

Version checking

Because the JGroups wireformat changed between certain releases, and because the dissection which the jgroups plugin performs is intimately tied 
to the wireformat, we need to have a mechanism for checking that 
(i) a UDP/TCP payload which is handed to the jgroups dissector represents a payload for a valid JGroups version (e.g. 2.4.2, .., 2.6.1, 2.6.2, ..2.7.0 ) and 
(ii) that support for dissection of that version exists in the jgroups plugin (at present, only 2.6.4 and binary compatible  versions)

This check has now been added.








> Wireshark plugin for JGroups
> ----------------------------
>
>                 Key: JGRP-324
>                 URL: https://jira.jboss.org/jira/browse/JGRP-324
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Richard Achmatowicz
>            Priority: Minor
>             Fix For: 2.x
>
>
> Write a C implementation of a Wireshark plugin which understands the JGroups wire format and displays information about the JGroups messages (e.g. sender, receiver, headers) in ethereal.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        



More information about the jboss-jira mailing list