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" <luke@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
>
|