plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Dywicki <>
Subject Re: [DISCUSS] Ethernet based protocols
Date Mon, 11 May 2020 14:23:08 GMT
I've noticed some hidden features of mspec when I declared a `Duration`
field type and surprisingly - it did compile because of wildcard import
from javax.time. :-)

Using implicit classpath is fine for me. I haven't done the active part
of the LLDP, but I suspect that overlapping part with profinet will be
just structures.
The big differentiator is how actually frames are processed.


On 11.05.2020 14:48, Christofer Dutz wrote:
> 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?
> Chris
> Am 11.05.20, 14:01 schrieb "Łukasz Dywicki" <>:
>     Hey,
>     Based on observations I gathered while writing LLDP and Profinet DCP
>     mspec file I found there are some elements which are repeating between
>     these.
>     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. :)
>     Best,
>     Łukasz

View raw message