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" <[email protected]>: 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
