You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by Łukasz Dywicki <lu...@code-house.org> on 2020/05/11 12:01:47 UTC

[DISCUSS] Ethernet based protocols

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

Re: [DISCUSS] Ethernet based protocols

Posted by Łukasz Dywicki <lu...@code-house.org>.
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.

Cheers,
Łukasz

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" <lu...@code-house.org>:
> 
>     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
>

Re: [DISCUSS] Ethernet based protocols

Posted by Christofer Dutz <ch...@c-ware.de>.
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" <lu...@code-house.org>:

    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