plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <>
Subject Re: [DISCUSS] Ethernet based protocols
Date Mon, 11 May 2020 12:48:27 GMT
Hi Lukasz,

well in the PLC4J 0.6.0 world we explicitly modeled each layer of the protocols so they could
be layered.
However we quickly noticed that not a single layer was re-used. 

I agree that the current mspec approach brings some duplication with it, however I am not
really seeing it happen so far. 
I would assume as soon as we start supporting more CIP based protocol, the duplication will
increase. Same with the low level ethernet frames.
In theory it should be quite simple to just add wildcard import statements to a driver which
should make it work with layered mspecs.
The reason this should work is that currently the parser doesn't check if all used types are
actually defined, it just expects the developer to take care of this.

For now I would suggest to keep it simple and duplicate things and as soon as we see problems
arise from this, we can factor out the common parts.

What do you think?


Am 11.05.20, 14:01 schrieb "Łukasz Dywicki" <>:

    Based on observations I gathered while writing LLDP and Profinet DCP
    mspec file I found there are some elements which are repeating between
    These are basic structures: mac address, ip address and ethernet frame
    with different payloads based on ethernet type field. The same
    structures must be added to LLDP, Profinet DCP and eventually any other
    raw ethernet protocol.
    Since I do see a risk of getting growing amount of code duplicated
    across a project I wanted to discuss possible approaches to that. I do
    not see a big trouble around mspec, cause above structures are all
    together 15-20 lines long, but around processing of ethernet frame itself.
    Because same interface can host multiple protocols I am not quite sure
    how to proceed with this one. So far we have only SingleStack configurer.
    I been thinking about basic unification and re-use of Ethernet frame
    across low level protocols. Maybe it would allow us to provide a
    multistack configurer implementation.
    I am aware that the same interface can be opened by pcap library
    multiple times, however I do see an overhead there. Multiple handles
    will keep processing same packets with no real need for that.

    Please take this as a starting point for a discussion as I do not have
    any idea yet, how to handle this. If you do - then please throw it here. :)


View raw message