Personally I think moving to a set would reduce functionality for some applications. Industrial ethernet applications for instance heavily rely on multiple protocols being transported in single frames multiple times (one UDP packet contains a lot of openSAFETY frames, which themselve could contain data dissectors).
So -1 for me for moving to a set. @Pascal - could you point me in the direction of Michael's change you mentioned (pino stuff)? On Fri, Oct 6, 2017 at 7:01 AM, Pascal Quantin <pascal.quan...@gmail.com> wrote: > Hi Guy, > > Le 5 oct. 2017 23:20, "Guy Harris" <g...@alum.mit.edu> a écrit : > > A given frame's dissection can have multiple packets for a given protocol, > if, at any protocol layer, a PDU can contain multiple PDUs for the next > layer above it (or parts of multiple PDUs, as with byte-stream protocols > such as TCP). > > Some recent changes have been submitted to fix that for particular > protocols. > > However, the underlying problem is that frame.protocols is intended to be > a set (in which a given item can occur only once) rather than a bag (in > which a given item can occur multiple times). Perhaps it should be > implemented as a set, with uniqueness enforced, so that individual > dissectors don't need to keep from putting another XXXX in the bag if > there's already one there? > > > What I like also with frame.protocols field is that it shows the protocol > encapsulation order within the packet. So in case of an IP packet > encapsulated inside a protocol running in top of IP, I think it makes sense > to display up twice. Changing it to a set would lose this property. > > The problem with S1AP and Co is that it uses some dissector tables > internally to decode the fields, leading to fake multiple occurrences > within frame.protocols field. By the way, I realize that the pino > functionality introduced by Michael might have been used here also instead > of the simple patch I did. It might be an opportunity for me to see how > this pino stuff behaves exactly ;) > > Cheers, > Pascal. > > ____________________________________________________________ > _______________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject= > unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe