[JBoss JIRA] Created: (JGRP-494) Investigate marshalling format to simplify wireshark / ethereal plugin
9:05 a.m.
Investigate marshalling format to simplify wireshark / ethereal plugin
-----------------------------------------------------------------------
Key: JGRP-494
URL: http://jira.jboss.com/jira/browse/JGRP-494
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.5
Currently, parsing JGroups network data via wireshark is difficult:
- message lists don't have (a) total number of bytes and (b) bytes/message and
- headers don't have (a) total bytes for all headers and (b) bytes / header
Investigate whether we can change the marshalling format to accommodate the wireshark
plugin. This has the nice side effect that the JGroups wire format becomes standardized,
ie. each header has the same format. This allows us to display a header even if we
don't know how to parse it. In this case, we'd simply display the name and number
of bytes.
Caveat: we want to avoid having to make messages bigger when marshalled.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:55 a.m.
New subject: [JBoss JIRA] Resolved: (JGRP-494) Investigate marshalling format to simplify wireshark / ethereal plugin
[ http://jira.jboss.com/jira/browse/JGRP-494?page=all ]
Bela Ban resolved JGRP-494.
---------------------------
Resolution: Done
Added a short field for each header which is the number of bytes the header will write to
the output stream. Chris will see whether this is all that's needed when parsing
JGroups messages for wireshark
Investigate marshalling format to simplify wireshark / ethereal
plugin
-----------------------------------------------------------------------
Key: JGRP-494
URL: http://jira.jboss.com/jira/browse/JGRP-494
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.5
Currently, parsing JGroups network data via wireshark is difficult:
- message lists don't have (a) total number of bytes and (b) bytes/message and
- headers don't have (a) total bytes for all headers and (b) bytes / header
Investigate whether we can change the marshalling format to accommodate the wireshark
plugin. This has the nice side effect that the JGroups wire format becomes standardized,
ie. each header has the same format. This allows us to display a header even if we
don't know how to parse it. In this case, we'd simply display the name and number
of bytes.
Caveat: we want to avoid having to make messages bigger when marshalled.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:12 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-494) Investigate marshalling format to simplify wireshark / ethereal plugin
[ http://jira.jboss.com/jira/browse/JGRP-494?page=comments#action_12419504 ]
Richard Achmatowicz commented on JGRP-494:
------------------------------------------
It may be that we need to reopen this issue.
Here's the problem. When dissecting JGroups over TCP, we have to take account of two
things due to the stream-orientation of TCP:
(i) a large TP bundle may be split into several TCP fragments
(ii) several small TP bundles may be placed into one TCP fragment
Reassembly of TP bundles will occur at the receiving TCP peer end, but Wireshark captures
the fragments before reassembly, in between
the peers so to speak, and so the Wireshark plugin writer has to do the reassembly
herself.
Reassembling TCP fragments is very very simple if we have a field in the TP header which
describes the length of the entire TP bundle.
We can then say to Wireshark - "reassmble enough TCP fragments until you get a buffer
with at least this length". Dissection on a complete
TP bundle can then proceeed in a straightforward fashion.
Without this information, we never know if we have a complete TP bundle in the buffer, and
so have to dissect the TCP fragment "on the fly" -
checking before each read from the buffer if we have enough data in the buffer left; in
that case that there is not enough data, request the
reading of another TCP fragment. This complicates processing quite a bit.
So - in summary, having the total length of a TP bundle in the TP header would help
greatly with TCP processing.
Investigate marshalling format to simplify wireshark / ethereal
plugin
-----------------------------------------------------------------------
Key: JGRP-494
URL: http://jira.jboss.com/jira/browse/JGRP-494
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.5
Currently, parsing JGroups network data via wireshark is difficult:
- message lists don't have (a) total number of bytes and (b) bytes/message and
- headers don't have (a) total bytes for all headers and (b) bytes / header
Investigate whether we can change the marshalling format to accommodate the wireshark
plugin. This has the nice side effect that the JGroups wire format becomes standardized,
ie. each header has the same format. This allows us to display a header even if we
don't know how to parse it. In this case, we'd simply display the name and number
of bytes.
Caveat: we want to avoid having to make messages bigger when marshalled.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:51 p.m.
New subject: [JBoss JIRA] Updated: (JGRP-494) Investigate marshalling format to simplify wireshark / ethereal plugin
[ http://jira.jboss.com/jira/browse/JGRP-494?page=all ]
Bela Ban updated JGRP-494:
--------------------------
Fix Version/s: 2.7
(was: 2.5)
Investigate marshalling format to simplify wireshark / ethereal
plugin
-----------------------------------------------------------------------
Key: JGRP-494
URL: http://jira.jboss.com/jira/browse/JGRP-494
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.7
Currently, parsing JGroups network data via wireshark is difficult:
- message lists don't have (a) total number of bytes and (b) bytes/message and
- headers don't have (a) total bytes for all headers and (b) bytes / header
Investigate whether we can change the marshalling format to accommodate the wireshark
plugin. This has the nice side effect that the JGroups wire format becomes standardized,
ie. each header has the same format. This allows us to display a header even if we
don't know how to parse it. In this case, we'd simply display the name and number
of bytes.
Caveat: we want to avoid having to make messages bigger when marshalled.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:51 p.m.
New subject: [JBoss JIRA] Reopened: (JGRP-494) Investigate marshalling format to simplify wireshark / ethereal plugin
[ http://jira.jboss.com/jira/browse/JGRP-494?page=all ]
Bela Ban reopened JGRP-494:
---------------------------
Investigate marshalling format to simplify wireshark / ethereal
plugin
-----------------------------------------------------------------------
Key: JGRP-494
URL: http://jira.jboss.com/jira/browse/JGRP-494
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.7
Currently, parsing JGroups network data via wireshark is difficult:
- message lists don't have (a) total number of bytes and (b) bytes/message and
- headers don't have (a) total bytes for all headers and (b) bytes / header
Investigate whether we can change the marshalling format to accommodate the wireshark
plugin. This has the nice side effect that the JGroups wire format becomes standardized,
ie. each header has the same format. This allows us to display a header even if we
don't know how to parse it. In this case, we'd simply display the name and number
of bytes.
Caveat: we want to avoid having to make messages bigger when marshalled.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:08 a.m.
New subject: [JBoss JIRA] Closed: (JGRP-494) Investigate marshalling format to simplify wireshark / ethereal plugin
[
https://jira.jboss.org/jira/browse/JGRP-494?page=com.atlassian.jira.plugi...
]
Bela Ban closed JGRP-494.
-------------------------
Resolution: Won't Fix
Turns out that we do have the length for a UDP bundle, so we don't need this change
Investigate marshalling format to simplify wireshark / ethereal
plugin
-----------------------------------------------------------------------
Key: JGRP-494
URL: https://jira.jboss.org/jira/browse/JGRP-494
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.7
Currently, parsing JGroups network data via wireshark is difficult:
- message lists don't have (a) total number of bytes and (b) bytes/message and
- headers don't have (a) total bytes for all headers and (b) bytes / header
Investigate whether we can change the marshalling format to accommodate the wireshark
plugin. This has the nice side effect that the JGroups wire format becomes standardized,
ie. each header has the same format. This allows us to display a header even if we
don't know how to parse it. In this case, we'd simply display the name and number
of bytes.
Caveat: we want to avoid having to make messages bigger when marshalled.
--
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
5958
days inactive
6406
days old
5 comments
2 participants
participants (2)
-
Bela Ban (JIRA) -
Richard Achmatowicz (JIRA)