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

Reply via email to