It sounds to me like it shouldn’t be a set or a list, but a tree? Evan
On Fri, Oct 6, 2017 at 08:17 Michael Mann via Wireshark-dev < wireshark-dev@wireshark.org> wrote: > There's also this explanation: > https://www.wireshark.org/lists/wireshark-dev/201701/msg00005.html > > > -----Original Message----- > From: Pascal Quantin <pascal.quan...@gmail.com> > To: Developer support list for Wireshark <wireshark-dev@wireshark.org> > Sent: Fri, Oct 6, 2017 3:06 am > Subject: Re: [Wireshark-dev] XXXX: avoid appending xxxx multiple times to > frame.protocols field > > Hi Roland, > > 2017-10-06 8:23 GMT+02:00 Roland Knall <rkn...@gmail.com>: > > 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)? > > > Here it is: https://code.wireshark.org/review/19464 > > > 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 > > > ___________________________________________________________________________ > 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 > <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
___________________________________________________________________________ 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
