Hi Roland, 2017-10-06 8:23 GMT+02:00 Roland Knall <[email protected]>:
> 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 <[email protected]> > wrote: > >> Hi Guy, >> >> Le 5 oct. 2017 23:20, "Guy Harris" <[email protected]> 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 <[email protected]> >> Archives: https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >> mailto:[email protected]?subject=unsubscr >> ibe >> > > > ____________________________________________________________ > _______________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject= > unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
