I have implemented far too many protocols over the years, in Java, and I
typically end up with;
Link Layer = serial port, IP, TCP, UDP...
Framing / Packet Layer = everything common no matter what payload is.
Typicall involves start/stop markers, escaping/replacement, checksums,
Operations Layer = Different payloads depending on the "function",
"operation", "data type", "event type",... being exchanged.
And to that, I would attach "Utilities" which deals with data type
conversions to/from Java types, bit manipulation, text handling,... and
zero, one or more "Subsystems" for advanced topics specific to the protocol
needed to bridge to "my platform", such as remote alarm management, device
level data recordings, programming, heart beat handling, ++
My 2 devalued cents...
Niclas
On Thu, May 30, 2019 at 6:06 AM Julian Feinauer <
j.feina...@pragmaticminds.de> wrote:
> Hey Chris,
>
> this is one oft he problems I also stumbled across when reasoning and
> which I consider 'hard'.
> One way to make it way cleaner would be to switch to a layered
> architecture.
> If we generally distinguish between Transport Layers and Communication
> Layer (better anmes are welcome) we can introduce a general format of these
> transport layers which is
>
> [Type
> [Some Type of header Stuff]
> [byte[] payload]
> [Some Type of fooder Stuff]
> ]
>
> This would also enforce reusability.
>
> Or am I getting things wrong?
>
> Am 29.05.19, 23:55 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
>
> Hi all,
>
> so today I somewhat finished the POJO generation for Java and am
> currently implementing the IO classes to parse the POJOs (Second step will
> be serializing)
>
> Now I stumbled into following problem (One example from the S7
> protocol):
>
> [discriminatedType 'S7Message' ['payloadLength']
> [const uint 8 'protocolId' '0x32']
> [discriminator uint 8 'messageType']
> [reserved uint 16 '0x0000']
> [field uint 16 'tpduReference']
> [implicit uint 16 'parameterLength' 'parameters.size']
> [implicit uint 16 'payloadLength' 'payloads.size']
> [typeSwitch 'messageType'
> ['0x01' Request
> [context string 'messageType' 'request']
> ]
> ['0x03' Response
> [context string 'messageType' 'response']
> [field uint 8 'errorClass']
> [field uint 8 'errorCode']
> ]
> ['0x07' UserData
> [context string 'messageType' 'userData']
> ]
> ]
> [field S7Parameter 'parameter' {messageType: 'messageType'}]
> [field S7Payload 'payload' {messageType: 'messageType', parameter:
> 'parameter'}]
> ]
>
> As you can see there's properties that belong to the base type and
> parts that belong to Request, Response and UserData ... however this
> information is sort of in-between the header and the footer.
>
> Enforcing the switch to be the last and pulling the parameter and
> payload into the cases, sounds like an ugly restriction.
>
> So I thought that I might generate some parser classes for the
> sub-types, that contain the sub-type properties only and a factory method
> ... to in this case the Response factory pojo class which would sort of
> look like this:
>
> public class ResponseDelayedBuilder implements DelayedBuilder {
> private final short errorClass;
> private final short errorCode;
>
> public ResponseParserModel(short errorClass, short
> errorCode) {
> this.errorClass = errorClass;
> this.errorCode = errorCode;
> }
>
> @override
> public Response build(int tpduReference, S7Parameter parameter,
> S7Payload payload) {
> return new Response(tpduReference, parameter, payload,
> errorClass, errorCode);
> }
> }
>
> Is there a cleaner way of doing something like this?
>
> Chris
>
>
>
> Am 29.05.19, 09:34 schrieb "Christofer Dutz" <
> christofer.d...@c-ware.de>:
>
> Hi all,
>
> I just wanted to give you all an update on how we are progressing
> on the driver generation front.
>
> I just pushed some major refactorings which transition the POC
> more in the direction of something usable.
> Here the most important changes:
>
> * There are Protocol-modules which are discovered similar to
> how we discover drivers in the classpath
> * There are now Language-(output)-modules which also are
> discovered similar to how we discover drivers in the classpath
> * The input modules generally provide only the spec
> * The output modules contain everything needed to produce
> output for a given language
> * In order to allow experimentation of the output variants the
> output modules contain everything needed to generate the output
> * My implementation of a language-template-java uses
> freemarker to generate output, but others could simply use other techniques
>
> So far I have a pojo template that will generate the POJO classes
> for the types in the spec.
> Right now I’m working on the little tool that will tell the output
> which Java type it should use for which spec type …
> but as soon as that’s done I’m looking forward to implementing the
> IO components.
>
> All of this is happening in the “feature/code-gen” branch … and
> all my code-generation related code is in sandbox/code-generation
>
> So far the update …
>
> Chris
>
>
>
>
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
