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

[ https://jira.jboss.org/jira/browse/JGRP-324?page=com.atlassian.jira.plugi... ] 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. -- 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